RFR (S) CR 8014966: Add the proper Javadoc to @Contended

[Peter Levart]

On 05/29/2013 01:20 PM, Aleksey Shipilev wrote:
>> In general, I think you
>> >*DO*  want the subclass fields to be potentially in the same location as
>> >the superclass padding fields.
>> >A >: B
>> >A layout: ppppaaaapppp
>> >B layout: ppppaaaabbbbpppp
>> >  
>> >which is not asking too much of a jit.
>> >I believe it is already common for VMs to allocate subclass fields in
>> >natural padding space of superclasses.
>> >
> This gets very tricky even in a slightly complicated case:
>    A >: B
>    A layout: ppppAAppppCCpppp
>    B layout: ppppAABBppCCpppp
>
> Note that we can't move CC in B because the fields are bound statically;
> so we end up ruining the padding for both BB and CC. We can, of course,
> have the gap in the padding to tolerate this, but before knowing in
> advance what subclasses will be loaded next, we can not prepare enough;
> or, we can redefine all the classes up the hierarchy... (Current HotSpot
> classloader code is completely not ready for things like these).
>
> However, implementation issues aside:
>
> Allowing contended tags to be inherited will force users to look at the
> entire hierarchy to search for the colliding tags; or (what's worse)
> push the superclass maintainers to use cryptic tags so no possible
> subclasses can collide with the protected fields. IMO, that is way
> messier than pushing users to aggregate the semantically-close fields in
> the same class. Hence, I left the inheritance clause as is.

Hi Aleksey,

Just some ideas for future...

Implementation issues aside, the name of the tag specified in the 
@Contended annotation could be evaluated in the context of the fully 
qualified class name in which the annotation is used. For example:

package pkg;
class C {
     @Contended("g") int x;
}

...here the fully qualified name of contention group for field 'x' could 
be interpreted as "pkg.C.g".

When the tag contained at least one dot, it would be interpreted as 
fully qualified, oterwise as a simple name. Implementation could allow 
one of the contention groups to be used in a "global" context on the 
boundary of superclass/subclass, but which one is the one, would have to 
be anticipated and explicitly or implicitly noted on the superclass, so 
that the layout logic could group those fields at the end of object as 
soon as the superclass is loaded. One way to implicitly note the 
"global" contention group could be: "the global group is the group 
specified on the last @Contended field in the class as ordered in the 
source/class file".

I don't know if this is useful anyway. Could a superclass correctly 
anticipate the "global" group in some situations?

Regards, Peter