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

David M. Lloyd david.lloyd at redhat.com
Mon Feb 22 18:24:38 UTC 2016

On 02/22/2016 12:11 PM, mark.reinhold at oracle.com wrote:
> 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.

I agree, and I would also point out (perhaps redundantly?) that there 
was talk on concurrency-interest of possibly relocating or replicating 
the park/unpark statics into j.l.Thread, which further strengthens the 
idea that Thread is the best place for things like this.


More information about the core-libs-dev mailing list