RFR(M): 8204615: [lworld] C2 support for java.lang.Object methods on value types

[Tobias Hartmann]

Hi Roland,

as we've discussed off-thread I added a runtime check for now to avoid the potentially unstable
changes to the deoptimization code:
http://cr.openjdk.java.net/~thartmann/8204615/webrev.01/

We can improve this later by either moving the guard to the macro expansion phase or improve
webrev.00 once we understand why these changes are necessary. I'll file a RFE for that.

I've also re-enabled the hashCode tests and removed the PrintInlining flag from the tests because
it's not needed and increases test output and runtime significantly. All tests pass.

Thanks,
Tobias

On 06.07.2018 15:17, Roland Westrelin wrote:
> 
>>> Sure. The thing I still don't understand is why the bci of the
>>> monitorenter, given it can throw, is not included in the range covered
>>> by the exception handler. Shouldn't it be?
>>
>> I'm not sure either but if I don't increment the bci, for example test76 fails with:
>> Caused by: java.lang.IllegalMonitorStateException
>> 	at compiler.valhalla.valuetypes.TestLWorld.test76(TestLWorld.java:2066)
>> 	at compiler.valhalla.valuetypes.TestLWorld.test76_verifier(TestLWorld.java:2073)
>> 	... 6 more
> 
> It seems it tries to unlock the monitor that's not locked because it
> thinks it's locked but it finds it's not locked?
> 
> Debug info includes monitors that are locked. Given debug info for
> monitorenter includes the execution of that bytecode, the monitor that
> can't be locked is included in that list. I wonder if that messes things
> up on deoptimization (where locked monitors are pushed on the
> interpreter stack).
> 
> Roland.
>