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

[Vitaly Davidovich]

Chris,

I don't know if you (and others) prefer to discuss this here or start a
separate thread, but let me just throw in my vote (again) for including
@Contended in SE.  I'm sure you're well aware of the ugly hacks people
resort to for achieving this currently.  False sharing is an effect that we
need to account for, particularly as things go more parallel with
increasing core counts.  I highly urge you (i.e. Oracle) to export this to
the outside world.

Thanks

On Wed, Nov 11, 2015 at 9:07 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> On 11 Nov 2015, at 13:11, Doug Lea <dl at cs.oswego.edu> wrote:
>
> > On 11/11/2015 07:06 AM, Chris Hegarty wrote:
> >
> >>>>>> http://cr.openjdk.java.net/~chegar/8140687/00/
> >>>>>
> >>>
> >>> While this is up for review, could someone please explain
> >>> again why @Contended should not be a public annotation?
> >>
> >> Sorry Doug, I don’t have the answer to your question. I was
> >> not involved in the original @Contended support. Since it
> >> was added in JDK 8, we have some experience with it now,
> >> so  maybe this would help influence any future discussion on
> >> its possible inclusion in Java SE.
> >>
> >
> > Sorry to be a pest about this.
>
> Not a problem. This is a good discussion to have now.
>
> > But, as I should have noticed
> > before, taking away sun.misc.Contended without providing any
> > alternative for non-JDK users seems to be the only exception to
> > the stated policy of only removing functionality that has a jdk9
> > equivalent, or else making it public. If this exception was not
> > deliberate, then it is better to reconsider this now vs later.
>
> JEP 260 [1] lists a number of “critical” internal API’s that will remain
> accessible in JDK 9. It specifically calls out the following:
>
>   - sun.misc.Cleaner
>   - sun.misc.{Signal,SignalHandler}
>   - sun.misc.Unsafe
>   - sun.reflect.Reflection::getCallerClass
>   - sun.reflect.ReflectionFactory
>
>  "Suggested additions to this list, justified by real-world use cases
>    and estimates of developer and end-user impact, are welcome.”
>
> Are you suggesting that @Contended be added to this list?
>
> If @sun.misc.Contended remains as is, and no new standard Java
> SE API is defined, then an alias or similar will be required. The
> reason for this is that eventually the ‘sun.misc' package will be split
> out into a new module “jdk.unsupported”, and the base module,
> which is a consumer of @Contended, cannot have a dependency
> on any other module. This work is possible, just requires a different
> solution.
>
> 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 ?
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8132928
>
>