[lworld] RFR: object methods in VM for lworld value type (original) (raw)

Karen Kinnear karen.kinnear at oracle.com
Fri Apr 27 21:55:22 UTC 2018

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?

  1. 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

  2. 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/objectmethods/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

More information about the valhalla-dev mailing list