[concurrency-interest] Spin Loop Hint support: Draft JEP proposal

mark.reinhold at oracle.com mark.reinhold at oracle.com
Mon Feb 22 18:11:33 UTC 2016

2016/1/28 9:25 -0800, gil at azul.com:
> This thread seems to have "hopped away" to the concurrency-interest
> list in mid-Dec-2015. This posting is intended to capture a summary of
> reasoning and some of the discussion there so that we have it in the
> record in core-libs-dev. Mostly by including the contents of several
> posts in the continuations of the original thread.
> See thread continuations here:
> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14576
> and here:
> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14580
> Summary:
> ...

Thanks for the summary.

I still don't buy the argument that this method belongs in j.l.Runtime.

To say that this method should go there because it's an instruction to
the run-time system is pretty weak.  I agree with Vitaly [1] that if
that's the threshold for adding methods to the Runtime class then lots
of other stuff belongs there as well, including much of what's now in
java.lang.Thread and java.util.concurrent and, arguably, anything else
related to interacting with the environment in which the application
runs (file and network I/O, process manipulation, etc.).

This thread-related method really belongs in either java.lang.Thread or
java.util.concurrent.LockSupport.  j.l.Thread already has plenty of
expert-level static methods related to the current thread, one of which
(Thread::yield) is even a hint, just like this one.  j.u.c.LockSupport
is even more obviously intended for expert users and hence may be the
best choice, but I could live with either one.

- Mark

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038400.html

More information about the core-libs-dev mailing list