JDK-8015848 : SA: ClassWriter have to support JSR292
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: hs25
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2013-06-03
  • Updated: 2019-08-15
  • Resolved: 2017-11-07
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 10
Related Reports
Blocks :  
Blocks :  
Blocks :  
Relates :  
Relates :  
SA ClassWriter have to support JSR292
Thanks Tobias for confirming. Closing as NAI as the issue is now fixed.

I think we can close this bug if buildreplayjars now works with lambdas. The warnings with replay compilation can be ignored by -XX:+ReplayIgnoreInitErrors. The problem that replay compilation does not work with compilations that inline lambdas is out of the scope of this bug.

'buildreplayjars' works with a testcase containing lambdas and creates app.jar & boot.jar. Trying to replay from the above files gives these kind of errors java.lang.NoClassDefFoundError: java/lang/invoke/LambdaForm$MH Error while parsing line 22: java/lang/invoke/LambdaForm$MH java.lang.NoClassDefFoundError: java/lang/invoke/LambdaForm$DMH Error while parsing line 23: java/lang/invoke/LambdaForm$DMH java.lang.NoClassDefFoundError: java/lang/invoke/LambdaForm$MH Error while parsing line 24: java/lang/invoke/LambdaForm$MH Is that something we should be worrying in this bug ?

Buildreplayjars goes through fine now. Probably got fixed with 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure.

Haha! It just got pushed to 10...

What is the status of this bug? Is it going to be fixed soon? The issue completely disables compilation replay, blocking investigation of other bugs.

I got next call stack: hsdb> buildreplayjars all /tmp/kvn/ Exception in thread "main" java.lang.InternalError at sun.jvm.hotspot.tools.jcore.ClassWriter.writeIndex(ClassWriter.java:106) at sun.jvm.hotspot.tools.jcore.ClassWriter.writeMethod(ClassWriter.java:550) at sun.jvm.hotspot.tools.jcore.ClassWriter.writeMethods(ClassWriter.java:431) at sun.jvm.hotspot.tools.jcore.ClassWriter.write(ClassWriter.java:93) at sun.jvm.hotspot.tools.jcore.ClassDump.dumpKlass(ClassDump.java:166) at sun.jvm.hotspot.tools.jcore.ClassDump.access$000(ClassDump.java:38) at sun.jvm.hotspot.tools.jcore.ClassDump$1.visit(ClassDump.java:109) at sun.jvm.hotspot.memory.Dictionary.classesDo(Dictionary.java:68) at sun.jvm.hotspot.memory.SystemDictionary.classesDo(SystemDictionary.java:190) at sun.jvm.hotspot.tools.jcore.ClassDump.run(ClassDump.java:105)

So when this will be fixed at least in jdk9?

SQE defer OK

Attempt to fix it failed because some important information still missed in the class file. Continue with debugging.

The fix get stuck on review.

invokedynamic related functions in ConstantPool.java (and related) is broken, because re-implementing it from hotspot we missed the fact that x86 is little endian but java is big endian so we need byteswap in couple of places.

This really should be done for 8, not some future version. This is a blocking issue for the compiler team.

Which means no compiler replay. (From Christian)

Impact = H Likelihood = L Workaround = H HLH -> P2

JDK core libraries are now using Lambdas which means we can't use the SA to extract boot class path classes.