<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 10:48 AM, Alexandre De Champeaux <<a href="mailto:adc@quartetfs.com" class="">adc@quartetfs.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><span class=""><div class=""></div></span><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">I don't see why only DBB that are immediately garbage would be affected.</div></div>
</div></div>
</div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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".</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">— Gil.</div></body></html>