review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code

Vladimir Kozlov vladimir.kozlov at
Fri Jul 13 11:36:23 PDT 2012
   I am concern that BMH subclass names are looks like constants names: BMH_LLI. 
In several places you have BMH constants and variables:

+ final Class<BoundMethodHandle> BMH = BoundMethodHandle.class;

+ static final String BMH = "java/lang/invoke/BoundMethodHandle"; empty diffs
  remove commented print statement if it is not needed:

-        System.out.println(arrayType.getSimpleName());
+        //System.out.println(arrayType.getSimpleName());


John Rose wrote:
> On Jul 11, 2012, at 5:53 PM, John Rose wrote:
>> As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months.  These changes make method handles more optimizable.  They refactor lots of "magic" out of the JVM and into more manageable Java code.
>>>> An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine.  (This change set also deletes a lot of old code.)
> Here is that webrev:
> These are the changes to JDK code that accompany the JVM changes already under review.
> There are 2900 LOC deleted, and 7000 LOC added.  Key changes:
>  - method handle behavior is fully represented by LambdaForm objects
>  - chained method handles (including "adapter method handles") are gone
>  - an ASM-based bytecode spinner compiles LambdaForms when they warm up
>  - bound method handles are compactly represented without boxing
>  - the private symbol-resolution interface to the JVM (MemberName) is improved
>  - unit tests have more systematic coverage
>  - a number of minor bugs are fixed
> This is implementation work.  No public Java APIs are changed, although the javadoc is slightly edited for clarity.
> Please have a look.
> — John

More information about the hotspot-compiler-dev mailing list