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

Chris Hegarty chris.hegarty at oracle.com
Mon Nov 23 10:11:56 UTC 2015


Given John's comments, and the limitation of -XX:-RestrictContended,
adding an additional command line flag, -XaddExports, in 9 to access
@CS seems reasonable. I will proceed with this change as is.

   http://cr.openjdk.java.net/~chegar/8140687/00/

-Chris.


On 13/11/15 00:08, John Rose wrote:
> On Nov 12, 2015, at 5:48 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>>>....
> 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