[concurrency-interest] DirectByteBuffers and reachabilityFence

Gil Tene gil at azul.com
Wed Dec 9 14:07:37 EST 2015


> On Dec 9, 2015, at 10:48 AM, Alexandre De Champeaux <adc at quartetfs.com> wrote:
> 
> 
> Ok, I buy that.  I can't help but wonder how DBB authors decided it's ok to release it to the public like this though.  Granted, I can't think of a (realistic) scenario where allocating a DBB that's immediately garbage is normal.
> 
> I don't see why only DBB that are immediately garbage would be affected.

Like Alexandre, the current bug-tripping scenario that keeps me up at night is not the strange allocate-and-immediate-garbage case, but the last-use case. As in the behavior of the last get or put into a buffer that has been around for a while. These last accesses currently race with the cleaner's execution, and can result in reading from or writing to free'd (and potentially already allocated elsewhere) memory.

I believe that the reason this is "rare" dynamically is that most DBB uses we run into make fairly static use of DBBs, either managing their internal contents themselves (in various off heap memory patterns) or using them as a long lasting communications buffer (in various io and JNI setups). These use cases usually contain the race's exposure to the rare end-of-life events of the DBB, which often coincide with the program's end-of-life. Basically, the likelihood of completing a GC and running the cleaner within the race window, coupled with the actual access to the freed memory causing some actual problem (a SEGV or bad data being read that actually affects the program's behavior) in these situations is not 0, but is "fairly low".

But then there are the applications that make heavy dynamic use of DBBs, allocating and releasing them constantly. I'm dealing with one such app that is doing this with multiple TB of DBB managed memory, in tons of little chunks that come and go all the time, and some significant GC pressure as well, and it's those sort of apps that IMO are currently exposed to the inherent last-use race in DBB.

— Gil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/89e18762/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/89e18762/attachment.bin>


More information about the Concurrency-interest mailing list