JDK-8317527 : Make VtableStubs::entry_point() lock free
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-10-04
  • Updated: 2023-10-05
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
Relates :  
JDK-8317600 - VtableStubs::stub_containing() table load not ordered wrt to stores
Description
VtableStubs::entry_point() is used to query whether a given address is a vtable (or itable) stub.

It takes the global VtableStubs_lock to do so. However this is not necessary - these hashtable entries are only ever added, so a much faster store_release()/load_acquire() pair is sufficient to guarantee consistency during querying.

This is particularly important during class unloading where multiple threads do that query in parallel while cleaning CompiledICs. This can improve runtime of that part of the class unloading quite a bit.
Comments
Some perf numbers: when unloading with 16 parallel gc threads, the code snippet in CompiledIC::internal_set_ic_destination() // Don't use ic_destination for this test since that forwards // through ICBuffer instead of returning the actual current state of // the CompiledIC. if (is_icholder_entry(_call->destination())) { // When patching for the ICStub case the cached value isn't // overwritten until the ICStub copied into the CompiledIC during // the next safepoint. Make sure that the CompiledICHolder* is // marked for release at this point since it won't be identifiable // once the entry point is overwritten. InlineCacheBuffer::queue_for_release((CompiledICHolder*)get_data()); } shows the following timing (with a prototype for JDK-8316959 to avoid queue_for_release() taking a lot of time, diluting the results): new code | #nmethods = 41675 | time taken = 42,39 old code | # nmethods = 49138 | time taken = 167,24
05-10-2023