Spin Loop Hint support: Draft JEP proposal

Vitaly Davidovich vitalyd at gmail.com
Tue Oct 6 14:12:24 UTC 2015

Although spin lock would also benefit from this, the spinning is also done
when doing message hand off between threads.  It's common in low latency
space to monopolize the cpu(s) and spin wait for data to arrive; this is to
avoid parking the thread in kernel when you know arrival rate is very high.

As for j.u.c. I believe StampedLock had some manual spinning and uses
ThreadLocalRandom to create artificial mispredicts to prevent speculative
pipeline from filling up (basically simulating pause like instruction).

sent from my phone
On Oct 6, 2015 4:17 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 06/10/15 05:32, Gil Tene wrote:
> > I don't think of this as platform specific. And it's not much lower
> > level than e.g. some java.util.concurrent stuff (but probably
> > doesn't belong in that package because it's not really about
> > concurrency). I'm looking for a proper Java SE spec'ed way to do
> > this. So sun.misc.* won't work. I'm sure we don't want another
> > Unsafe for people to abuse...
> >
> > But naming the class and method is the smaller, easier detail. Right? ;-)
> Sure.  I would have thought, though, that java.util.concurrent was a
> natural home for this.  Is there any kind of userland spinlock which
> is not about concurrency?
> Andrew.

More information about the core-libs-dev mailing list