Future plans for sun.misc.Contended

[Andrew Haley]

On 23/02/17 17:26, Vitaly Davidovich wrote:
> My understanding was it's in sun.misc as an experimental/"unstable"
> annotation, but that it was incubating there before being made supported
> (and moved out of that package) as it's a legitimately useful feature (the
> manual padding one does today with class hierarchy and unused padding
> fields is atrocious, as some of you may know).

John Rose spoke about this before.

"There's a misunderstanding here.  Sadly, it relates to security
policy.

"The shadowy figures with the liberal usage of sharp-edged features
are not dumb users, nor are they smart users like you whom we
unaccountably view as "dumb and misinformed", but black hat attackers
(or security researchers of any stripe), who take sharp stuff like
that and use it backwards and upside down, in ways neither dumb nor
smart users would ever dream of, to coax the JVM into disallowed
states.

"The overflow Paul refers to would not be a heap OOM but
(hypothetically) size indicators in the implementation of the JVM.
Adding @C to the public mix gives a determined attacker 3 more bits of
dynamic range to maximum instance sizes.

"I personally don't think there is any specific way to weaponize that,
but I do know, from bitter experience, that some such expansions
produce bugs.  (Think 16-bit overflow: It has happened, it hurts when
it happens.)  Adding @C to the public mix means we have to race the
black hats to find any bug tail due to the extra degrees of freedom in
instance layout.  It's not a race I want to run or need to run, so we
are not making @C public.

"As we do value types we are having to open up object layout to many
more degrees of freedom.  This will be carefully reviewed and
stress-tested.  At that point it will be very safe to add other layout
hacks like @C.  In fact, it is likely that we will be able to factor
field-semantic hacks like @C (and WeakReference and Optional and
various other interesting variable types) into value type wrappers of
the base type."

Andrew.