JDK-8214449 : Make alt_hash a regular immutable member of inner hash table
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 12
- Priority: P4
- Status: Resolved
- Resolution: Withdrawn
- Submitted: 2018-11-28
- Updated: 2019-08-15
- Resolved: 2018-12-13
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 |
|---|
13Resolved  |
Related Reports
|
Relates :
|
Description
Kim Barrett's comment: _alt_hash is not subject to concurrent modification, which is a good thing because there is lots of code that is not set up to cope with that possibility. It is only set by rehash_table, which is only called from safepoint cleanup. Hm, but looking at that makes me nervous. We're running various cleanup tasks in parallel. What happens if one of the other parallel tasks needs to look up a symbol? That seems like it would lead to bad things if it can happen. And it's not entirely obvious to me that it can't happen. Similarly for stringtable. Given the way it's used, it seems like it should be a StringTable ordinary member rather than a static member, and the new table produced by rehashing (that wants it turned on) should be constructed with it being true.
Comments
|