JDK-7033779 : CodeCache::largest_free_block may need to hold the CodeCache lock
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2011-04-04
  • Updated: 2011-04-24
  • Resolved: 2011-04-24
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 Other
7Fixed hs21Fixed
Related Reports
Relates :  
JDK-7025742 - Can not use CodeCache::unallocated_capacity() with fragmented CodeCache
Relates :  
JDK-7034957 - acquiring lock CodeCache_lock/1 out of order with lock tty_lock/0 -- possible deadlock
Description
largest_free_block may walk the free block list but doesn't hold the CodeCache lock while doing so which could cause crashes.

Stack: [0x00007fbcef2e9000,0x00007fbcef3ea000],  sp=0x00007fbcef3e8490,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x4ab490]  CodeHeap::largest_free_block() const+0x80
V  [libjvm.so+0x3a29b7]  CompileBroker::compile_method(methodHandle, int, int, methodHandle, int, char const*, Thread*)+0x307
V  [libjvm.so+0x39364f]  SimpleCompPolicy::method_invocation_event(methodHandle, Thread*)+0xef
V  [libjvm.so+0x392b1e]  NonTieredCompPolicy::event(methodHandle, methodHandle, int, int, CompLevel, Thread*)+0xde
V  [libjvm.so+0x504c4e]  InterpreterRuntime::frequency_counter_overflow_inner(JavaThread*, unsigned char*)+0x13e
V  [libjvm.so+0x5050c6]  InterpreterRuntime::frequency_counter_overflow(JavaThread*, unsigned char*)+0x16
j  org.sunflow.core.renderer.BucketRenderer.refineSamples([Lorg/sunflow/core/renderer/BucketRenderer$ImageSample;IIIIFLorg/sunflow/core/IntersectionState;)V+0
j  org.sunflow.core.renderer.BucketRenderer.refineSamples([Lorg/sunflow/core/renderer/BucketRenderer$ImageSample;IIIIFLorg/sunflow/core/IntersectionState;)V+241
j  org.sunflow.core.renderer.BucketRenderer.renderBucket(Lorg/sunflow/core/Display;IIILorg/sunflow/core/IntersectionState;)V+454
j  org.sunflow.core.renderer.BucketRenderer.access$300(Lorg/sunflow/core/renderer/BucketRenderer;Lorg/sunflow/core/Display;IIILorg/sunflow/core/IntersectionState;)V+8
j  org.sunflow.core.renderer.BucketRenderer$BucketThread.run()V+125
v  ~StubRoutines::call_stub
V  [libjvm.so+0x509ad5]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x345
V  [libjvm.so+0x508608]  JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x28
V  [libjvm.so+0x50889c]  JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x17c
V  [libjvm.so+0x5089c7]  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x47
V  [libjvm.so+0x5577ff]  thread_entry(JavaThread*, Thread*)+0xdf
V  [libjvm.so+0x7fdf4a]  JavaThread::run()+0x17a
V  [libjvm.so+0x6e2590]  java_start(Thread*)+0x100
Comments
EVALUATION 7033779: CodeCache::largest_free_block may need to hold the CodeCache lock Reviewed-by: kvn CodeCache::largest_free_block may be called without the CodeCache_lock being held which might result in crashes when the free list is being updated. The changes for 7025742 are the primary culprit but there are other places where this was being done. The fix is to acquire the lock when needed. I wasn't able to directly reproduce the original crash so I just tested it by running the JVM a bit to make sure the calls to largest_free_block continued to work correctly in both contexts.
06-04-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/527977d4f740
06-04-2011