JDK-6965570 : assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs17,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_redhat_5.0
  • CPU: generic,x86
  • Submitted: 2010-06-30
  • Updated: 2013-06-22
  • 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 6 JDK 7 Other
6u60Fixed 7Fixed hs21Fixed
Related Reports
Duplicate :  
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 http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/425688247f3d
21-03-2011

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.
07-03-2011

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

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

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.
25-02-2011