review(XS): 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier)

[Vladimir Kozlov]

I am fine with guarantees but I misled you with should_not_reach_here() in deopt 
stub on x86, sorry. It is not needed for the same reason as on SPARC.

Thanks,
Vladimir

Igor Veresov wrote:
> On Wednesday, January 18, 2012 at 7:34 PM, Tom Rodriguez wrote:
>> On Jan 18, 2012, at 7:18 PM, Vladimir Kozlov wrote:
>>
>>> Why not use should_not_reach_here() in deopt stub? Also x86 deopt stub does not have stop() or should_not_reach_here().
>> I think the stop should be removed from emit_deopt_handler on sparc since it's preceded by a direct jump. Usually we emit a stop when we do a call that we don't expect to return, like for an exception dispatch, but in this case since it's a jump it's really impossible the reach the following instruction.
> Indeed. Removed.
> 
> But my fix was incorrect. I had to return the 1K limits for the non-product builds. The code that we emit is flag-dependent and with TraceJump on sparc and VerfiyOops on x86 it can grow very large. Unfortunately that means that the asserts are not that useful and we can easily miss such a problem again. I'd like to make them guarantees instead.
> 
> Webrev updated: http://cr.openjdk.java.net/~iveresov/7131288/webrev.02/
> 
> igor
>> tom
>>
>>> Vladimir
>>>
>>> Igor Veresov wrote:
>>>> After 701291 we started generating should_not_reach() code in product VM in LIR_Assembler::emit_exception_handle()
>>>> which is significantly bigger than exception_handler_size for product VM. It seems that we generate should_not_reach for all other platforms, so I decided to leave it for sparc too. I adjusted the sizes for stubs so that they are the same in product and debug, which should enable the assert that checks for the overflow to make sense. Did the same for deopt stub too.
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/7131288/webrev.00/
>>>> igor
> 
> 
>