On 2016-07-06 16:05, Paul Sandoz wrote:
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.
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
