Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Peter Levart peter.levart at gmail.com
Wed Nov 25 15:31:36 UTC 2015


Changing the subject to not hijack the thread...

On 11/25/2015 01:54 PM, Andrew Haley wrote:
> On 11/25/2015 12:39 PM, Peter Levart wrote:
>> What do you think?
> It's very problematic.  First off, collection often clears the young
> generation altogether, promoting everything.

This could be a best-effort algorithm. If it must clear the young 
generation, it would. User would have to size it accordingly to 
accommodate for extra space needed by direct ByteBuffers staying in the 
young gen forever.

>    Secondly, I think we are
> already short of header bits in some cases.

How many bits are there for object age? 4 ? This means 16 values. If one 
value is "reserved" for eternally-young objects, there would still be 15 
values for normal operation.

>    Thirdly, this requires
> all collectors to be changed.

Why? For start, only the most popular collector used in those 
applications could be modified and the feature could be optional 
(guarded by switch). API calls would be no-ops in unsupported collectors 
or when the feature is not enabled.

>    Fourthy, some collectors don't use
> multiple generations: they can just allow a dense prefix to pile up at
> the left-hand end of the heap which they don't bother to collect.

Those would not be supported.

> Etc, etc...

Maybe. Would have to dive into VM to find out. ;-)

>
> Andrew.

Regards, Peter




More information about the core-libs-dev mailing list