United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7033779 CodeCache::largest_free_block may need to hold the CodeCache lock
JDK-7033779 : CodeCache::largest_free_block may need to hold the CodeCache lock

Details
Type:
Bug
Submit Date:
2011-04-04
Status:
Closed
Updated Date:
2011-04-24
Project Name:
JDK
Resolved Date:
2011-04-24
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs21
Fixed Versions:
hs21 (b09)

Related Reports
Backport:
Relates:
Relates:

Sub Tasks

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

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/527977d4f740
                                     
2011-04-06
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.
                                     
2011-04-06



Hardware and Software, Engineered to Work Together