[lworld] RFR: object methods in VM for lworld value type

[Karen Kinnear]

Mr Simms,

Yay! Thank you so much for doing the vm changes for Object methods for -Xint. 

Question on functionality:
1) Cloneable - this is different than we had originally discussed - so I should bring this to an EG discussion -
hopefully for when you are there

Hard to catch all our sync fast paths - many thanks. Looks like the fast way to do this - hopefully
below radar. I don’t know all the JIT paths, but sounds like that is a follow-on for our JIT folks.

1.templateTable_x86.cpp
What happens if you skip verification and generate bytecodes with a monitor exit but no monitorenter
for a value type? Does this already fall through to IMSE?

2. synchronizer.cpp
Do you need checks for:
jni_enter, jni_exit, reenter, complete_exit
otherwise they seem to go into revoke_and_rebias and then inflate, never checking for exceptions

3. jvm.cpp
So JVM_Clone doesn’t need to throw CloneNotSupported because we ensure that this is not
a cloneable in classfileparser, and j.l.Object catches?
Is it worth adding an assertion here?

thanks,
Karen


> On Apr 26, 2018, at 11:20 AM, David Simms <david.simms at oracle.com> wrote:
> 
> Greetings,
> 
> Here is a patch that for the most part ensures Object methods implemented by the JVM do not crash (as some do today):
> 
> http://cr.openjdk.java.net/~dsimms/valhalla/object_methods/webrev0/
> 
> Summary of changes, interpreter only (-Xint):
> 
> * "Object.getClass()": sanity test
> * "Object.hashCode()" / "System.identityHashCode()": simply return 0
>     o should be revisited for "System.identityHashCode()", once we
>       have BSM hashCode generation in place
> * "Object.clone()": disallow "Cloneable" value types, throws
>   ClassFormatError
>     o implicit cloning via "pass by value" does not allow user code
>       (as clone does), so no clone
> * "Object.wait()", "notify()" and monitorenter byte-code: throw
>   IllegalMonitorStateException
>     o missing test for monitorexit (whoops)
> 
> This change is primarily to enable further prototyping with -Xint, giving JIT implementation further time to adjust to lworld, and ignoring JDK methods whom may or may not provide alternative implementations for lworld "objectification" of value types.
> 
> Cheers
> 
> /David Simms
> 
>