RFR: Add generations to freeset [v20]

Kelvin Nilsen kdnilsen at openjdk.org
Sat Apr 29 13:49:55 UTC 2023


On Sat, 29 Apr 2023 01:04:13 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 41:
>> 
>>> 39: 
>>> 40: class ShenandoahSetsOfFree {
>>> 41:   friend class ShenandoahFreeSet;
>> 
>> Is the friendliness necessary, or is this a case of leakage of abstraction. Could the requisite stuff just be made public? May be as I look more closely at uses of non-public methods by the friend, I'll understand why the friendliness seems necessary. It'd be good to document that, if nothing else. That process of documentation itself might make one see a better approach.
>
> Hmm, wait, the only non-public method is `clear_internal` which is anyway exposed via `clear_all`. 
> 
> In that case, is the friend accessing a private data member field? 
> 
> Or perhaps the friend annotation is now obsolete from an earlier round of development and must now be removed.

You are correct that I no longer need the friend class.  In a previous version of the code, I had an assert on ShenandoahFreeSets::clear_all() that was not appropriate for all calls (in particular the initialization call) from ShenandoahFreeSet::clear_internal().  I'll make this change. (hmmm. Or should I put that assert_heaplocked()) back into ShenandoahFreeSets::clear_all()?)

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/250#discussion_r1181081071


More information about the shenandoah-dev mailing list