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

[Igor Veresov]

Looks good! 

igor


On Wednesday, January 18, 2012 at 1:54 PM, 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.