JDK-7130676 : Tiered: assert(bci == 0 || 0<= bci && bci
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs23
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-01-17
  • Updated: 2012-03-24
  • Resolved: 2012-03-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 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Duplicate :  
JDK-7130677 - Tiered: assert(bci == 0 || 0<= bci && bci
Relates :  
JDK-7131259 - compile_method and CompilationPolicy::event shouldn't be declared TRAPS
Description
Fastdebug VM crashes with the following assertion when trying to construct stack trace for an uncaught exception in Reference Handler thread:
#
#  Internal Error (/tmp/jprt/P1/085000.jcoomes/source/src/share/vm/oops/methodOop.cpp:508), pid=25769, tid=26
#  assert(bci == 0 || 0<= bci && bci<code_size()) failed: illegal bci
#
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a81f60ddab06
22-03-2012
EVALUATION 7130676: Tiered: assert(bci == 0 || 0<= bci && bci<code_size()) during stack trace construction Reviewed-by: kvn, iveresov This appears to be a long standing issue that was exposed by the tiered code. The bci -1 is used to represent a point in a method before execution has actually started and is commonly used for the stack at the monitor enter of a synchronized method (SynchronizationEntryBCI). The code which records stack traces for exception only records a u2 so the -1 doesn't fit and it blindly gets smeared to 65535. If that value is used to look up line number then it asserts because the value is out of range. In product mode the line number code would report the line number with the highest bci in the line number table when it really should report the lowest. The fix is to smear -1 to 0. In this particular case we're throwing an OOM while inside the counter overflow on entry to a method. The exception appears to propagate up from compile_method, presumably from the resolve_string_constants and load_signature_classes calls. compile_method_base is also declared TRAPS though it can't actually throw an exception. I think the whole path from CompilationPolicy::event to compile_method_base should be cleaned up so that exceptions can't propagate. Any exception thrown in the path are side effects and not exception that should even be propagated to the regular Java code. I'll file a separate bug for this. Tested with failing test from report.
23-01-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a81f60ddab06
23-01-2012