hg: mlvm/mlvm/hotspot: rebase to jdk7-b132 in bsd-port

[John Rose]

On Mar 24, 2011, at 9:01 PM, Stephen Bannasch wrote:

>> Except for MethodTypeTest, this is the group of failures you might get if jtreg were using the wrong (out-of-date) javac.  That's odd, because I think jtreg's -jdk: option pulls javac out of the same place as the JVM and JDK runtime.
>> 
>> Would you mind posting or sending me the test output (*.jtr files)?
> 
> Sure, I've attached JTwork_java_lang_invoke.tgz

The root cause is visible in InvokeGenericTest.jtr:

> ----------messages:(3/291)----------
> command: junit -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.lang.invoke.InvokeGenericTest
> reason: User specified action: run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.lang.invoke.InvokeGenericTest 
> elapsed time (seconds): 0.096
> ----------System.out:(0/0)----------
> ----------System.err:(24/1600)----------
> java.lang.UnsatisfiedLinkError: java.lang.invoke.MethodHandleNatives.registerNatives()V
> 	at java.lang.invoke.MethodHandleNatives.registerNatives(Native Method)
> 	at java.lang.invoke.MethodHandleNatives.<clinit>(MethodHandleNatives.java:125)
> 	at java.lang.invoke.MethodType.makeImpl(MethodType.java:248)

The JVM is failing to link the native method java.lang.invoke.MethodHandleNatives.registerNatives.  It's clear that you have a good version of rt.jar, but the JVM is refusing to link it.

This could happen, for example, if meth-impl-6839872.patch has not been applied in the hotspot repository.

Or it could be the JVM is somehow confused about which version of 292 it is supposed to link to.  (If that's the case it should be printing something out, which I don't see in the *.jtr file.  When you run the build script does the jtreg command produce any output?

Also, try running jtreg with -XX:-AllowTransitionalJSR292, to encourage the JVM to forget about the old names.

-- John