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

[Dean Long]

On Wed, 13 Oct 2021 09:21:18 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

Looks good.  There's a memory leak with the global mirror jobjects that will need to be fixed for JDK-8254110.  One way to do this might be to prune your replay white list as klasses are added to _ci_metadata.  That would mean moving your white list check until we check for existing klasses in _ci_metadata.
Also, you could reduce the number of JNI global refs needed by putting the mirror objects in an array, then storing the array in a single JNI global ref, or adding it to what gets scanned by CompileTask::metadata_do or ciEnv::metadata_do, but I think that can wait until JDK-8254110 too.

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

Marked as reviewed by dlong (Reviewer).

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