JDK-8064467 : Deoptimization type information persistence doesn't work - "Failed to calculate version dir name"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-11-10
  • Updated: 2015-06-04
  • Resolved: 2014-11-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40Fixed 9 b40Fixed
Description
Run test script : 

var x = { a: 2, b:1 }; 
x.a = Number.POSITIVE_INFINITY; 
x.b = 0; 
print(x.a/x.b);

with options: -Dnashorn.typeInfo.maxFiles=100 --log=recompile:fine

output :
[recompile] Parameter type specialization of ':program' signature: (Object,Object)Object
[recompile] Failed to calculate version dir namejava.lang.NullPointerException
[recompile] Looking up ':program' type=(ScriptFunction,Object)Object
[recompile] Looking up ':program' type=(ScriptFunction,Object)Object
[recompile] RewriteException [pp=9, type=double, value=Infinityd)]
[recompile] Deoptimizing recompilation (up to bytecode) ':program' signature: (ScriptFunction,Object)Object [2->D] [9->D]
[recompile] Reusable IR generated
[recompile] Generating and installing bytecode from reusable IR...
[recompile] Rest-of compilation [CODE PIPELINE REUSE] ':program' signature: (ScriptFunction,Object)Object [2->D] [9->D]
[recompile] Done.
[recompile] Recompiled ':program' (0x0ea6147e)  can still be deoptimized.
[recompile] Looking up invoker...
[recompile] Looking up ':program' type=(ScriptFunction,Object)Object
[recompile] Done: MethodHandle(ScriptFunction,Object)Object
[recompile] Looking up ':program' type=(RewriteException)Object
Infinity
Comments
To verify the fix, just run nashorn shell with: java -Dnashorn.typeInfo.maxFiles=100 jdk.nashorn.tools.Shell --log=recompile and confirm that instead of [recompile] Failed to calculate version dir namejava.lang.NullPointerException you see [recompile] Optimistic type persistence directory is ${some_cache_dir}/com.oracle.java.NashornTypeInfo/${some-base64-encoded-sha1} with legitimately looking values for ${some_cache_dir} and ${some-base64-encoded-sha1}.
11-11-2014
I was trying to reproduce the same NPE for JDK-8064475, so I'm glad I saw this comment. Would getting the resource of an actual class file solve the problem? The following seems to work: final URL url = OptimisticTypesPersistence.class.getResource("/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.class");
11-11-2014
Ok, I can reproduce this also on Mac OS X, just by downloading b38 from https://jdk9.java.net/download/. I thought it might be a permission issue, but the permissions on the distributed nashorn.jar and a self-built one are the same. Investigating���
11-11-2014
Okay, this is subtle. The ant-built JAR file has entries for directories, e.g. jdk/ jdk/internal/ jdk/internal/dynalink/ jdk/internal/dynalink/beans/ jdk/internal/dynalink/beans/AbstractJavaLinker$1.class while the distribution JAR file won't have them (e.g. in the above, it'll start the package with jdk/internal/dynalink/beans/AbstractJavaLinker$1.class). We're trying to retrieve the URL for the nashorn JAR file so we can calculate its SHA1, and we do it using OptimisticTypesPersistence.class.getResource(""), which returns an URL as long as there's a directory entry in the JAR file, but returns null when there's none. Apparently, the distro build process is removing these directory entries from JAR files (well, except for META-INF/; it's treated specially). Adding "filesonly=true" to build.xml results in the same JAR file; it might be worth doing it that way to have a more similar nashorn.jar
11-11-2014
normal JDK distribution - download from http://jre.us.oracle.com/java/re/jdk//9/promoted/all/b38/bundles/ (jdk-9-linux-x64.tar.gz) with setting JAVA_HOME and $JAVA_HOME/bin/java to path. if I built nashorn.jar from jdk9/dev/nashorn repository (from tip or tag jdk9-b38) and put to $JAVA_HOME/jre/lib/ext, i wouldn't reproduced this issue.
10-11-2014
Can you give me the exact command line? Where are nashorn classes loaded from? (e.g. is it a normal JDK distribution or something else)
10-11-2014