[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 23:26:08 EST 2015


I don't think it's needed for correctness in these examples, but I can see
people adopting try/finally forms as a way to "outline" the lifetime
extension and not mix it in with the core logic.  This also helps in
ensuring code refactoring does not inadvertently place code that needs
lifetime extension after reachabilityFence by mistake.

On Tue, Dec 8, 2015 at 10:40 PM, Justin Sampson <jsampson at guidewire.com>
wrote:

> Vitaly Davidovich wrote:
>
> > > public ByteBuffer put(int i, byte x) {
> > >     try {
> > >         unsafe.putByte(ix(checkIndex(i)), ((x)));
> > >         return this;
> > >     } finally {
> > >         Fences.reachabilityFence(this);
> > >     }
> > > }
> >
> > Yes. This also reminds me that default inlining size needs to be
> > reconsidered in light of changes like the above. Putting
> > try/finally {reachabilityFence(this)} adds about 14 bytes of
> > bytecode alone, which may make some methods go over the default
> > MaxInlineSize threshold.
>
> Is the try/finally necessary? How about instead:
>
> public ByteBuffer put(int i, byte x) {
>     unsafe.putByte(ix(checkIndex(i)), x);
>     Fences.reachabilityFence(this);
>     return this;
> }
>
> public int get(int i) {
>     int result = unsafe.getByte(ix(checkIndex(i)));
>     Fences.reachabilityFence(this);
>     return result;
> }
>
> Cheers,
> Justin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151208/c1ed77b6/attachment.html>


More information about the Concurrency-interest mailing list