RFR: 8133051: Concurrent refinement threads may be activated and deactivated at random
Kim Barrett
kim.barrett at oracle.com
Wed Apr 6 02:12:11 UTC 2016
> On Apr 5, 2016, at 6:31 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>
> I saw that this review is on hold. Just want to offer a suggestion (if it isn't
> already there - I only had a cursory look). In run_service() count the
> number of buffers processed and report that number in the deactivate
> logging.
Sure. I was planning to collect that information anyway in a future improvement.
We need to improve the mechanics of deciding when and how many concurrent
refinement threads to run. Part of that is going to involve collecting information
about the estimated rate at which the threads process buffers.
I re-ran specjbb2015 locally, and the latest set of changes to accommodate smaller
machines also has the desired improvement for larger machines; keeping the number
of buffers close to the green zone value seems to be just generally beneficial, allowing
the green zone to grow significantly because there are fewer missed update_rs targets.
Future improvements to the control law being used there should be able to smooth out
some of the still present lumpiness, making it even more predictable.
More information about the hotspot-gc-dev
mailing list