Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization
Roger.Riggs at Oracle.com
Wed Nov 25 15:45:38 UTC 2015
Seems like a reprise from September of "Suggested fix for JDK-4724038
(Add unmap method to MappedByteBuffer)".
Prompt cleanup can't rely on GC.
On 11/25/2015 10:31 AM, Peter Levart wrote:
> 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. ;-)
> Regards, Peter
More information about the core-libs-dev