On 9/25/19 9:21 PM, [email protected] wrote:
I see. I dumped the redefinition count in the replay data because I
saw the other fields were dumped there. Would they also not affect
the generated code?
I can remove these changes.
open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev
Rebuilt and retested with the ciReplay tests. Thank you for looking at
the change.
Coleen
Thanks,
Coleen
On 9/25/19 6:18 PM, [email protected] wrote:
Saving and restoring redefinition_count for compiler replay doesn't
make sense to me. It won't affect the generated code, and we
probably shouldn't even be installing/registering replay nmethods. I
would remove the ciEnv::dump_replay_data_unsafe() and
process_JvmtiExport() changes.
dl
On 9/25/19 7:33 AM, [email protected] wrote:
Summary: Dont create nmethod if classes have been redefined since
compilation start.
The bug was caused by a new nmethod created with an old Method in
the metadata section. Added verification (which hit on windows) and
NSV in the other place where the method can be replaced in the
nmethod metadata section.
There are some jvmci changes (to vmStructs_jvmci.cpp) that might be
needed also in the graal compiler.
Tested with tier1-6 and failing test 100 times.
open webrev at
http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8226690
Thanks,
Coleen
