Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Roedy Green Newsgroups: comp.lang.java.programmer Subject: Re: Eclipse generated hashCode() and Compiler Efficiency Date: Mon, 04 Jul 2011 08:54:36 -0700 Organization: Canadian Mind Products Lines: 19 Message-ID: References: <8ee12802-2786-472a-815f-94dc14112d7d@c29g2000yqd.googlegroups.com> Reply-To: Roedy Green NNTP-Posting-Host: RCd/Ul4tyxGUBII8WGwa5g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Forte Agent 6.00/32.1186 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5853 On Mon, 4 Jul 2011 04:07:51 -0700 (PDT), Robert Klemme wrote, quoted or indirectly quoted someone who said : > Is this an optimization they didn't bother to do >(or left for the JVM) or is there any reason why the local variable >must be there? So far I could not find any hints in JLS or JVM spec. Almost no optimisation is done at the byte code level. It is all done later when hotspotting. Ironically, it is possible that if you get too clever and optimise the byte code, then later optimisers could miss standard patterns and hence fail in their optimisations. -- Roedy Green Canadian Mind Products http://mindprod.com One of the curses of the computer age is manufacturers now design home appliances to die on the very day the warranty expires. It is deliberate waste in the service of mindless profit.