Hi Paul,
> There is a very valid concern, since @Contended changes object layout and > increases object size, liberal use might tickle an overflow in HotSpot > code. Hence why it has remained internal so far. What overflow? OOM of the heap? How is that a "very valid" concern? Why would it be used liberally? Why are you allowing users to allocate any memory whatsoever? Why not put a cap on the size of objects non-JDK code can allocate? :) I mean seriously, with all due respect, the occasional "our users are dumb and misinformed" sentiment is very off-putting. If you think there are, currently, *implementation* issues with how @Contended is handled in the VM which cannot be addresses, I'll buy that. But can we please stop with the dumbing down? :) On Thu, Nov 12, 2015 at 8:23 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi, > > I don’t think anyone disagrees on the usefulness of @Contended. > > Beyond the JDK and 166 are there any more usages out there in the wild? > > I am not aware of any, grepcode does not report any usages outside of the > JDK, but we may have missed them. The current set of proposed critical > internal APIs have been derived from analyses of various collections of > code. This may in part be because it was only introduced in Java 8. > > Note that as currently proposed @Contended is not going away, it would > just be made inaccessible by default for anything not integrated into the > java.base module. A command line option is required to crack open the safe > [1]. > > There is a very valid concern, since @Contended changes object layout and > increases object size, liberal use might tickle an overflow in HotSpot > code. Hence why it has remained internal so far. > > One approach to mitigate such concern is to provide a -XX flag. There > happens to be one already available (that Aleksey pointed me to) :-) > RestrictContended, whose default value is true, such that by default > @Contended is ignored for anything other that stuff on the boot and > extension class loader [2]. So any current use outside of the JDK needs to > opt in with a command line argument. > > > My inclination would be continue with the conservative position for now > and provide an @sun.misc.Contended that aliases to the JDK internal, the > former of which requires -XX:-RestrictContended to function outside of > privileged code, and the latter of which will not function outside of > privileged code. > > I anticipate with Project Panama and Valhalla we are gonna seriously > hammer on the object layout mechanisms in HotSpot, and that may root out > any lurking issues, and thus we may be more comfortable supporting this in > a future public API (there is still the attractive nuisance argument, but > that one is much harder to solve...) > > Paul. > > [1] See the “Breaking encapsulation” section of > http://openjdk.java.net/jeps/261 > > [2] Note that the extension mechanism has been removed in JDK 9, see the > "Removed: The extension mechanism” section of > http://openjdk.java.net/jeps/220 > > > On 12 Nov 2015, at 01:17, Doug Lea <d...@cs.oswego.edu> wrote: > > > > On 11/11/2015 09:07 AM, Chris Hegarty wrote: > > > >> So I think the questions we need to answer are as follows: > >> a) Is it desirable to have @Contended as part of Java SE? > >> i) If so, is this doable for JDK 9? > >> b) If ‘No’ to a or i, do we consider @Contended “critical”, > >> as per JEP 260 ? > >> > > > > @Contended is something that only a very small number of developers > > directly use (sparingly), but the products of their efforts are used > > by many other developers. > > > > The "very small number" is still greater than the number of > > java.util.concurrent maintainers. As the use of concurrency expands, > > java.util.concurrent itself can't (and shouldn't) supply all possible > > specialized components needed in applications, so external libraries > > are needed to fill in the gaps. I'm sure that every developer of such > > concurrent components would vote to be able to use @Contended. > > > > I don't know of any argument not to expose it, beyond the usual > > concerns about supporting nichy esoteric stuff in jdk. Under the > > Unsafe-phase-out plans, public support for nichy esoteric stuff > > that has no other functional alternative will be more common. > > > > Without some good argument against it, I think the only issue > > is where (what package) to place it. Carrying it out from there seems > > identical to your webrev diffs, just changing import statements > > and the like. > > > > > > -Doug > > > > > > > > > > > >
