United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6965570 assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded")
JDK-6965570 : assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded")

Details
Type:
Bug
Submit Date:
2010-06-30
Status:
Closed
Updated Date:
2013-06-22
Project Name:
JDK
Resolved Date:
2011-04-24
Component:
hotspot
OS:
generic,linux_redhat_5.0
Sub-Component:
compiler
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs17,6
Fixed Versions:
hs21 (b05)

Related Reports
Backport:
Backport:
Backport:
Duplicate:

Sub Tasks

Description
Application run with debug solaris-i586 VM and stress options crashes with

#  Internal Error (/export0/BUILD_AREA/jdk6_21/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp:1595), pid=25387, tid=13
#  Error: assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded")

Stack trace:
V  [libjvm.so+0xb5eb75];;  void VMError::report(outputStream*)+0x5fd
V  [libjvm.so+0xb5fbe9];;  void VMError::report_and_die()+0x4b5
V  [libjvm.so+0x3a9873];;  void report_assertion_failure(const char*,int,const char*)+0x5f
V  [libjvm.so+0x1d2e3c];;  void LIRGenerator::do_LoadField(LoadField*)+0x46c
V  [libjvm.so+0x19ea74];;  void LoadField::visit(InstructionVisitor*)+0x14
V  [libjvm.so+0x1cbea9];;  void LIRGenerator::do_root(Instruction*)+0x75
V  [libjvm.so+0x1cbe0f];;  void LIRGenerator::block_do(BlockBegin*)+0x53
V  [libjvm.so+0x19cdbc];;  void BlockList::iterate_forward(BlockClosure*)+0x6c
V  [libjvm.so+0x19604b];;  void IR::iterate_linear_scan_order(BlockClosure*)+0x27
V  [libjvm.so+0x1630f2];;  void Compilation::emit_lir()+0x2b6
V  [libjvm.so+0x1636cf];;  int Compilation::compile_java_method()+0x1fb
V  [libjvm.so+0x1639fc];;  void Compilation::compile_method()+0x84
V  [libjvm.so+0x16422a];;  Compilation::Compilation(AbstractCompiler*,ciEnv*,ciMethod*,int)+0x252
V  [libjvm.so+0x1655ea];;  void Compiler::compile_method(ciEnv*,ciMethod*,int)+0xda
V  [libjvm.so+0x3412a8];;  void CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbec
V  [libjvm.so+0x33fbd5];;  void CompileBroker::compiler_thread_loop()+0x8ad
V  [libjvm.so+0xa99ac6];;  void compiler_thread_entry(JavaThread*,Thread*)+0x2a
V  [libjvm.so+0xa92796];;  void JavaThread::thread_main_inner()+0x16e
V  [libjvm.so+0xa924ce];;  void JavaThread::run()+0x34e
V  [libjvm.so+0x93a5dd];;  java_start+0x109
C  [libc.so.1+0xa7045];;  _thr_setup+0x4e
C  [libc.so.1+0xa7330];;  _lwp_start+0x0

                                    

Comments
EVALUATION

I believe this is an instance of 6354181.  It's not marked and it must be if we are able to read the fields to figure out they are static.  The only way that's possible is if we found a class which was still in a state earlier than loaded which is what occurs with 6354181.
                                     
2011-02-25
EVALUATION

This isn't the same as 6354181.
                                     
2011-03-01
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/425688247f3d
                                     
2011-03-07
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/425688247f3d
                                     
2011-03-21
EVALUATION

6965570: assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded")
Reviewed-by: iveresov

During code generation for a volatile getfield in an outer class we've
managed to resolve the inner class symbolically but the constant pool
reference hasn't actually been resolved.  This results in a field
reference that should be patched so that the proper access checks are
performed by constant pool resolution.  In this case the field is
volatile and LIRGenerator expects that if the class was loaded and we
can see that's it actually volatile that a patch must not be needed.
In debug mode this asserts but in product mode it generates code to
uses max_jint for the field offset.  The fix is to always respect the
needs_patching flag.  We could makes the patching machinery handle
this more normally but that would complicate patching even more.  It's
a rare case so allowing deopt in Runtime1::patch_code to handle it is
the easiest way to go.

Part of the confusion stems from the is_loaded flag on AccessField
which doesn't really mean what it says, so I've removed it and pushed
all the needs_patching logic up into GraphBuilder.  is_initialized()
is similarly confusing since it really means does this static field
need patching.  I've eliminated that flag from AccessField and
captured that logic in a new method that is used instead.  Tested with
runthese with and without PatchALot, ctw, and the nsk jvmti tests.
                                     
2011-03-07



Hardware and Software, Engineered to Work Together