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

[Remi Forax]

On 12/05/2012 12:46 AM, John Rose 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.

I will agree if it's a way to be sure that the boot class path will not 
be cut in small pieces by jigsaw.
What we really want here is a way to say that a module is tainted (like 
the linux kernel), and only tainted module have access to sun.misc.

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

I strongly disagree, dynamic langage runtimes are used from command line 
(so they can control the BCP) but also in JEE containers (no control).
I see your proposal as a way to create work for a lot of support team to 
figure out why there is performance regression when users they don't 
start their favourite languages using the command line.
>
> 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.

You can already force inlining using a text file. I show that to my 
students and they don't use it after the lab because it's so easy to 
reach the max number of nodes that you can not use it on a large scale. 
Microsoft as introduced this feature in their latest version .Net [1] 
and nobody cares.
Being in sun.misc is in my opinion enough.

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

Rémi

[1] 
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions%28v=vs.110%29.aspx