Nashorn bug JDK8u40 “Method Code Too Large”

Question

The Nashorn eval of a js script on a method invoked on an object that is actually implemented by its superclass, delegates to a dynamic linker. This iterates through the entire hierarchy of the class and builds a classWriter on all its methods. If the superclasses contain few 1000's of methods it still emits the "Method Code Too Large" error exceeding the 64K limit JDK defines.

var obj = SomeInitCode.getObjectOfCustomType();

var xyz = obj.doSomeOperation() // this is method implemented on obj's superclass which is Abstract.

The Nashorn engine then tries to create an Adaptor which thereafter fails as there are in my case about 6000+ methods on the Abstract class and its superclasses.

Ref:

http://skrishnamachari.wordpress.com/2014/06/18/nashorn-bug/

Also is there a possibility to access the latest Nashorn source to be able to quickly debug through. Atleast find a hack/ validate and have it stick for our use till some final patch is provided.

Answer 1

Sure, latest developer repo for the 8u branch is available at http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn. It will soon become the development stage for 8u60, though but you'll be able to get the 8u40 code here then: http://hg.openjdk.java.net/jdk8u/jdk8u40-dev/nashorn. FWIW, 8u and 9 code for Nashorn are almost entirely identical so far (so far, we backported everything from 9 to 8u except for some parser changes that don't actually affect externally observable behavior).

Speaking of your problem: if we need to generate a JS-to-Java adapter class for a Java class of +6000 methods, then it'll indeed fail as the constructor of the class will have code for looking up 6000 JS functions in the adapted object, and that'll indeed be too large. We might supposedly come up with some different way of organizing the constructor but it seems like an awful lot of work for a hopefully rare case of people having humongous classes.

Alternatively, we could check whether we only create adapters when they're really needed. Your above code snippet looks like the adapter is not strictly necessary at that point, so it might be that in certain scenarios we're overeager to create adapter classes. Do you have a full stack trace maybe?