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

Tobias Hartmann tobias.hartmann at oracle.com
Fri Jul 6 10:26:41 UTC 2018

Hi Roland,

On 06.07.2018 10:51, Roland Westrelin wrote:

If the method is deoptimized once the the monitor is being locked (by a concurrent class loading), then we would not want to reexecute the bytecode. Not sure if we can have a single bytecode where sometimes we want to reexecute the bytecode, sometimes not.

Yes, we would need to be able to control re-execution from the runtime and only re-execute if we deoptimize due to an exception when trying to lock on a value type. Sounds complicated.

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

In the interpreter, we increment rbcp as well before locking the object which may throw:

// Increment bcp to point to the next bytecode, so exception // handling for async. exceptions work correctly. // The object has already been poped from the stack, so the // expression stack looks correct. __ increment(rbcp);

[...]

__ lock_object(rmon);

http://hg.openjdk.java.net/valhalla/valhalla/file/afd996f10a3b/src/hotspot/cpu/x86/templateTable_x86.cpp#l4788

But I'm not sure why that is necessary..

Best regards, Tobias

More information about the valhalla-dev mailing list