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

Vitaly Davidovich vitalyd at gmail.com
Fri Nov 13 00:29:09 UTC 2015

Thanks John, I understand your position and rationale (Paul actually
clarified this along the same lines to me earlier today).  I have to admit
that this would have to be quite an exotic exploit, but point taken.

sent from my phone
On Nov 12, 2015 7:08 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 12, 2015, at 5:48 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> There is a very valid concern, since @Contended changes object layout and
> increases object size, liberal use might tickle an overflow in HotSpot
> code. Hence why it has remained internal so far.
> What overflow? OOM of the heap? How is that a "very valid" concern? Why
> would it be used liberally? Why are you allowing users to allocate any
> memory whatsoever? Why not put a cap on the size of objects non-JDK code
> can allocate? :) I mean seriously, with all due respect, the occasional
> "our users are dumb and misinformed" sentiment is very off-putting.
> 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.
> For now, sorry.  Please use the -XX and -Xbcp thingies as workarounds.
> — John

More information about the core-libs-dev mailing list