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