JDK-6316313 : hotspot terminates at assert during GC in java_g
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u3
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2003
  • CPU: x86
  • Submitted: 2005-08-26
  • Updated: 2014-02-27
  • Resolved: 2006-11-20
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.
1.4.2_14 b01Fixed
A customer reproted Hotspot crash at assert function in java_g command during GC.

# An unexpected error has been detected by HotSpot Virtual Machine:
#  Internal Error (C:/BUILD_AREA/jdk1.5.0_03/hotspot\src\share\vm\memory\genOopClosures.inline.hpp, 69), pid=2908, tid=2280
# Java VM: Java HotSpot(TM) Client VM (1.5.0_03-b07-debug mixed mode)
# Error: assert(!_g->to()->contains(obj),"Scanning field twice?")

 JRE : 1.4.2_08/5.0u3
 OS  : Windows 2003 server

 Launch the command line.
   java_g -cp .;csmjaxp.jar TEST1 TEST1.xml TEST1.xsd

 Several hours is needed to reproduce.

SUGGESTED FIX Either add another field to Thread which will not change during GC or store eax in a temporary stack slot. The former is the easy way to implement but the later more effecient.

EVALUATION When C1 generate native return code, there is a tiny time window during which GC can kick in and change _vm_result. It happens between where we unbox return result (in eax) and where we checking safepoint there after. This is a long standing bug, not exist in mustang since the rewriring of all the stub routines, but it is in tiger too. Thanks to Tom and Ken for help on this issue.