JDK-8219642 : ciReplay loads wrong data when MethodData size changes
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 13
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2019-02-25
- Updated: 2019-08-15
- Resolved: 2019-03-08
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.
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 13 |
|---|
13 b12Fixed  |
Related Reports
|
Relates :
|
Description
I stumbled upon this problem when trying to reproduce https://bugs.openjdk.java.net/browse/JDK-8219448 on JDK 13. The crash was recorded on a late 12 build, but the issue doesn't reproduce on 13. A bisection revealed that JDK-8210832 "Remove sneaky locking in class Monitor" caused the problem, at it doesn't even touch the compilers. The problem is that when ciReplay serializes a ciMethodData it will serialize a MethodData as an array precceded by the size. But a MethodData contains an inlined Mutex, and its size changed with the removal of sneaky locking. This fix adds code for detecting a size change of MethodData, and tries to recover by adding padding or dropping data. Since all non significant serialization data are in the beginning, the padding or dropping of data is done from the start.
Comments
|