RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

[John Rose]

Using @Stable breaks down some of the complexity.
And the CHM (with the winning computeIfAbsent) breaks down lots more.
Nice job!

I'm a little sad that it needs two CHMs (CACHE and CLASS_CACHE).
This must be because there are three or four states per key, instead of
the usual two.  These states should be documented for posterity.

— John

On Nov 9, 2015, at 4:16 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi all,
> 
> Thanks for analysis, reviews and discussion that hopefully beheaded this hydra.
> 
> I added an assert to method setSpeciesDataToConcreteBMHClass() that verifies the presence of @Stable annotation on the SPECIES_DATA field of the generated class. It caught a bug I made when I specified a binary class name "java/lang/invoke/Stable" in FieldVisitor.visitAnnotation() instead of type signature "Ljava/lang/invoke/Stable;"
> 
> The consequence was not drastic - the field was just not being interpreted by VM as @Stable.
> 
> With that adjustment and successful re-run of jtreg tests, I ask for re-confirmation to push the following:
> 
>    http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.07/
> 
> Regards, Peter
> 
> On 11/06/2015 01:31 PM, Vladimir Ivanov wrote:
>> Peter,
>> 
>>> 
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.06/
>>> 
>> 
>> Looks really good! Reviewed.
>> 
>>> - the SPECIES_DATA field in generated class can not be static final when
>>> it is initialized out of <clinit>. Just static. It was just static
>>> before when it was initialized in <clinit> and could be static final. We
>>> can make it @Stable at least.
>>> 
>> Not sure it is on hot path, but I'm all for marking the field as @Stable
>> 
>>> - there's no need for empty <clinit> method now. Removed.
>>> 
>>> Basic java/lang/invoke jtreg tests pass.
>> 
>> Best regards,
>> Vladimir Ivanov
>