RFR  8140687: Move @Contended to the jdk.internal.vm.annotation package
john.r.rose at oracle.com
Fri Nov 13 00:08:27 UTC 2015
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
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
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.
More information about the core-libs-dev