On Sat, 22 Jun 2024 00:18:43 GMT, Coleen Phillimore wrote:
> The 'resolve' for the CLDG iterator was to temporarily keep that CLD from
> being unloaded, in the short time that we're iterating on that particular CLD.
This is the crux of the problem. For concurrent GCs, if the 'resolve' is
On Wed, 19 Jun 2024 15:06:25 GMT, Axel Boldt-Christmas
wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metadata alive. This is
On Thu, 20 Jun 2024 16:30:30 GMT, Coleen Phillimore wrote:
> If the default is to not keep the CLD alive, I don't like that we need the
> details of the side effect in the name. Just call it classes_do, etc. I don't
> care about no-keepalive in all these callers, if that's the right answer for
On Wed, 19 Jun 2024 15:06:25 GMT, Axel Boldt-Christmas
wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metadata alive. This is
On Wed, 19 Jun 2024 15:06:25 GMT, Axel Boldt-Christmas
wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metadata alive. This is
> ClassLoaderDataGraph provides APIs for walking different metadata. All the
> iterators which are not designed to be used by the GC also keep the holder of
> the CLDs alive and by extensions keeps all metadata alive. This is
> problematic for concurrent GC as it keeps otherwise unreachable
