RFR (S): JEP-142: Reduce Cache Contention on Specified Fields

[Vitaly Davidovich]

John,

What is driving this eagerness to hide away this feature? Is it Oracle
support concern? Is it fear of having to support this in future versions?
I'm a bit puzzled on the concerns expressed here and on other threads given
this is being put into sun.misc, which already comes with a "you're on your
own" label (including no promise of source or binary backwards
compatibility).  What am I missing? Can anyone actually describe a
realistic scenario where this will cause grave harm if allowed in sun.misc?

Thanks

Sent from my phone
On Dec 4, 2012 6:47 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 27, 2012, at 3:35 AM, Doug Lea wrote:
>
> > And, as someone else noted, sun.misc (where Unsafe lives) is even
> > more exotic, and has the audience of low-level/core developers
> > that this targets. Placing it there would get us past all the
> > concerns (that I honestly think are wrong) about sending the
> > wrong message or precluding miraculous automation. So, how
> > about we just live with it as follows:
>
> I don't mean to add insult to injury, but I think there is yet another
> restriction that we should place this annotation under, in its current
> residence of sun.misc.
>
> The annotation must be documented as being a no-op when it occurs inside
> class files that are loaded outside the boot class path.
>
> This is consistent with comments made by several other people, that these
> tools are intended, at least at first, for developers of core classes.
>  This is also consistent with Unsafe, which (however popular it is) is
> designed to be used core classes only, on the BCP (boot class path).[1]
>
> For JSR 292 we are likely to introduce @ForceInline, @Stable, and some
> other annotations into sun.misc.  They will be restricted to BCP classes
> only, and may go away in the future.  How fast do you think people would
> pollute their code with @ForceInline if it was effective outside of core
> classes?  We need hooks for system-specific tuning (when the JIT is part of
> the tuned system) but we do not want a "register" keyword[2] to become part
> of Java lore.
>
> At the same time the annotation is sufficiently understood to be exported
> more widely, it can be enabled off the BCP.  I think we need a module
> system in place to do a good job of this.  (And, yes, Unsafe should also be
> importable as a module of some sort.)
>
> The bottom line is that sun.misc is a good place for vetting experimental
> annotations.  And, unless there is a strong reason otherwise, they should
> be no-ops outside of the core classes (i.e., the BCP).
>
> I now don my asbestos smoking jacket.
>
> — John
>
> [1] Yes I know Unsafe is sometimes broken into by a Field.setAccessible
> hack.  Which is an implementation artifact that could easily break by
> accident.  If you use that hack, you should move your code to BCP.
>
> [2] http://www.cplusplus.com/forum/general/8225/