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: 2016-04-14
  • 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.
8u20Resolved 9Fixed
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
Duplicate of automatically generated JDK-8031308 for JDK9

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.

Forgot about JFR using the timers too, adapted ILW accordingly