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

David Holmes davidcholmes at aapt.net.au
Wed Oct 8 23:16:28 EDT 2014


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



More information about the Concurrency-interest mailing list