RFR: 8262912: ciReplay: replay does not simulate unresolved classes

[Dean Long]

On Thu, 14 Oct 2021 13:40:02 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When trying to replay compile, the JVM will always resolve some classes before actually doing the replay compilation. When finally replay compiling the method, the state of `ciInstanceKlasses` which are resolved/unresolved could be different compared to the state at which the replay file was dumped. This will even be a bigger problem when tackling [JDK-8254110](https://bugs.openjdk.java.net/browse/JDK-8254110).
>> 
>> This change intends to fix this by only treating a `ciInstanceKlass` as *not* unresolved if there is a corresponding entry for it in the replay file. This is achieved by a whitelist (`ciInstanceKlassRecord`). All accesses to get a pointer to a `ciInstanceKlass` are eventually routed through `ciEnv::get_metadata()`. This method is hooked to compare it against the replay compilation whitelist. If the corresponding `Klass` is not on the list, an unresolved `ciInstanceKlass` is returned instead.
>> 
>> Finding a way to reliably test this feature was difficult. I therefore came up with a test which first creates a replay file with `CICrashAt` and then removes the `ciInstanceKlass` entry for class `Foo` to simulate that `Foo` was unresolved at replay dump time. This will result in a different C2 IR which is verified by checking the `PrintIdeal` output (see comments in test).
>> 
>> Thanks,
>> Christian
>
> Thanks Vladimir and Dean for your reviews!
> 
> @dean-long: Should we already do some of these changes now or should we move forward and eventually fix these in JDK-8254110?

@chhagedorn I suggest pushing what you have now and fixing the leaks in JDK-8254110.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5926