Allow redefinition of Object in fast HCR

[gacholio]

Allow java.lang.Object to be redefined (or retransformed) in fast HCR
mode (i.e. runtime HCR, not extended HCR used by the java debugger).

Related: #3410

[ci skip]

Signed-off-by: Graham Chapman graham_chapman@ca.ibm.com

[gacholio]

Note there is currently no testing for this because:

a) Proper testing requires generating class files (more difficult than just writing .java files)
b) Any test would fail at -Xint today (since that implies extended HCR)

[gacholio]

jenkins test all plinux jdk8

[gacholio]

I have hand-tested the virtual and non-virtual cases for Object (which also covers the private interface method case). Tests will eventually be added to cover all of these cases.

[fjeremic]

@andrewcraik FYI so we can think about whether JIT optimizer makes certain assumptions about java.lang.Object and it's methods.

[andrewcraik]

There are definitely assumptions in some places - we need to prioritize the dev work to do this against other items since it will take a bit of time to find all the possible dependencies.

[gacholio]

@andrewcraik I'd call the JIT work low-priority at this point - we already allow Object to be transformed at load time, so any assumptions you're making can already be broken (and the VM has plenty of its own assumptions around Object).

[andrewcraik]

So just caaturing some thoughts discussion related to this:

• what are we going to do if Object's finalize method gains a body - is the GC going to start running these? what are we going to do with JITCODE that has been produced assuming that no finalization is necessary?
• the JIT is going to need to stop special casing Object.hashCode and rely on forcing the inlining to get fastIdentityHashCode exposed to get good performance - I think this may be done, but we need to check
• we will need to worry about Object.clone changing - if clone gains side-effects they may not be respected by JIT optimizations to object cloning to force it inline - we'll need an appropriate guard
  Given the impacts of the above can there at least be some kind of debug option to disable allowing Object redefinition in case of perf or functional problems?

[DanHeidinga]

For the case of clone / finalize, can we, as you've elegantly suggested in the past, "throw the car battery in the pool" and dump the entire code cache if those methods are redefined?

[andrewcraik]

certainly possible - depends on the perf behaviours that are expected.

[gacholio]

The fix is to not recognize the Object methods at all, and recognize the primitives that they call (and we're not allowing to be modified).

For other things like finalize, we will report the modification to the JIT, so it can break assumptions, etc, as needed.

finalize() in particular is interesting, since we use the tag when we allocate. There are several options:

1. Disallow Object becoming finalizeable

I like this since there's no way we're going to add finalization to arrays.

2. Allow it, propagate the finalize bits down the hierarchy

2a) New instances are finalizeable

Maybe.

2b) New and existing instances are finalizeable

Seems like a lot of work for nothing.

[gacholio]

Note that the things we're talking about here have nothing to do with HCR - Object can be modified in any of the unpleasant ways we've discussed at load time, so we need to handle it in both cases, which means we should remove as many of our hard-coded assumptions as possible.

I'll open a new issue to deal with our expectations for Object.

[gacholio]

Please continue any discussion in #4792

[DanHeidinga]

lgtm