Can't get lambda forest to work
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Jun 17 03:01:25 PDT 2010
Hi
The "Closures.java" example works as expected, but you need a b93
hotspot to run it. I'm now trying to sort this out using a slightly
different approach (reverting hotspot source to b93 and then do a full
build). If this happens to work, I will post detailed instructions on
how to get the lambda-repo up and running while we wait for a complete
292 fix (which, btw is on its way).
Maurizio
On 17/06/10 09:47, Peter Levart wrote:
> Hello Maurizio,
>
> I'm very eager to try this out (and that's the 1st time I did a build of OpenJDK myself) so please bear with me if I ask questions that don't belong to this list.
>
> 1st I tried some naive "patching" of hostspot myself:
>
>
> diff -r b0e7cd862748 src/share/vm/classfile/javaClasses.cpp
> --- a/src/share/vm/classfile/javaClasses.cpp Thu Jun 10 13:58:59 2010 -0700
> +++ b/src/share/vm/classfile/javaClasses.cpp Wed Jun 16 15:05:16 2010 +0200
> @@ -2454,9 +2454,9 @@
> if (!EnableInvokeDynamic) return;
> klassOop k = SystemDictionary::CallSite_klass();
> if (k != NULL) {
> - compute_offset(_target_offset, k, vmSymbols::target_name(), vmSymbols::java_dyn_MethodHandle_signature());
> - compute_offset(_caller_method_offset, k, vmSymbols::vmmethod_name(), vmSymbols::sun_dyn_MemberName_signature());
> - compute_offset(_caller_bci_offset, k, vmSymbols::vmindex_name(), vmSymbols::int_signature());
> + compute_offset(_target_offset, k, vmSymbols::target_name(), vmSymbols::java_dyn_MethodHandle_signature(), true);
> + compute_offset(_caller_method_offset, k, vmSymbols::vmmethod_name(), vmSymbols::object_signature(), true);
> + compute_offset(_caller_bci_offset, k, vmSymbols::callerBCI_name(), vmSymbols::int_signature(), true);
> }
> }
>
> diff -r b0e7cd862748 src/share/vm/classfile/vmSymbols.hpp
> --- a/src/share/vm/classfile/vmSymbols.hpp Thu Jun 10 13:58:59 2010 -0700
> +++ b/src/share/vm/classfile/vmSymbols.hpp Wed Jun 16 15:05:16 2010 +0200
> @@ -344,6 +344,7 @@
> template(form_name, "form") \
> template(erasedType_name, "erasedType") \
> template(append_name, "append") \
> + template(callerBCI_name, "callerBCI") \
> \
> /* non-intrinsic name/signature pairs: */ \
> template(register_method_name, "register") \
> diff -r b0e7cd862748 src/share/vm/prims/methodHandles.cpp
> --- a/src/share/vm/prims/methodHandles.cpp Thu Jun 10 13:58:59 2010 -0700
> +++ b/src/share/vm/prims/methodHandles.cpp Wed Jun 16 15:05:16 2010 +0200
> @@ -2564,9 +2564,10 @@
>
> // More entry points specifically for EnableInvokeDynamic.
> static JNINativeMethod methods2[] = {
> - {CC"registerBootstrap", CC"("CLS MH")V", FN_PTR(MHI_registerBootstrap)},
> - {CC"getBootstrap", CC"("CLS")"MH, FN_PTR(MHI_getBootstrap)},
> - {CC"setCallSiteTarget", CC"("CST MH")V", FN_PTR(MHI_setCallSiteTarget)}
> +// these are all removed from MethodHandleNatives (where have they gone?)
> +// {CC"registerBootstrap", CC"("CLS MH")V", FN_PTR(MHI_registerBootstrap)},
> +// {CC"getBootstrap", CC"("CLS")"MH, FN_PTR(MHI_getBootstrap)},
> +// {CC"setCallSiteTarget", CC"("CST MH")V", FN_PTR(MHI_setCallSiteTarget)}
> };
>
>
> ... and JVM didn't crash any more but when I tried to run the "Closures.java" example I got the following:
>
> Exception in thread "main" java.dyn.NoAccessException: cannot access: *.java.dyn.MethodHandle.invoke()int
> at sun.dyn.MemberName.newNoAccessException(MemberName.java:421)
> at sun.dyn.MemberName.newNoAccessException(MemberName.java:412)
> at sun.dyn.MemberName$Factory.resolveOrFail(MemberName.java:517)
> at java.dyn.MethodHandles$Lookup.findVirtual(MethodHandles.java:268)
> at sun.dyn.Invokers.exactInvoker(Invokers.java:66)
> at sun.dyn.Invokers.genericInvoker(Invokers.java:74)
> at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:354)
> at closures.Closures.main(Closures.java:9)
>
> so I thought that there are obviously other things that need to be sorted out in hotspot and supporting java.dyn classes to make it run correctly (or, which is unlikely, the bytecode generated by latest lambda prototype is wrong?).
>
> Then I saw your Email about possible work-arrounds and here's what I tried:
>
> I reverted my JVM "patch" and:
>
> 1st I tried building clean/all with ALT_JDK_IMPORT_PATH set to b97 and BUILD_HOTSPOT=flase and that didn't work - still crashing on java.dyn.CallSite offset calculations (b97 seems to have newer hotspot which is not compatible with java.dyn classes any more) - with your latest patch to java launcher such jdk is unusable even for normal programs because it always tries to initialize method handles eagerly and crashes...
>
> 2nd I tried building with ALT_JDK_IMPORT_PATH set to b95 (which should be the same as b94 apart from SUN->Oracle re-branding according to change-log) and I get the same VM crash.
>
> I even tried to run the compiled class with stock binary distributed b95 and b97 JDKs with same results.
>
> Unfortunately I don't have any earlier JDK7 release to try and Oracle made sure that b94 and earlier releases are not accessible any more (those damn lawyers)...
>
>
> It seems I will have to wait for John Rose to push a working hotspot/jdk combo...
>
>
> Regards, Peter
>
> On 06/16/10, Maurizio Cimadamore wrote:
>
>> I recently pushed some changes that should improve the usability of the
>> javac/java artifacts generated during a full build of the lambda
>> repository. Now it is not necessary to manually specify the -XX VM
>> options (the launcher adds them for you); classes that are required
>> during compilation/execution (e.g. com/sun/runtime/ProxyHelper) are now
>> added to rt.jar so that they are automatically found by the jdk.
>>
>> The only problem that needs to be fixed now is the VM crash. We are
>> working on a patch that I will push it in the lambda-repo; meanwhile you
>> might want to build the repo with the ALT_JDK_IMPORT_PATH option set (to
>> point to a JDK distro, b94 is fine), and also BUILD_HOTSPOT=false.
>>
>> Alternatively you can use the workaround suggested in this email, as
>> Remi pointed out:
>>
>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-May/001727.html
>>
>> with one caveat: if you build hotspot from the sources in the lambda
>> repo, you will need to add the patch to the bootclasspath of the VM used
>> for launching javac. This is done by invoking javac as follows:
>>
>> javac -J-Xbootclasspath/p:$DOWNLOADS$/hs19-b01-jsr292-patch.jar<javac-args>
>>
>> I apologize for the inconvenient.
>>
>> Maurizio
>>
>>
>>
>> On 15/06/10 17:58, Maurizio Cimadamore wrote:
>>
>>> On 15/06/10 17:57, Andrew Haley wrote:
>>>
>>>
>>>> On 06/15/2010 02:49 PM, Maurizio Cimadamore wrote:
>>>>
>>>>
>>>>
>>>>> I did a merge with b97, I hope that helps.
>>>>>
>>>>>
>>>>>
>>>> Not exactly, sorry.
>>>>
>>>> I still get
>>>>
>>>>
>>>>
>>> Noticed that me too - we are working to fix this issue.
>>>
>>> Maurizio
>>>
>>>
>>>> happy:local $ hg fclone http://hg.openjdk.java.net/lambda/lambda
>>>>
>>>> ... make ...
>>>>
>>>> happy:~ $ /local/lambda/build/linux-amd64/j2sdk-image/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic Closures
>>>> Invalid layout of java.dyn.CallSite at target
>>>>
>>>> Andrew.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
More information about the lambda-dev
mailing list