See
https://github.com/openjdk/jdk/blob/7ec0132ad3129b805664c85351fe6d55041066fa/src/hotspot/share/oops/cpCache.cpp#L711-L720
ConstantPoolCache::walk_entries_for_initialization() is called by ConstantPoolCache::remove_unshareable_info() to restore the CpCache to the state immediately after the class has been rewritten by the Rewriter (which happens during the class linking phase). In most part, this means the ConstantPoolCacheEntry's need to be zeroed. However, the _f2 fields of some of the entries are initialized to be non-zero by the Rewriter and must be preserved.
The reason walk_entries_for_initialization() exists is that after Rewriter::rewrite() has finished, some information about what is stored inside the CpCache is discarded (e.g., Rewriter::_invokedynamic_references_map). As a result, we cannot easily determine which entries has a _f2 field that need to be preserved. We must walk all the bytecodes in all the methods of this class to recompute this information.
This is awkward and time consuming. It also needs to be updated if the Rewriter ever changes.
Also, for future optimizations, we may need to pre-resolve a subset of the CpCache entries during CDS dump time. Trying to make that work alongside walk_entries_for_initialization() seems too complicated.
==========================
Proposal:
Save a copy of the ConstantPoolCacheEntry's immediate after bytecode rewriting. At this point, there are no pointers inside the entries, so we are just saving a bunch of integer values.
During ConstantPoolCache::remove_unshareable_info(), simply overwrite the ConstantPoolCacheEntry's with the saved state.
https://github.com/openjdk/jdk/blob/7ec0132ad3129b805664c85351fe6d55041066fa/src/hotspot/share/oops/cpCache.cpp#L711-L720
ConstantPoolCache::walk_entries_for_initialization() is called by ConstantPoolCache::remove_unshareable_info() to restore the CpCache to the state immediately after the class has been rewritten by the Rewriter (which happens during the class linking phase). In most part, this means the ConstantPoolCacheEntry's need to be zeroed. However, the _f2 fields of some of the entries are initialized to be non-zero by the Rewriter and must be preserved.
The reason walk_entries_for_initialization() exists is that after Rewriter::rewrite() has finished, some information about what is stored inside the CpCache is discarded (e.g., Rewriter::_invokedynamic_references_map). As a result, we cannot easily determine which entries has a _f2 field that need to be preserved. We must walk all the bytecodes in all the methods of this class to recompute this information.
This is awkward and time consuming. It also needs to be updated if the Rewriter ever changes.
Also, for future optimizations, we may need to pre-resolve a subset of the CpCache entries during CDS dump time. Trying to make that work alongside walk_entries_for_initialization() seems too complicated.
==========================
Proposal:
Save a copy of the ConstantPoolCacheEntry's immediate after bytecode rewriting. At this point, there are no pointers inside the entries, so we are just saving a bunch of integer values.
During ConstantPoolCache::remove_unshareable_info(), simply overwrite the ConstantPoolCacheEntry's with the saved state.
- relates to
-
JDK-8292318 Memory corruption in remove_dumptime_info
-
- Resolved
-
-
JDK-8292534 Build failure with ASAN after JDK-8290833
-
- Closed
-