Hi Claes, Paul, Andrej, thank you very much for your reviews. I've added lazy initialisation. This is the change I'm going to push: http://cr.openjdk.java.net/~mhaupt/8160717/webrev.02/
Best, Michael > Am 06.07.2016 um 16:31 schrieb Claes Redestad <claes.redes...@oracle.com>: > > > > 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 -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
