Re: [9] RFR of 8032027: Add BigInteger square root methods
Joe / Andrew / Louis, Following up on the thread regarding https://bugs.openjdk.java.net/browse/JDK-8032027. I revised the algorithm similarly to what Louis suggested for the initial value of the iteration. I also tightened up the memory usage. The updated version is here: http://cr.openjdk.java.net/~bpb/8032027/webrev.01/ I did not at this time change the algorithm to compute the reciprocal of the square root instead of the root directly as Andrew suggested. Apparently this would improve the rate of convergence from quadratic to cubic, but I am inclined to file this and the Karatsuba square root as two separate issues for future enhancement. Likewise I did not yet include the special case which Joe mentioned for tuning performance for n < 2^1023 wherein the spread of unity bits is sufficiently small. If this does not make it into the current round of revisions a separate enhancement issue may likewise be filed. Thanks, Brian
RFR 9 : 8138824 : java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches()
Hi, Please review my doc/spec change (no code) for 8138824. Bug: https://bugs.openjdk.java.net/browse/JDK-8138824 Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/ Specdiff: http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html This change addresses a longstanding mismatch between spec and implementation, clarifies comparison methods which do not account for locale, and adds references to the locale-aware java.text.Collator. Thanks, -Brent
Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null
On 7 October 2015 at 23:24, Roger Riggs wrote:
> Please consider and comment:
>
> T nonNullOf(T obj, T defaultObj);
> T nonNullOf(T, obj, Supplier defaultSupplier);
>
> Details are in the updated webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/
I think I can live with that name.
The Javadoc for the supplier variant needs to mention that an NPE is
thrown if the supplier itself is null.
@throws NullPointerException if {@code obj} is null and either {@code
supplier} is null or the {@code supplier.get()} value is {@code null}
Stephen
Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null
Hi, The original intent was to simplify the filling in of default values (even if null). I took Remi's point about the canonical coalescing operator not always returning non-null but the push seems to be in the direction of making sure the result is always non-null. I'd rather add a few very useful methods and avoid those with diminishing returns. I note that nulls are discovered eventually, but doing more aggressive checking is preferred. I expect the compiler is able to squeeze out all the extra checks. In the current context of Objects that the jdk, I read the naming pattern of firstNonNull to imply access to some sequential data structure like an array or list; but it doesn't gel with me to apply it to the arg list (unless it was varargs). The pattern of naming us "of" as being factory producing an object from the arguments seems apropos and is concise. Please consider and comment: T nonNullOf(T obj, T defaultObj); T nonNullOf(T, obj, Supplier defaultSupplier); Details are in the updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ Regards, Roger On 10/6/2015 6:42 PM, Remi Forax wrote: Null coalescing is a popular operator in several languages [1] and the usual semantics is nullOrElse and not firstNonNull. In languages like Kotlin or Swift, because there is a distinction between Object and Object?, it's not a big deal, you can not de-reference null by error, anyway. Also note that nullOrElseGet, the one that takes a supplier also exists in Groovy and Kotlin under the name null safe navigation. So even if i prefer the semantics of firstNonNull, i think we should also include both nullOrElse and nullOrElseGet. regards, Rémi [1] https://en.wikipedia.org/wiki/Null_coalescing_operator -
Re: Spin Loop Hint support: Draft JEP proposal
On Oct 5, 2015, at 2:41 AM, Andrew Haley 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.
* Example:
* {@code
MyMailbox mb = …;
while (true) {
if (!pollSpinExit(mb.hasMail()) continue;
Object m = mb.getMail();
if (m != null) return m;
}
* }
* /
@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
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.
Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils
On 07/10/2015 20:57, Chris Hegarty wrote: : I updated Connection with a readFully that has the same semantics as IOUtils. http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ I agree with Roger. Couldn't this be changed to use create an array of length seqlen and use readNBytes? -Alan
Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils
Hi, Yea, but now we have duplicated code... Does it ever go away? Roger On 10/7/2015 3:57 PM, Chris Hegarty wrote: On 7 Oct 2015, at 20:15, Chris Hegarty wrote: On 7 Oct 2015, at 20:04, Alan Bateman wrote: On 07/10/2015 19:19, Chris Hegarty wrote: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, It certainly would be nice. could that one be fixed? I didn’t look too hard at this because sun.security.util is already exported to java.naming, but yes I could write a readFully variant that works for this. I’ll take a closer look. I updated Connection with a readFully that has the same semantics as IOUtils. http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ -Chris.
RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)
Hello, Actually I am searching through the JBS for low hanging fruits. Right now i am looking through the openjdk-sources and try to evaluate if i can make something about JDK-5108778. Please find my webrevs for the jdk, jaxp, jaxws and corba repos at: http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/jaxp/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/jaxws/webrev.00/ http://cr.openjdk.java.net/~sebastian/5108778/corba/webrev.00/ I hope for jaxp,jaxws and corba this mailinglist is also the right place. jdk: The Boolean constructors are @Deprecated now so that we get compile-warnings for the uses. See also [0] and [1] jaxp: For the change in XBoolean (jaxp) i thought it would be more readable than the autoboxing solution. jaxws: The changes in jaxws are in a generated class. I would love to fix this in the source, but i have no clue where the real source could be. corba: For all calls against com.sun.tools.corba.se.idl.constExpr.Expression.value(Object) i used the valueOf solution instead of the autoboxing for better readability. For some general discussion on regression-tests for this please find the thread in discuss[0][1] and for the general suggestion to make more wrapper-type-constructors deprecated find [2] at core-libs-dev. [0] http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html -- Sebastian
Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils
On 7 Oct 2015, at 20:15, Chris Hegarty wrote: > On 7 Oct 2015, at 20:04, Alan Bateman wrote: > >> On 07/10/2015 19:19, Chris Hegarty wrote: >>> This primary motivation behind this bug [1] is the clearing out of >>> sun.misc, in preparation for JEP 260 [2]. >>> >>> >> It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use >> sun.security.util.IOUtils, > > It certainly would be nice. > >> could that one be fixed? > > I didn’t look too hard at this because sun.security.util > is already exported to java.naming, but yes I could > write a readFully variant that works for this. I’ll take a > closer look. I updated Connection with a readFully that has the same semantics as IOUtils. http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ -Chris.
Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils
On 7 Oct 2015, at 20:04, Alan Bateman wrote: > On 07/10/2015 19:19, Chris Hegarty wrote: >> This primary motivation behind this bug [1] is the clearing out of >> sun.misc, in preparation for JEP 260 [2]. >> >> > It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use > sun.security.util.IOUtils, It certainly would be nice. > could that one be fixed? I didn’t look too hard at this because sun.security.util is already exported to java.naming, but yes I could write a readFully variant that works for this. I’ll take a closer look. > The rest look fine. Thanks. -Chris. > -Alan
Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils
On 07/10/2015 19:19, Chris Hegarty wrote: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use sun.security.util.IOUtils, could that one be fixed? The rest look fine. -Alan
Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils
Hi Chris, Looks fine. The change in exception message is more informative than the previous exception message. Roger On 10/7/2015 2:19 PM, Chris Hegarty wrote: This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is a JDK internal convenience utility class that provides a single method that offers bulk blocking InputStream read semantics. In 9, java.io.InputStream has been retrofitted with two methods that provide similar, but not quite the same, functionality, readNBytes and readAllBytes, see JDK-8080835 [3]. There are a number of places where IOUtils can be replaced with the appropriate supported API, readNBytes or readAllBytes. There are a number of places, mainly in the security implementation, that required to read a specific number of bytes ( not to end of stream ), where it is preferable to not preallocate the byte[] and allow it to "grow" lazily, to be defensive against protocol errors. These cases cannot use read[N|All]Bytes, so it makes sense to retain IOUtils but locate it in a package, sun.security.util, that makes it clear who its primary consumer is. http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8138978 [2] https://bugs.openjdk.java.net/browse/JDK-8132928 [3] https://bugs.openjdk.java.net/browse/JDK-8080835
RFR [9] 8138978: Examine usages of sun.misc.IOUtils
This primary motivation behind this bug [1] is the clearing out of sun.misc, in preparation for JEP 260 [2]. sun.misc.IOUtils is a JDK internal convenience utility class that provides a single method that offers bulk blocking InputStream read semantics. In 9, java.io.InputStream has been retrofitted with two methods that provide similar, but not quite the same, functionality, readNBytes and readAllBytes, see JDK-8080835 [3]. There are a number of places where IOUtils can be replaced with the appropriate supported API, readNBytes or readAllBytes. There are a number of places, mainly in the security implementation, that required to read a specific number of bytes ( not to end of stream ), where it is preferable to not preallocate the byte[] and allow it to "grow" lazily, to be defensive against protocol errors. These cases cannot use read[N|All]Bytes, so it makes sense to retain IOUtils but locate it in a package, sun.security.util, that makes it clear who its primary consumer is. http://cr.openjdk.java.net/~chegar/8138978/webrev.00/jdk/ http://cr.openjdk.java.net/~chegar/8138978/webrev.00/hotspot/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8138978 [2] https://bugs.openjdk.java.net/browse/JDK-8132928 [3] https://bugs.openjdk.java.net/browse/JDK-8080835
Re: Array equality, comparison and mismatch
On 7 Oct 2015, at 16:55, Paul Sandoz wrote:
>
>> On 6 Oct 2015, at 10:58, Chris Hegarty wrote:
It was not immediately obvious to me that the common prefix can be 0.
Should this be called out specifically?
>>>
>>> When reading the documentation of compare or mismatch or both?
>>
>> mismatch. But maybe this is just me.
>>
>
> I could add something following the paragraph defining the common prefix:
>
> Note that a common prefix length of {@code 0} indicates that the first
> elements from each array mismatch.
Thanks, that makes it explicit.
-Chris.
> Paul.
Re: Spin Loop Hint support: Draft JEP proposal
On 10/07/2015 04:45 PM, Gil Tene wrote: > For ARM, I expect WFE/SEV to need to evolve as well, and for other > reasons, even fit use within OSs. The current WFE/SEV scheme is not > scalable. While it probably works ok for spinning at the kernel > level on hardware that only has s handful of cores, the fact that > the event WFE waits for (and SEV sends) is global to the system will > break things as core counts grow (it is the hardware equivalent of > wait/notifyAll() with a single global monitor). That's not how it works. It's sufficient to write to the lock word to wake a core from a WFE: SEV is not required. Each core has its own event monitor, and wakeup is handled by the cache coherency logic. Andrew.
Re: Array equality, comparison and mismatch
> On 6 Oct 2015, at 10:58, Chris Hegarty wrote:
>>> It was not immediately obvious to me that the common prefix can be 0.
>>> Should this be called out specifically?
>>>
>>
>> When reading the documentation of compare or mismatch or both?
>
> mismatch. But maybe this is just me.
>
I could add something following the paragraph defining the common prefix:
Note that a common prefix length of {@code 0} indicates that the first
elements from each array mismatch.
Paul.
Re: Spin Loop Hint support: Draft JEP proposal
On 10/07/2015 04:45 PM, Gil Tene wrote: > In any case, even if it were user-mode-accessible, MWAIT may not appropriate > for latency-sensitive spinning because it can apparently take 1000s of cycles > to come out of the C-state modes it goes into. Oh, yuck. OK, forget it. Thanks, Andrew.
Re: Spin Loop Hint support: Draft JEP proposal
Sent from Gil's iPhone > On Oct 7, 2015, at 1:14 AM, Andrew Haley wrote: > >> On 05/10/15 21:43, Gil Tene wrote: >> >> I see SpinLoopHint as very separate from things like MONITOR/WAIT >> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice >> way until this state changes" instructions that other architectures >> may have or add. >> >> Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to >> potentially wait for specific state changes to occur. As such, they >> can be used to implement a specific form of a spin loop (the most >> common one, probably). But they do not provide for generic spinning >> forms. E.g. loops that have multiple exit conditions in different >> memory locations, loops that wait on internal state changes that are >> no affected by other CPUs (like "spin only this many times before >> giving up" or "spin for this much time"), and loops that may use >> transactional state changes (e.g. LOCK XADD, or wider things with >> TSX) are probably "hard" to model with these instructions. > > Yes, you're right: there's no real way to combine these things, and > support for WFE requires some other kind of interface -- if I ever > manage to think of a nice way to express it in Java. So, my > apologies for hijacking this thread, but now you've got me thinking. > > In an ideal world there would be a timer associated with WFE which > would trigger after a short while and allow a thread to be > descheduled. However, it is possible to set a periodic timer which > regularly signals each worker thread, giving it the opportunity to > block if unused for a long time. This should make a much more > responsive thread pool, so that when worker threads are active they > respond in nanoseconds rather than microseconds. The problem with using timer based interrupts to kick out of WFE or MWAIT situations is that the granularity is often too thin for timers (and interrupts). E.g. j.u.c often uses "magic number of spins" of 64 or so before backed my out of the spin. That's just too short to get a timer going (and canceled) in, and the overhead of interrupt handling will overwhelm the actual action being attempted. "What we really need" for WFE/MEAIT hardware instructions to be useful in this space (of spin-for-bit-before-giving-up) is for the instructions to take a timeout argument (e.g. # of clock cycles. A power of two would probably suffice, so not slot of bits needed). But that's just not how they work on current HW... > > [ An aside: WFE is available in user mode, and according to Intel's > documentation it should be possible to configre an OS to use > MONITOR/WAIT in user mode too. I don't know why it doesn't work. ] While there are some ambiguous suggestions that MONITOR/MWAIT may be available in CPLs above 0 in some documentation, the current documentation for the actual MWAIT instruction is pretty clear about it only working in privilege level 0. So maybe this will be relaxed in the future? In any case, even if it were user-mode-accessible, MWAIT may not appropriate for latency-sensitive spinning because it can apparently take 1000s of cycles to come out of the C-state modes it goes into. At those level, you may be better off blocking or yielding, and no one would make use of it if they care about quick reaction time. It may be that it's not that bad, depending on the cstate requested, but the fact that Linux kernels don't currently use MWAIT for spin loops suggests that it not good for that use case yet. For ARM, I expect WFE/SEV to need to evolve as well, and for other reasons, even fit use within OSs. The current WFE/SEV scheme is not scalable. While it probably works ok for spinning at the kernel level on hardware that only has s handful of cores, the fact that the event WFE waits for (and SEV sends) is global to the system will break things as core counts grow (it is the hardware equivalent of wait/notifyAll() with a single global monitor). I expect that for OSs to use it for spinning on many-core systems, there would need to be some de-muxing capability added (e.g. by address or by some id). In its current form, it is probably not ready for exposure to user mode code. (Imagine what would happen if user code started doing system-wide SEVs on every unlock).
Re: JEP 264: Platform Logging API and Service
Hi, I have pushed an implementation of the prototype in the sandbox. The branch name is JDK-8046565-branch Instructions for cloning a sandbox branch can be found here: http://cr.openjdk.java.net/~chegar/docs/sandbox.html best regards, -- daniel On 05/10/15 12:54, Daniel Fuchs wrote: New JEP Candidate: http://openjdk.java.net/jeps/264 Hi I have uploaded an initial prototype specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html LoggerFinder methods that take a Class caller argument will take a java.lang.reflect.Module callerModule instead when that is available in jdk9/dev. comments welcome, best regards, -- daniel
RFR(xxs): 8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing
Hi, please review and sponsor this AIX fix. in ResolverConfigurationImpl.c, we may crash because strchr() is used without prototype, which causes the C compiler to default to an int return type, which means we loose the upper 32bit of the pointer returned by strchr(). The solution is to include string.h. Before, string.h was conditionally included for all platforms but AIX - reason is not really clear to me. But as strchr() is POSIX and always in string.h, I included string.h unconditionally for all Unices. webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8139037/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8139037 Kind Regards, Thomas
Re: JEP 269: Convenience Factory Methods for Collections
The current guideline seems to be that new collections introduced after Java 4 should not allow null. ArrayDeque is an example of such collections. This proposal introduces new static methods on both interfaces and implementations. Interface static methods use new immutable collections, if those doesn't support null, a user can easily switch to the static method on one of the corresponding implementation class. By example, instead of using List.of (null), one can use ArrayList.of (null). That's why i think it's fine to not allow null in new immutable collections. regards, Rémi Le 7 octobre 2015 02:13:30 CEST, Stuart Marks a écrit : > > >On 10/3/15 7:16 AM, fo...@univ-mlv.fr wrote: >> "Kevin Bourrillion" wrote: >>> We have ~1800 occurrences of Optional-valued Maps or Caches in >Google. They >>> do this for an actual reason: a negative result is meaningfully >different >>> from no result. This is addressed in our Optional javadoc . >> >> mapped-to-absent means that you know the keys you are waiting for, so >you can store them in an external set (list, etc) and enjoy >implementations like EnumMap or the couple JSObject/HiddenClass you >found in most javascript engines. >> Using Optional for that seem inefficient. > >Indeed, the Optional docs that Kevin linked to themselves have links to >other >pages that describe techniques for avoiding use of nulls and Optionals >in cases >such as this. Nonetheless, as Kevin points out, there are 1,800 such >usages in >Google's code base. > >And personally, as a matter of style, I dislike using Optional in >collections. > >My question is, is this enough of a problem that we should allow nulls >in these >collections? I would prefer not to do this, but if there is evidence >that this >would be a mistake, I'd like to hear it. > >And if disallowing nulls will cause developers to create things like >Map>, are we ok with that, and are developers ok with >that? > >s'marks
Re: JEP 269: Convenience Factory Methods for Collections
On 7 Oct 2015, at 10:30, Stephen Colebourne wrote: > On 7 October 2015 at 01:13, Stuart Marks wrote: >> My question is, is this enough of a problem that we should allow nulls in >> these collections? I would prefer not to do this, but if there is evidence >> that this would be a mistake, I'd like to hear it. >> >> And if disallowing nulls will cause developers to create things like >> Map>, are we ok with that, and are developers ok with that? > > Given what we know now vs when the collections library ws created, I > think it would be a mistake to allow nulls. Developers that > desperately want null in there have other mechanisms to achieve that, > not just Optional. I agree with this. These are, after all, “just convenience” methods, there are other ways if null is required. I do not see any compelling reason for allowing null, given the type of use case these methods are trying address, collections and maps with small numbers of elements. > I too would argue against Optional in collections, > at least until value types exist, but thats a social discussion, not > one that can be controlled. > > Stephen -Chris.
Re: JEP 269: Convenience Factory Methods for Collections
On 7 October 2015 at 01:13, Stuart Marks wrote: > My question is, is this enough of a problem that we should allow nulls in > these collections? I would prefer not to do this, but if there is evidence > that this would be a mistake, I'd like to hear it. > > And if disallowing nulls will cause developers to create things like > Map>, are we ok with that, and are developers ok with that? Given what we know now vs when the collections library ws created, I think it would be a mistake to allow nulls. Developers that desperately want null in there have other mechanisms to achieve that, not just Optional. I too would argue against Optional in collections, at least until value types exist, but thats a social discussion, not one that can be controlled. Stephen
Re: Spin Loop Hint support: Draft JEP proposal
On 05/10/15 21:43, Gil Tene wrote: > I see SpinLoopHint as very separate from things like MONITOR/WAIT > (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice > way until this state changes" instructions that other architectures > may have or add. > > Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to > potentially wait for specific state changes to occur. As such, they > can be used to implement a specific form of a spin loop (the most > common one, probably). But they do not provide for generic spinning > forms. E.g. loops that have multiple exit conditions in different > memory locations, loops that wait on internal state changes that are > no affected by other CPUs (like "spin only this many times before > giving up" or "spin for this much time"), and loops that may use > transactional state changes (e.g. LOCK XADD, or wider things with > TSX) are probably "hard" to model with these instructions. Yes, you're right: there's no real way to combine these things, and support for WFE requires some other kind of interface -- if I ever manage to think of a nice way to express it in Java. So, my apologies for hijacking this thread, but now you've got me thinking. In an ideal world there would be a timer associated with WFE which would trigger after a short while and allow a thread to be descheduled. However, it is possible to set a periodic timer which regularly signals each worker thread, giving it the opportunity to block if unused for a long time. This should make a much more responsive thread pool, so that when worker threads are active they respond in nanoseconds rather than microseconds. [ An aside: WFE is available in user mode, and according to Intel's documentation it should be possible to configre an OS to use MONITOR/WAIT in user mode too. I don't know why it doesn't work. ] Andrew.
Re: Spin Loop Hint support: Draft JEP proposal
> On Oct 6, 2015, at 6:50 PM, Joseph D. Darcy wrote: > > > On 10/6/2015 6:28 PM, Gil Tene wrote: >>> On Oct 6, 2015, at 1:02 PM, Doug Lea wrote: >>> >>> On 10/04/2015 12:22 PM, Gil Tene wrote: I would like to circulate this draft JEP proposal for initial review and consensus building purposes. >>> Some background: about two years ago, Dave Dice and I put together >>> a pre-jep proposal for JVM support for recent CPU features covering: >>> >>> (1) MWAIT/PAUSE/etc (for spins as well as other uses people have noted); >>> (2) Core topology/neighborhood information and; >>> (3) 2CAS, as a foothold on HTM that could still be reasonably efficient >>> on non-transactional processors. >>> >>> My understanding of the result of this effort was that Oracle JVM engineers >>> didn't think they had resources to do this for jdk9. It didn't occur to >>> me that non-Oracle contributors might want to cherry-pick one (some >>> of (1) above). It seems plausible to do this, but only if designed >>> as the first of some possible enhanced support along these lines. >> Good point. But that's what an actual community is about. Isn't it? >> >> We (Azul) are volunteering the resources for spinloopHint(). Including >> experimentation, implementation, testing, and even a TCK (which in this case >> will be trivial). So the vast majority of resources needed will not be coming >> other budgeted jdk9 resources. >> >> I certainly recognize that there will still be work involved that others will >> end up having to do: reviewing, arguing, contributing opinions, etc., as well >> as integrating the work into the whole. But this specific proposed JEP is >> about >> as narrow and low risk as you can get. especially from a specification point >> of >> view (e.g. intrinsic implementation can be left under a flag if deemed risky >> to >> stability or schedule). >> >> As for fitting in with larger-picture or theme things (listed above). I >> think that >> agonizing over the choice of where to put this is important (e.g. the >> Thread.spinLoopHint() >> idea, or a create new class that other hints will go into in the future, and >> where?). >> But I don't think that there is good reason to bundle this work with e.g. >> 2CAS, HTM, >> and affinity. Work. While we can think of them all as "support for recent >> CPU features", >> they are very different (and probably have multiple other unrelated >> groupings). >> >> MWAIT (and the like) and PAUSE do deserve some co-thinking (see earlier >> discussion >> on the thread). So does a discussion about a capturing abstraction like >> synchronic >> (raised in concurrency interest), But given the actual common uses already >> waiting >> for a spinLoopHint(), the very tangible and immediate benefit it shows, and >> the fact that >> most of the use cases wouldn't be able to make use of MWAIT (or the like), >> and some >> won't be able to use a synchronic-like thing, I think that either a >> spin-hint-only JEP >> is not just a good "shortcut", but also an actual stand-alone feature need. >> > > Taking a long-term view, it seems to me premature to burn this kind of hint > into the Java SE API (effectively) forever in the absence of experience that > the hint in this form is useful and will continue to be useful in 5 years, 10 > years, etc. > > If the hint started out as a JDK-specific API, there would be (some) more > room to modify or drop the API in the future, leaving open the possibility of > migrating the functionality to the Java SE API too. > > -Joe While I don't disagree with the need for long term thinking, I think this JEP represents exactly that. It is hardly "premature". "Very late" is probably a much better description. There is overwhelming evidence and experience showing that this exact form of hint is useful, and will likely continue to be useful for a decade or more. Spin hinting isn't something new. This hint technique (include an explicit instruction or function call hinting that you are in a spin loop) has been dominantly and beneficially used for over a decade in virtually all spinning code *other* than Java. E.g. Linux (and probably all other OSs) uses this for virtually all kernel spinning situations on x86 and PowerPC. POSIX libraries do so too in mutexes and semaphores in user mode. Even the JVM's own custom C++ spinning code has been doing it for many years. It is only pure Java code that has been deprived this ability for the past decade. And in the many-core world we've been living in for at least 5 years, even on commodity hardware, the lack really hurts. This JEP is a fairly late reaction to the very patient requests of a substantial set of Java developers. The community of people doing performant messaging and latency sensitive stuff with Java has been asking for this for a long time as well. Usually with variants of sentences like "Our C and C++ versions of these things use a PAUSE instruction, but in Java we hav
