RFR: 8211718: Supporting multiple concurrent OopStorage iterators

Kim Barrett kim.barrett at oracle.com
Thu Oct 4 23:27:52 UTC 2018


> On Oct 4, 2018, at 9:53 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> 
> Hi,
> 
> OopStorage has an artificial restriction of having only one concurrent iterator at a time. This restriction should be removed.
> 
> The solution is to turn the bool that tracks concurrent iterations, into an int.
> 
> For some background, the reason for the restriction has historic reasons, from a time when opening OopStorage for concurrent iteration was done using a lock-free protocol between GC worker threads, which made it tricky. Since then, the model was simplified to just let the ParState RAII object open and close the concurrent iterations. With the simplified model, there is no need for such a restriction.
> 
> I talked to Kim, and long-term there are more plans in this area, such as removing weak_oops_do, and then unifying the iterators. But for now, I would like to just stop disallowing multiple concurrent iterations as one small step along the way.
> 
> I updated the relevant OopStorage documentation to reflect the removal of this restriction.
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8211718/webrev.00/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8211718
> 
> Thanks,
> /Erik

Looks good, so far as it goes.  However, maybe some renames are in order:

_concurrent_iteration_active => _concurrent_iteration_state
or
_concurrent_iteration_active => _concurrent_iteration_count
update_iteration_state => update_[concurrent_]iteration_count

And perhaps an assertion in the update function that it didn’t get updated to negative.




More information about the hotspot-gc-dev mailing list