The NoClassDefFoundError bug is back :(

Rémi Forax forax at univ-mlv.fr
Mon Dec 5 07:28:32 PST 2011


John, Christian,
I was updating the multi-dispatch sample from the cookbook
when the NoClassDefFoundError bug re-appear.



[forax at localhost multi-dispatch]$ java -ea -cp classes:. Main2
skip java.lang.String.contentEquals/2
skip java.lang.String.replace/3
Exception in thread "main" java.lang.NoClassDefFoundError: Main2
     at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java)
     at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java)
     at Main2.test2(Main2.java:27)
     at Main2.main(Main2.java:42)

[forax at localhost src]$ java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b07)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b03, mixed mode)

The sample is here:
http://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/src/jsr292/cookbook/mdispatch/

You can compile it from src,
javac -d ../classes jsr292/cookbook/mdispatch/*.java

The example that doesn't work is Main2, which is created by compiling 
Main2.java
and then by rewriting all invokevirtual/invokestatic to invokedynamic 
using this line
java -cp classes:../lib/asm-debug-all-4.0_RC1.jar 
jsr292.cookbook.mdispatch.Rewriter Main2.class

Note that Main2.class is already rewritten so you don't have to do it
if you just want to reproduce the bug without modifying Main2.java

I think the error is thrown when calling a method handle created by this 
line
https://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/src/jsr292/cookbook/mdispatch/SmallSelectorMetadata.java?spec=svn13&r=13#121
at this callsite
http://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/Main2.java#27

How the code works: it installs a bimorphic cache on the receiver
and an inlining cache on the parameters. After 3 cache misses, the 
implementation
switch to use a table based resolution that lookup for most specific 
method handle and
use an exactInvoker to call it. The bug appear when the exactInvoker is 
called.

regards,
Rémi



More information about the mlvm-dev mailing list