Spin Loop Hint support: Draft JEP proposal

[John Rose]

On Oct 5, 2015, at 2:41 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> Hi Gil,
> 
> On 04/10/15 17:22, Gil Tene wrote:
> 
>> Summary
>> 
>> Add an API that would allow Java code to hint that a spin loop is
>> being executed.
> 
> 
> I don't think this will work for ARM, which has a rather different
> spinlock mechanism.
> 
> Instead of PAUSE, we wait on a lock word with WFE.  WFE puts a core
> into a lightweight sleep state waiting on a particular address (the
> lock word) and a write to the lock word wakes it up.  This is very
> useful and somewhat analogous to 86's MONITOR/MWAIT.
> 
> I can't immediately see how to generalize your proposal to ARM, which
> is a shame.

Suggestion:  Allow the hint intrinsic to take an argument, from which
a JIT can infer a memory dependency (if one is in fact present).

Even if we are just targeting a PAUSE instruction, I think it is helpful
to the JIT to add more connection points (beyond control flow) between
the intrinsic and the surrounding loop.

class jdk.internal.vm.SpinLoop {
    /** Provides a hint to the processor that a spin loop is in progress.
     *  The boolean is returned unchanged.  The processor may assume
     *  that the loop is likely to continue as long as the boolean is false.
     *  The processor may pause or wait after a false result, if there is
     *  some reason to believe that the boolean argument, if re-evaluated,
     *  will be false again.  Any pausing behavior is system-specific.
     *  The processor may not pause indefinitely.
     *  <p>Example:
     * <blockquote><pre>{@code
MyMailbox mb = …;
while (true) {
  if (!pollSpinExit(mb.hasMail())  continue;
  Object m = mb.getMail();
  if (m != null)  return m;
}
     * }</pre></blockquote>
     * /
   @jdk.internal.HotSpotIntrinsicCandidate 
    public static boolean pollSpinExit(boolean spinExit) { return spinExit; }
}

I'm going to guess that the extra hinting provided by the parameter would
make it easier for a JIT to generate MWAIT and WFEs.

Also, the boolean argument is easy to profile in the interpreter, if that's what
a VM wants to do.

For a similar mechanism (which again uses a boolean to provide IR
connection to a data dependency), see:

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/fe40b31c0e52/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l697 <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/fe40b31c0e52/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#l697>

In fact, something like the profileBoolean intrinsic might be useful to allow
spin loops to gather their own statistics.  Getting the array allocation right
might require an invokedynamic site (or some equivalent, like a static
method handle), in order to control the allocation of profile state per call site.

HTH
— John

P.S. I agree with others that this needs cooking, in a jdk.internal place,
before it is ready for SE.