RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

[Vitaly Davidovich]

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.sandoz at 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 <dl at 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
> >
> >
> >
> >
> >
>
>