I want to make a comment on OptimizeMethodHandles here, for those users (extremely important users!) who build and/or use the JSR 292 features while they are incubating in the mlvm repository.
As we complete the JDK7 cycle, I'm working on a long-standing problem with the current implementation (in HotSpot only), which is that method handle "glue logic" cannot block to perform GC, etc. This is tracked by bug 6939861. I am working on this bug now. Until this bug is fixed, all method handle logic is required to be non-blocking and tail-recursive, so that there is no disturbance to the thread's backtrace that can be observed by other modules (GC, exception thrower, deoptimizer, debugger, etc.). When this bug is fixed, the JVM will recognize a special MH adapter frame that will function as a place-holder, even if the JVM needs to walk the stack. While I am working on 6939861, the OptimizeMethodHandles flag, if explicitly set to true on the JVM command line, will turn on the bleeding edge code for blocking method handles. If it is turned off or unspecified, you shouldn't get blocking MH's. In the current (as of today) version of the patch, the special frames are created only for primitive-to-reference conversions, which is the simplest case. Additional cases to follow are (a) invoking an arbitrary MH to filter single argument and (b) invoking an arbitrary MH to collect (or fold) several arguments into a single result. So the new code (at present) just handles boxing, which may trigger a GC. There are some known failures when this new code is turned on, so I have not turned it on by default. I would be grateful for reports of what happens if you turn it on for use cases that you care about. Best wishes, -- John P.S. A general note on scheduling: The official Public Review of the JSR 292 API specification ends on 4/18. Comments are always welcome, but the door will close for changes soon after that. As you might guess from looking at the JDK7 schedule, the API will be finalized in May (with an official Public Final Draft). This isn't the only chance to adjust things, since the JSR 292 EG expects to do a maintenance release (MR) of the API in the future, with lots more goodies. Anyway, thanks for all the help! On Apr 9, 2011, at 11:01 PM, john.r.r...@oracle.com wrote: > Changeset: b8a6a156fc3a > Author: jrose > Date: 2011-04-09 21:49 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b8a6a156fc3a > > meth: final version of 6987991, turn on 6939861 with > -XX:+OptimizeMethodHandles > > ! meth-conv-6939861.patch > ! meth-ver-6987991.patch > ! series _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
