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

[John Rose]

On Dec 6, 2012, at 1:31 AM, Michael Barker wrote:

> A middle ground I could live with would be something like
> -XX:(+/-)RestrictContendedToBootClassPath (preferably with the default
> as off).  Adding/removing a switch of that nature is operationally
> simpler than fiddling with file locations and classpath settings.

I'm OK with that.  The important thing is that, in order for your code use the annotations, you have to have control over the command line (or Unsafe) in order to access the functionality.  That way, people cannot start using the annotation from unprivileged class files, without an overarching decision from the person that launched the JVM.


On Dec 4, 2012, at 4:08 PM, Doug Lea wrote:

>> [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.
>> 
> 
> Which is the trick we use to put out our pre-openjdk-integration
> preview packages. So we'd have to find another trick...

On Dec 5, 2012, at 3:16 AM, Doug Lea wrote:

> This would be a less
> controversial idea if it were not for all the cases that arise
> in practice where other factors make it impossible for the
> actual users of the functionality to control JVM startup
> settings. Which ends up making this proposed rule overly
> hostile in its practical effect.

Note that Unsafe.defineClass allows you to load classes anywhere, including on the boot class path.  So if you want to load privileged code from an unprivileged context, and you are willing and able to use Unsafe, that is an option.  Is there some reason this fails to be useful?  Maybe some residual security check that still executes?

> So I think that wording things so as to make no promises
> in these cases (and to not force the VM to make special
> efforts to see if it must ignore @Contended), rather than to
> promise no effect, is the best compromise available.

It's easy to make the check (I just pointed Aleksey at the code), so I think we need to do it from the start, as long as @Contended is in a private package.  When it goes public, then all code (presumably) will benefit from it.

Additional rationale details:  If you cannot validly compile source code that refers to the annotation (which the ctsym file filters out), then you should not be able to execute the annotation within class files you can load, even if you are clever enough to build the annotation into the class files.  On the other hand, invalid annotations are defined as silent no-ops.  This leads to the restriction I am asking for.

In positive terms:  If you have to work around the ctsyms during compilation, expect to work around package access restrictions when loading and linking your program.  (This is already true, and will continue to be true.)

Why should a restriction on source code be mirrored by a restriction on bytecode?  It's not logically necessary, and it would be convenient to library deployers to have no restrictions on bytecode.  But I believe it is more reasonable to have repeated source/binary restrictions than to have source-only restrictions, especially for configuration parameters like class visibility.  In any case, that's how Java does things, and people are used to it.  It eases security and configuration analyses to have the source code and binary code to be subject (as much as possible, but see JLS Ch. 13) to the same (or analogous) access restrictions.

Granted, there would be little or no security downside for allowing @Contended fields everywhere.  Worst case, maybe, is that hackers would be able to create gigantic instance layouts, to some nefarious purpose.  I guess, besides a remote possibility of an attack, the main thing I'm concerned with is creating a support burden from arbitrary code using a feature intended to be restricted to privileged code.  (Remi cites the opposite support burden, for people that loads code that crosses a line.  That burden should be borne by whoever made the decision to cross that line, and I think Unsafe.defineClass gives them a reasonable workaround.)

In a nutshell, now that we're getting into the business of fancy annotations, we need to roll them out with just as much care as we do with normal class-based APIs.  That means enforcing access checks at both compile time and run time.  And for annotations, a failed access check at runtime entails a no-op.

On Dec 4, 2012, at 4:36 PM, Remi Forax wrote:

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

I am assuming that wherever we say "boot class path" now, we will use a suitable replacement concept with Jigsaw.

— John