Thanks Andrew - I recall reading that, but wasn't sure if that was still the final thinking. Unfortunately, I'm seeing this annotation slip into codebases (with the corresponding -XX:-RestrictContended), and jigsaw is surfacing these instances. Looks like we have to wait for panama/valhalla then to see where layout control lands.
On Thu, Feb 23, 2017 at 12:41 PM, Andrew Haley <a...@redhat.com> wrote: > 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. > >