[concurrency-interest] JSR-133 Cookbook and exit monitor

Vitaly Davidovich vitalyd at gmail.com
Thu Oct 9 09:16:47 EDT 2014


"Personally I opposed it on liveness grounds - I presume that if you wrote
two close but seperate sync blocks then you had a good reason to do so, most
likely relating to liveness."

That's true but sometimes (probably most) the coarsening opportunities fall
out of other optimizations, which may result in two sync blocks being back
to back and the programmer didn't write that.  We just have to trust that
compiler's cost model/heuristics enable it to make an appropriate decision.

Sent from my phone
On Oct 8, 2014 11:39 PM, "David Holmes" <davidcholmes at aapt.net.au> wrote:

> Thurston writes:
> > David Holmes-6 wrote
> > > Not only is it allowed, it can easily be performed by the JIT. If that
> > > seems
> > > "unhealthy" you will be really freaked out by lock-coarsening which can
> > > coalesce:
> > >
> > > synchronized(x) {
> > >  // aaa
> > > }
> > > // other code
> > > synchronized(x) {
> > >  // bbb
> > > }
> > >
> > > into
> > >
> > > synchronized(x) {
> > >   // aaa
> > >   // other code
> > >   // bbb
> > > }
> > >
> > > where anything in the sync block can of course be further reordered.
> > >
> > > Of course this can't be done arbitrarily but it can be done.
> > >
> > > Cheers,
> > > David Holmes
> > >
> > >>
> >
> > Thanks.
> > To be precise, there is a hb(aaa, bbb), surely that needs to be
> > respected in the rewritten *coalesced* code; as far as "other code",
> > anything goes I guess
>
> I don't believe hb has any impact here - as long as intra thread semantics
> are obeyed.
>
> Lock coarsening has been employed in hotspot for years now:
>
> http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.2
>
> Personally I opposed it on liveness grounds - I presume that if you wrote
> two close but seperate sync blocks then you had a good reason to do so,
> most
> likely relating to liveness.
>
> David
> -----
>
>
>
>
> >
> >
> >
> > --
> > View this message in context:
>
> http://jsr166-concurrency.10961.n7.nabble.com/JSR-133-Cookbook-and-exit-moni
> tor-tp11323p11328.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> 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/20141009/fe6af39c/attachment.html>


More information about the Concurrency-interest mailing list