RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Michael Haupt]

Hi Claes, Paul, Andrej,

thank you very much for your reviews. I've added lazy initialisation. This is the change I'm going to push: http://cr.openjdk.java.net/~mhaupt/8160717/webrev.02/

Best,

Michael

> Am 06.07.2016 um 16:31 schrieb Claes Redestad <claes.redestad at oracle.com>:
> 
> 
> 
> On 2016-07-06 16:05, Paul Sandoz wrote:
>> 
>>> On 6 Jul 2016, at 13:31, Claes Redestad <claes.redestad at oracle.com> wrote:
>>> 
>>> 
>>> 
>>> On 2016-07-06 12:45, Paul Sandoz wrote:
>>>> 
>>>>> On 6 Jul 2016, at 12:04, Michael Haupt <michael.haupt at oracle.com> wrote:
>>>>> 
>>>>> Hi Paul,
>>>>> 
>>>>> thanks for your comments.
>>>>> 
>>>>> Lazy initialisation of the PerfCounter is good, as is the warning suppression.
>>>>> 
>>>>> I'll let Claes comment on the broader PerfCounter question, as he suggested using them. I think PerfCounter is a convenient abstraction for what we want to achieve, but the way it's used here may smell a bit abusive.
>>>>> 
>>>> 
>>>> Ok.
>>> 
>>> I know of a number of Java-side PerfCounters created early (and they're rather lean on dependencies in the first place, a select number of j.u.c.atomic classes IIRC), so I wouldn't worry about much of a startup penalty here.
>>> 
>>> Lazy initialization might not save us much, and would hide the counter from showing up.
>>> 
>>> I guess what I'm saying is I'm good with webrev.00. :-)
>>> 
>> 
>> LambdaForm is initiated very early in the startup, and that is gonna change the order in which other classes are loaded, namely Buffers etc. I am concerned it might induce a circular dependency with VarHandles and the 166 patches that will arrive soon, e.g. see use of static AtomicInteger fields in Bits.
>> 
>> If you want to retain the PerfCounter usages i think you may need to make it lazy.
> 
> Ah, right, it's one of the classes the VM preloads, so it'll be loaded long before anyone actually uses java.lang.invoke. Yes, that might cause bootstrap issues, and needs to be lazy.
> 
> For the record: I perceived a need to have some discoverable event in case this fallback ever takes effect. A PerfCounter is certainly not be the best fit for that, but it's readily available and would allow for a quick and dirty diagnostic. Perhaps it's best to move it to a follow-up improvement, but I'd prefer to have something in that can be improved/replaced than nothing at all.
> 
> /Claes

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment