[concurrency-interest] DirectByteBuffers and reachabilityFence

Peter jini at zeus.net.au
Thu Dec 10 21:47:17 EST 2015


Would another workaround be to use a phantom reference  for the DBB?

The memory isn't reclaimed by gc until the phantom reference is cleared or becomes reachable.

The phantom reference queue functionality could be implemented in static methods and fields.  Classes aren't gc'd until all classes in a ClassLoader and the ClassLoader itself becomes reachable.

Just curious.

Regards,

Peter.

Sent from my Samsung device.
  Include original message
---- Original message ----
From: Doug Lea <dl at cs.oswego.edu>
Sent: 11/12/2015 10:14:54 am
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] DirectByteBuffers and reachabilityFence

On 12/10/2015 07:56 AM, Andrew Haley wrote: 
> On 12/10/2015 12:51 PM, Vitaly Davidovich wrote: 
>> I can see a few reasons against extending `this` lifetime at this stage of 
>> java's life, but what were the objections last time(s) this came up? 
> 
> Basically twofold.  Mostly efficiency, but also a reluctance to change 
> long-settled language semantics.  Making changes to something as 
> fundamental as this is always much tricker than people expect.  The 
> great advantage of reachabilityFence is that we can do it without a 
> lot of complex argument and politics. 
> 

Like Andrew and others who have seen periodic protracted 
discussions of this issue over the past decade or so, I'm not 
too optimistic. 

But this is also one reason for considering a @Finalized annotation 
for fields (not classes!), that would give essentially this 
guarantee only in those cases it was requested. Compilers would 
translate methods/blocks accessing @Finalized field r 
(as in .. use(r); ...)  to  the equivalent of: 
   try { ... use(r); ... } finally { reachabilityFence(); } 

In the mean time, users can at least arrange this manually though. 
There is no reason to believe that the performance impact would 
be any different in manual vs automated forms, as long as some of 
us are willing to help hotspot minimize it. 

-Doug 


_______________________________________________ 
Concurrency-interest mailing list 
Concurrency-interest at cs.oswego.edu 
http://cs.oswego.edu/mailman/listinfo/concurrency-interest 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151211/4c0cde89/attachment.html>


More information about the Concurrency-interest mailing list