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