> On 6 Jul 2016, at 13:31, Claes Redestad <claes.redes...@oracle.com> wrote: > > > > On 2016-07-06 12:45, Paul Sandoz wrote: >> >>> On 6 Jul 2016, at 12:04, Michael Haupt <michael.ha...@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.
