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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Jan 18 14:52:54 PST 2012


Looks good.

Thanks,
Vladimir

Tom Rodriguez wrote:
> 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