JDK-8013651 : NMT: reserve/release sequence id's in incorrect order due to race
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs24,hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-04-30
  • Updated: 2013-09-12
  • Resolved: 2013-06-13
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
When developing new tests for NMT I ended up with: 

#  Internal Error (..\..\src\share\vm\services\memSnapshot.cpp:623), pid=6180, tid=10848
#  assert(new_rec->is_allocation_record()) failed: Sanity check

Zhengyu looked at it and it seems like it's a race where we end up with the wrong sequence id when one thread is releasing memory and another thread is reserving and gets the same address but they end up with incorrectly ordered sequence numbers.
The regression test was not created for this issue (JDK-8016595 closed as wont-fix). It is hard to reproduce w/o regression test. Closing with noreg-hard label.

updating priority to P2 because it causes bigapps crashes, release criterion. ILW = HMM