From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fnbkk-0004Dj-Q4 for garchives@archives.gentoo.org; Tue, 06 Jun 2006 13:37:51 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k56DZkDJ016782; Tue, 6 Jun 2006 13:35:46 GMT Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k56DZiVY014287 for ; Tue, 6 Jun 2006 13:35:44 GMT Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k56DZeJA021760 for ; Tue, 6 Jun 2006 07:35:40 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0F00E01XGOSJ00@mail-amer.sun.com> (original mail from David.Herron@Sun.COM) for gentoo-java@lists.gentoo.org; Tue, 06 Jun 2006 07:35:40 -0600 (MDT) Received: from [192.168.0.104] ([66.92.11.96]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0F003DAXREFOP0@mail-amer.sun.com>; Tue, 06 Jun 2006 07:35:39 -0600 (MDT) Date: Tue, 06 Jun 2006 06:35:38 -0700 From: David Herron Subject: Re: [gentoo-java] Re: How to predetermine if ebuilds will compile with 1.5? In-reply-to: <44854829.4000002@seznam.cz> Sender: David.Herron@Sun.COM To: Caster Cc: gentoo-java@lists.gentoo.org Message-id: <448584AA.1040300@sun.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IVAoL8PQ4jY4GgNDDcXJIw)" References: <44833F92.1020201@seznam.cz> <44843F50.4020706@seznam.cz> <4484ADDC.2010105@sun.com> <44854829.4000002@seznam.cz> User-Agent: Thunderbird 1.5.0.4 (X11/20060516) X-Archives-Salt: 8f0444bd-9571-4614-ba6d-4ce930cfcab8 X-Archives-Hash: 3e8b6893da7cf888a2b70f62d7ea930b This is a multi-part message in MIME format. --Boundary_(ID_IVAoL8PQ4jY4GgNDDcXJIw) Content-type: text/plain; format=flowed; charset=windows-1252 Content-Transfer-Encoding: 7BIT Okay, that helps. I'm not a compiler expert but here's a couple factoids: 1) we're always working to improve performance, 2) the compiler team is always working on improving the compiler (fix bugs etc), 3) the generated byte codes can either exhibit certain bugs or performance gains/losses ... hence, hence I expect/assume the byte codes output to vary somewhat from release to relase. I can't say how much or what specifically that would be. - David Caster wrote: > Greg Tassone wrote: > >> I think this statement is a little too broad to be considered correct. >> The compiler can (and often does) make changes to the resulting binaries >> that may be VM-level specific (e.g., targeted for a 1.5 VM). Consider >> the "-target" argument for javac, for example, which "Allow[s] javac to >> use 1.5 specific features in the libraries and virtual >> machine" (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html ). > David Herron wrote: > >> er... Caster, the bytecode does vary based on the compiler. And the >> class file format has varied a small amount from release to release with >> the 1.5 class file format being the most different. >> >> This is, as I understand it, the crux of the problem you guys are seeing >> with adopting 1.5 ... yes? > > Sorry, I wasn't clear enough. I didn't mean the class file format which > is indeed different and causes problems. I was trying to ask if there > are any (the compiled bytecode performance?) gains of using 1.5 compiler > for 1.4 source (without specifying --source and --target 1.4). This > source won't use any 1.5 specific features, but you say the bytecode > still can somehow? > > Caster > > --Boundary_(ID_IVAoL8PQ4jY4GgNDDcXJIw) Content-type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k56DZkDg016782 Okay, that helps.

I'm not a compiler expert but here's a couple factoids:=A0 1) we're always working to improve performance, 2) the compiler team is always working on improving the compiler (fix bugs etc), 3) the generated byte codes can either exhibit certain bugs or performance gains/losses ... hence, hence I expect/assume the byte codes output to vary somewhat from release to relase.=A0

I can't say how much or what specifically that would be.

- David


Caster wrote: 
Greg Tassone wrote:
  
I think this statement is a little too broad to be con=
sidered correct.
The compiler can (and often does) make changes to the resulting binaries
that may be VM-level specific (e.g., targeted for a 1.5 VM).  Consider
the "-target" argument for javac, for example, which "Allow[s] javac to
use 1.5 specific features in the libraries and virtual
machine" (http://java.sun.com/j2se/1.5.0/do=
cs/relnotes/features.html ).
David Herron wrote:
  
er... Caster, the bytecode does vary based on the comp=
iler.  And the
class file format has varied a small amount from release to release with
the 1.5 class file format being the most different.

This is, as I understand it, the crux of the problem you guys are seeing
with adopting 1.5 ... yes?

Sorry, I wasn't clear enough. I didn't mean the class file format which
is indeed different and causes problems. I was trying to ask if there
are any (the compiled bytecode performance?) gains of using 1.5 compiler
for 1.4 source (without specifying --source and --target 1.4). This
source won't use any 1.5 specific features, but you say the bytecode
still can somehow?

Caster
--Boundary_(ID_IVAoL8PQ4jY4GgNDDcXJIw)-- -- gentoo-java@gentoo.org mailing list