RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature
Claes Redestad
claes.redestad at oracle.com
Wed Jul 6 14:31:18 UTC 2016
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
More information about the core-libs-dev
mailing list