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

[Roger Riggs]

Hi,

Seems like a reprise from September of "Suggested fix for JDK-4724038 
(Add unmap method to MappedByteBuffer)".
Prompt cleanup can't rely on GC.

Roger


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. ;-)
>
>>
>> Andrew.
>
> Regards, Peter
>