RFR(M): 8204615: [lworld] C2 support for java.lang.Object methods on value types
tobias.hartmann at oracle.com
Fri Jul 6 10:26:41 UTC 2018
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
... 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.
But I'm not sure why that is necessary..
More information about the valhalla-dev