JDK-8254109 : replay can fail due to missing jar/class files
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 16
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-10-07
  • Updated: 2022-02-02
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.
Other
tbdUnresolved
Related Reports
Blocks :  
Relates :  
Comments
[~dlong] the are multiple reasons for why a class file could not be available: - Bytecodes were generated at runtime - Bytecodes have been instrumented (statically or at runtime) - Not publicly available (anymore) - Not clear which version of the class file was used > It sounds like the issue is that we might be given a replay file without all the necessary jar/class files Yes. > so are you proposing a command-line flag to dump all class data? Yes. It would be off by default to allow the customer/reporter to decide if he wants to share that information. > How does the serviceability agent support this? HSDB supports it via the `dumpreplaydata` command: https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/doc/clhsdb.html#L52
05-08-2021

[~thartmann], could you please elaborate on the issue? It sounds like the issue is that we might be given a replay file without all the necessary jar/class files. Normally we would assume access to these files, so are you proposing a command-line flag to dump all class data? How does the serviceability agent support this?
05-08-2021