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

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: 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.test76verifier(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