JDK-6560083 : -XX:+PrintPreciseBiasedLockingStatistics fails on amd64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: x86
  • Submitted: 2007-05-21
  • Updated: 2019-09-13
  • Resolved: 2016-03-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 9
9Resolved
Related Reports
Duplicate :  
JDK-8031320 - Use Intel RTM instructions for locks
Description
-XX:+PrintPreciseBiasedLockingStatistics on amd64 (any OS) causes random
failures at runtime.
The BiasedLockingCounters structure containing the counters is
malloc'ed and ends up being far from the code cache. In the
following MacroAssembler method, check_reach returns false:

  void incl(Address dst)
  { 
    check_reach(dst) ? Assembler::incl(dst) :
                       Assembler::incl(Address(rscratch1));
  }

dst is the malloc'ed space for the counters.  Looks like
we fail to initialize the register rscratch1 with dst,
and just increment at whatever address is in R10 (rscratch1).
Comments
This was fixed as part of JDK-8031320: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/diff/606acabe7b5c/src/cpu/x86/vm/macroAssembler_x86.cpp#l1.61
07-03-2016
ILW=HLM=P3
26-03-2014
The problem still exists: void MacroAssembler::atomic_incl(AddressLiteral counter_addr) { pushf(); if (os::is_MP()) lock(); incrementl(counter_addr); popf(); } void MacroAssembler::incrementl(AddressLiteral dst) { if (reachable(dst)) { incrementl(as_Address(dst)); } else { lea(rscratch1, dst); incrementl(Address(rscratch1, 0)); } }
16-10-2013
EVALUATION The problem is opposite: we insert 'movq rscratch1,imm64' between 'lock' generated in atomic_incl() and 'incl' instruction. See check_reach(Address adr). This creates incorrect HW instruction 'lock movq': # An unexpected error has been detected by Java Runtime Environment: # # SIGILL (0x4) at pc=0xfffffd7ffa8f92a5, pid=20373, tid=1 # 0xfffffd7ffa8f92a4: pushfq 0xfffffd7ffa8f92a5: lock movq $0x00000000006c58e8,%r10 0xfffffd7ffa8f92b0: incl (%r10) 0xfffffd7ffa8f92b3: popfq The problem is worse than this: any instruction which use a static address will have this problem with 'lock'. It includes cmpxchq(r,addr). It seems, we should pass a flag into assembler instruction or add new instructions so that 'lock' prefix will be generating before the requested assembler instruction.
23-05-2007