On 9/25/19 6: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 know some like _jvmti_can_access_local_variables can affect the
generated code. See
https://github.com/openjdk/jdk/blob/c83c8515ebb4e49fb63c9b896581c9f056268aa0/src/hotspot/share/ci/ciEnv.hpp#L344
dl
I can remove these changes.
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
