JDK-8168151 : Why do we need BasicHashtableEntry::next_addr() API?
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2016-10-18
  • Updated: 2016-11-07
  • Resolved: 2016-11-07
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.
JDK 10
10Resolved
Related Reports
Relates :  
JDK-8166848 - Performance bug: SystemDictionary - optimization
Relates :  
JDK-8166145 - runtime/threads/ThreadInterruptTest3 fails with ExitCode 0
Description
Do we really need BasicHashtableEntry<F>::next_addr() API?

For my JDK-8166145 I prototyped an optimization, that needs to be turned off whenever someone uses next_addr(), since the client might change the underlaying pointer (next_add() is not a ver apt name since it is returning a handle, and not the pointer).

I tried to modify "StringTable::buckets_unlink_or_oops_do()" not to use the next_addr() API, and only use next(), but it fails Java2Demo.jar with:

#  Internal Error (../../../../hotspot/src/share/vm/gc/serial/markSweep.inline.hpp:53), pid=35902, tid=20995
#  assert(Universe::heap()->is_in(obj)) failed: should be in heap, p:0x7fdd168860e0, heap_oop:0x700001758468, obj:0x6c1019e40
Comments
We need the next_addr() API to efficiently free entries (move them from the linked list to the free linked list). We could copy entries contents around, but at some point we still need to unlink them from one linked list and attach them to a different one (freed entries, ready to be reuses)
07-11-2016