On 9/26/19 5:43 AM, [email protected] wrote:
Hi Coleen,
Could you please make the counter uint64_t instead? We usually use 64
bit unsigned counters when we don't want to think about overflow.
Otherwise I like the approach. Don't need another webrev... This looks
good.
You are right. I don't want to think about overflow for int for number
of redefinitions. I changed it to uint64_t and am rerunning tier1 on
Oracle platforms just to be sure.
http://cr.openjdk.java.net/~coleenp/2019/8226690.03/webrev
Thanks,
Coleen
Thanks,
/Erik
On 9/26/19 3:29 AM, [email protected] wrote:
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
