> but even non-final methods are inlined by hotspot, if the compiler is sure > that the class was not extended There's absolutely no way a JIT compiler can be sure that the class was not extended (except declaring it final) - because you can create a new classloader and load new class any time you want. That's why when optimizing invokeVirtual / inlining stuff for non-final methods, compiler inserts guards that do a fast-check for expected class.
I also encountered cases with 1.6 when declaring local variables final helped, even though it was obvious that variable never changed after initialization. On Sun, Feb 28, 2010 at 21:40, Uwe Schindler <u...@thetaphi.de> wrote: > As far as I know, the HotSpot compiler does not really take care of final > anymore. In the older java ages that was important, but even non-final > methods are inlined by hotspot, if the compiler is sure that the class was > not extended and so on. So making a method final just for inlining is no > longer really needed. But with final you help hotspot more. Because of that, > e.g. the collect methods in TFDC should be final and so on. But there is no > requirement anymore. And Lucene 3.1 only runs with Java 5+, so who cares? > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > >> -----Original Message----- >> From: Michael McCandless [mailto:luc...@mikemccandless.com] >> Sent: Sunday, February 28, 2010 7:30 PM >> To: java-dev@lucene.apache.org >> Subject: Re: Turning IndexReader.isDeleted implementations to final >> >> Sorry, I think the classes? Not sure which others should be... >> >> Though it always spooks me out trying to decide if something should >> really be final... these two are package private so in theory nobody >> should be extending them, anyway, but if out there someone subclassed >> them (mixing code into oal.index) to fix something and didn't post >> back to us then we're slamming that door shut... all for likely tiny >> (if at all) perf gains. But then if we do make them final we would >> then hear from any (if any) places that broke about what we should >> fix/make extensible in our core impls.. >> >> I think using final for classes like any of our analyzers makes alot >> of sense. There we explicitly want to state that you should go make >> your own class if you need a custom analyzer. Too many problems >> surface if you subclass core analyzers. >> >> Also... making DirectoryReader final would prevent any sneaky >> subclassing out there... which'd be good because I don't actually like >> that DirectoryReader (and, MultiReader) even subclass IndexReader. I >> don't think they should, ie, I think it's bad that you can get >> Multi*Enum, call isDeleted (doing a binary search each time). You >> should work per segment (use MultiSearcher) instead. So tightening >> these classes up for that possible future seems good? Maybe we should >> even deprecate them! >> >> So +1 to make these 2 final, and maybe also MultiReader, but not sure >> which others... >> >> Mike >> >> On Sun, Feb 28, 2010 at 12:10 PM, Shai Erera <ser...@gmail.com> wrote: >> > What's ok? making the classes final or just the method declaration? >> If >> > classes, besides ReadOnlySegmentReader, which other impls do you >> think can >> > be made final (I'm not in front of the code)? >> > >> > On Sun, Feb 28, 2010 at 7:05 PM, Michael McCandless >> > <luc...@mikemccandless.com> wrote: >> >> >> >> Seems OK I think? >> >> >> >> Mike >> >> >> >> On Sun, Feb 28, 2010 at 12:37 AM, Shai Erera <ser...@gmail.com> >> wrote: >> >> > Hi >> >> > >> >> > Do you think it's worth to make some of the isDeleted method impls >> >> > final, >> >> > like in ReadOnlySegmentReader and (maybe) DirectoryReader? I'm >> thinking >> >> > the >> >> > classes that are perceived as final could benefit from that, since >> their >> >> > impl could be inlined. Maybe just make these classes final >> entirely? >> >> > >> >> > Shai >> >> > >> >> >> >> -------------------------------------------------------------------- >> - >> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
