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

[Tobias Hartmann]

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