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

Tobias Hartmann tobias.hartmann at oracle.com
Mon Jul 9 13:03:19 UTC 2018

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:

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.


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.

More information about the valhalla-dev mailing list