Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Enums: Properties vs. Methods Date: Thu, 31 Mar 2011 08:41:11 -0400 Organization: albasani.net Lines: 90 Message-ID: References: <2f38bb8e-9a8d-4464-ad3d-b9ce0b557219@e21g2000yqe.googlegroups.com> <8vh9efFg01U1@mid.individual.net> <0187eb75-7f36-4254-9711-f63ff480f62e@j13g2000yqj.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.albasani.net ehFDBDfQHxDsxAyvM2SbiTdwAGlHuszTwLsiMpoQnz/Vi4e5f/vD4CrgnmwvAIWQySGTxdlA4Jmetv1nF5/cNw== NNTP-Posting-Date: Thu, 31 Mar 2011 12:41:00 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="MstJUGG2FYEQt9tXu4Ff3QWxfnTkaftF3n/GMzouMpJXyZvTQ92fHSjCEtUj328FLIBTu1mtM/RGVOkCekfF/v5hA84ghogcikqzru/GTup189Yse5UzdQgqXSSXZe0L"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: <0187eb75-7f36-4254-9711-f63ff480f62e@j13g2000yqj.googlegroups.com> Cancel-Lock: sha1:5I5x4bm9s8aF0YIiNCYrCCRU37c= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2649 Robert Klemme wrote: > Lew wrote: >> Yes. So? that's what HotSpot does, except it's not one per instance, >> it's N>= 1 per instance, potentially. HotSpot optimizes for >> individual hot spots in the code, hence the name. > > Hmm... Considering > > public void hotSpotMethod(Valve v) { > // code > if (v.isOpen()) { > // ... > } > else { > // ... > } > // more code > } > > Since this method can be invoked with different Valve instances the > only optimization I can see so far is > > public void hotSpotMethod(Valve v) { > // code > if (v.open) { > // ... > } > else { > // ... > } > // more code > } > > or are you saying that we can actually get this? I make no claims whatsoever about individually crafted examples designed to show where HotSpot might fail. I only repeat publicly available information about what it does. > public void hotSpotMethod(boolean valve_open) { > // code > if (valve_open) { > // ... > } > else { > // ... > } > // more code > } ... >> Yes, it wins, but that has nothing to do with memory or performance in >> the JVM. >> >> For the toy example given I would expect no difference, since the >> final variables ocmpile to constants anyway. > But those final variables are only constant /per instance/. How would > hotspot be able to inline them? Per instance, or perhaps per call. Of course. It might then un-inline them for a later call, then re-inline them - even the exact same call if conditions change that affect optimization. The beauty of HotSpot is that it accounts for changing run-time circumstances, so it can perform optimizations that elude static analysis. You should read about it. ... >> As for JVM effects, I would expect the two approaches to be >> indistinguishable. Constant variables are compiled into constants in >> the code, so they get treated identically with constants (being, after >> all, constants in truth) at run time. > I don't think these final members (which are not static!) can be > compiled into the code because there is just one class (and hence one > instance of each method) but multiple instances with different sets of > values for their final members. The JLS requires them to be compiled into the code. And regardless of what you don't think, that's exactly what happens. You should read about it. Start here: JLS, ยง17.5.3, as I cited earlier. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg