Concurrent timer is called from both VMThread and ConcurrentMarkThread and this results in a race for ConcurrentGCTimer when abort happens.
The timer is mostly called from ConcurrentMark, so
it would be better to let ConcurrentMark have the timer and related codes(e.g. tracer).
And when abort happens, concurrent timer/tracer related things will not be ended by VM thread and it will done at the end of concurrent cycle.
This will change below things:
1. Start time of concurrent mark:
- current: when initial marking is decided
- this CR: when actual concurrent cycle starts
2. Heap summary trace:
- current: when initial marking is decided(before gc), when cleanup happens(after gc), when abort happens(after gc)
- this CR: when actual concurrent cycle is started(before gc), when actual concurrent cycle is ended(after gc).
This change will give much easier to control.
The timer is mostly called from ConcurrentMark, so
it would be better to let ConcurrentMark have the timer and related codes(e.g. tracer).
And when abort happens, concurrent timer/tracer related things will not be ended by VM thread and it will done at the end of concurrent cycle.
This will change below things:
1. Start time of concurrent mark:
- current: when initial marking is decided
- this CR: when actual concurrent cycle starts
2. Heap summary trace:
- current: when initial marking is decided(before gc), when cleanup happens(after gc), when abort happens(after gc)
- this CR: when actual concurrent cycle is started(before gc), when actual concurrent cycle is ended(after gc).
This change will give much easier to control.
- relates to
-
JDK-8151684 assert(_is_concurrent_phase_active) in TestStressRSetCoarsening
-
- Resolved
-
-
JDK-8151411 Proper GC cause for Concurrent tracer
-
- Closed
-
-
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-