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

[Paul Sandoz]

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
> 
> 
> 
> 
>