review for 7130676: Tiered: assert(bci == 0 || 0<= bci && bci<code_size()) during stack trace construction

Tom Rodriguez tom.rodriguez at oracle.com
Wed Jan 18 13:54:35 PST 2012


http://cr.openjdk.java.net/~never/7130676
14 lines changed: 11 ins; 0 del; 3 mod; 3293 unchg

7130676: Tiered: assert(bci == 0 || 0<= bci && bci<code_size()) during stack trace construction
Reviewed-by:

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.



More information about the hotspot-compiler-dev mailing list