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

Paul Sandoz paul.sandoz at oracle.com
Wed Jul 6 14:05:16 UTC 2016


> 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.

Paul.


More information about the core-libs-dev mailing list