Planet JDKNews and views from the Java SE Development-Kit CommunityVariousJeroen Frijters: MethodHandle PerformanceJeroen Frijtershttp://weblog.ikvm.net/PermaLink.aspx?guid=35b39430-63e7-4807-a510-65ae70a8f5862015-06-25T06:59:31Z2015-06-25T06:59:31Z

Last time I mentioned that with the integration of OpenJDK 8u45 MethodHandle performance went from awful to unusable. That was pretty literal as the JSR 292 test cases that I regularly run went from taking about 8 minutes to more than 30 minutes (when my patience ran out).

http://weblog.ikvm.net/Trackback.aspx?guid=35b39430-63e7-4807-a510-65ae70a8f586http://weblog.ikvm.net/pingback.aspxhttp://weblog.ikvm.net/PermaLink.aspx?guid=35b39430-63e7-4807-a510-65ae70a8f586http://weblog.ikvm.net/CommentView.aspx?guid=35b39430-63e7-4807-a510-65ae70a8f586http://weblog.ikvm.net/SyndicationService.asmx/GetEntryCommentsRss?guid=35b39430-63e7-4807-a510-65ae70a8f586

Last time I mentioned that with the integration of OpenJDK 8u45 MethodHandle performance went from awful to unusable. That was pretty literal as the JSR 292 test cases that I regularly run went from taking about 8 minutes to more than 30 minutes (when my patience ran out).

Using sophisticated profiling techniques (pressing Ctrl-Break a few times) I determined that a big part of the problem was MethodHandle.asType(). So I wrote a microbenchmark:

   IKVM 8.0.5449.1  IKVM 8.1.5638
asType.permutations(1) 2108 9039
asType.permutations(2) 2476 17269

The numbers are times in milliseconds. Clearly not a good trend. I did not investigate deeply what changed in OpenJDK, but after looking at the 8u45 code it was clear that too many intermediate MethodHandles were being created. So I rewrote asType to create a single LambdaForm to do all the work at once. This improved the performance a bit, but the disturbing increase in time for the second iteration was still there. Once again I decided not to investigate the root cause of this, but simply to assume that it was because of anonymous type creation (the CLR has no anonymous types and creating a type is relatively expensive).

Avoiding anonymous type creation turned out to be easy (well, the high level design was easy, the actual implementation took a lot more time). I just had to replace the LambdaForm compiler. There is a single method that represents the exact point where I can come in and change the implementation:

static MemberName generateCustomizedCode(LambdaForm form, MethodType invokerType) { ... }

In OpenJDK this method compiles the LambdaForm into a static method in an anonymous class and returns a MemberName that points to the static method. All I had to do was replace this method with my own implementation that directly generates a .NET DynamicMethod. As I said before, the idea was simple, actually getting the implementation correct took a couple of weeks (part time).

With both these optimizations in place, MethodHandle performance is back to awful (actually, it is less afwul than it was before):

   IKVM 8.0.5449.1  IKVM 8.1.5638  IKVM 8.1.5653
asType.permutations(1) 2108 9039 314
asType.permutations(2) 2476 17269 210

The running time of the JSR 292 test cases went down to less than 7 minutes. So I was satisfied. There are many more opportunities to improve the MethodHandle performance on IKVM, but so far no IKVM user has complained about it, so it is not a priority. Note that Java 8 lambdas are not implemented using MethodHandles on IKVM.

Changes:

Binaries available here: ikvmbin-8.1.5653.zip

Jeroen2015-06-25T06:59:31Z
David Dice: Accelerating Native Calls using Transactional MemoryDavid Dicehttps://blogs.oracle.com/dave/entry/accelerating_native_calls_using_transactional2015-06-17T19:09:07Z2015-06-17T19:09:07Z

Accelerating Native Calls using Transactional Memory appears in WTTM 2015.

Dave 2015-06-17T19:09:07Z
David Dice: Refined Transactional Lock ElisionDavid Dicehttps://blogs.oracle.com/dave/entry/refined_transactional_lock_elision2015-06-11T16:03:49Z2015-06-11T16:03:49Z

Refined Transactional Lock Elision appears in Transact 2015.

Dave 2015-06-11T16:03:49Z
David Gilbert: JFreeSVG 3.0David Gilberthttp://www.jroller.com/dgilbert/entry/jfreesvg_3_02015-06-09T16:43:05Z2015-06-09T16:43:05Z

I'm happy to announce that JFreeSVG version 3.0 has been uploaded to SourceForge. JFreeSVG is a fast and lightweight API for creating SVG content in Java. This release features:

David Gilbert2015-06-09T16:43:05Z
Jeroen Frijters: New Development SnapshotJeroen Frijtershttp://weblog.ikvm.net/PermaLink.aspx?guid=852ff0da-f4da-44b6-8d25-5261ca4139862015-06-09T11:50:20Z2015-06-09T11:50:20Z

I integrated OpenJDK 8u45, so a new development snapshot is warranted. MethodHandle performance regressed from awful to unusable, so that's something I need to look into.

http://weblog.ikvm.net/Trackback.aspx?guid=852ff0da-f4da-44b6-8d25-5261ca413986http://weblog.ikvm.net/pingback.aspxhttp://weblog.ikvm.net/PermaLink.aspx?guid=852ff0da-f4da-44b6-8d25-5261ca413986http://weblog.ikvm.net/CommentView.aspx?guid=852ff0da-f4da-44b6-8d25-5261ca413986http://weblog.ikvm.net/SyndicationService.asmx/GetEntryCommentsRss?guid=852ff0da-f4da-44b6-8d25-5261ca413986Jeroen2015-06-09T11:50:20Z