JDK-8027364 : PSScavenge accounts too large code section to StringTable unlink
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,8
  • Priority: P5
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2013-10-28
  • Updated: 2023-08-21
  • Resolved: 2014-01-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 8 JDK 9
8u20Resolved 9Fixed
Related Reports
Duplicate :  
Description
The scope of the GCTraceTime timer is too large for string table processing for the parallel scavange GC, expanding beyond it.

I.e. in psScavenge.cpp:
      469     GCTraceTime tm("StringTable", false, false, &_gc_timer);
      470     // Unlink any dead interned Strings and process the remaining live ones.
      471     PSScavengeRootsClosure root_closure(promotion_manager);
      472     StringTable::unlink_or_oops_do(&_is_alive_closure, &root_closure);

The fix is to put braces around this section.

Reported with this fix suggestion by J. Manson on the hotspot-dev list (http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011420.html)

ILW: L (user reported timings are wrong), M (only used with event tracing/JFR enabled), H (no workaround) -> P5
Comments
Duplicate of automatically generated JDK-8031308 for JDK9
07-01-2014

noreg-other justification: this change modifies the scope of the timing; as such the difference to previous behavior is that the reported values are smaller than before, but there is no way to validate the values with a reasonable effort.
28-10-2013

Forgot about JFR using the timers too, adapted ILW accordingly
28-10-2013