From Per.Bothner at Sun.COM Wed Aug 1 09:57:25 2007 From: Per.Bothner at Sun.COM (Per Bothner) Date: Wed, 01 Aug 2007 09:57:25 -0700 Subject: problem building compiler with nb 6m10 Message-ID: <46B0BB75.1090509@sun.com> I checked out the OpenJDK Subversion repository, and then followed the instructions in http://nb-openjdk.netbeans.org/get-and-build-compiler.html I get: Warning: falling back to building against /home/bothner/Java/jdk1.6.0 Please define bootstrap.jdk=.../recent/jdk7/snapshot in /home/bothner/.openjdk/build.properties or /home/bothner/Java/jdk/j2se/make/netbeans/compiler/nbproject/private/build.properties check-javac.isuptodate: build-lib.javac.jar: Compiling 8 source files to /home/bothner/Java/jdk/j2se/build/linux-i586/bootclasses /home/bothner/Java/jdk/j2se/make/netbeans/common/shared.xml:170: The following error occurred while executing this line: /home/bothner/Java/jdk/j2se/make/netbeans/compiler/build.xml:77: /home/bothner/Java/jdk/j2se/make/netbeans/compiler/${src.classes} not found. BUILD FAILED (total time: 0 seconds) This is on a GNU/Linux (Fedora 7) system. While the instructions for building the whole JDK talk about needing binary classes, I was hoping I could just build the compiler with jdk 1.6. The instructions suggest I can do that. -- --Per Bothner per.bothner at sun.com per at bothner.com http://per.bothner.com/ From jesse.glick at sun.com Thu Aug 2 14:32:24 2007 From: jesse.glick at sun.com (Jesse Glick) Date: Thu, 02 Aug 2007 17:32:24 -0400 Subject: problem building compiler with nb 6m10 In-Reply-To: <46B0BB75.1090509@sun.com> References: <46B0BB75.1090509@sun.com> Message-ID: Per Bothner wrote: > /home/bothner/Java/jdk/j2se/make/netbeans/compiler/build.xml:77: /home/bothner/Java/jdk/j2se/make/netbeans/compiler/${src.classes} not found. The build script is simply broken. I already posted an unrelated patch to nb-projects-dev a month ago to add extra targets to the compiler project which as an aside included a fix, but in case you missed that, try the attached. -J. -- jesse.glick at sun.com netbeans.org ant.apache.org hudson.dev.java.net http://google.com/search?q=e%5E%28pi*i%29%2B1 -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler-build.diff Type: text/x-diff Size: 1066 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070802/7f2087e5/compiler-build.diff From Per.Bothner at Sun.COM Fri Aug 3 00:59:29 2007 From: Per.Bothner at Sun.COM (Per Bothner) Date: Fri, 03 Aug 2007 00:59:29 -0700 Subject: problem building compiler with nb 6m10 In-Reply-To: References: <46B0BB75.1090509@sun.com> Message-ID: <46B2E061.7010606@sun.com> Jesse Glick wrote: > The build script is simply broken. It seems disturbing that a high-profile Sun public open-source project is unbuildable for a month ... > I already posted an unrelated patch > to nb-projects-dev a month ago to add extra targets to the compiler > project which as an aside included a fix, but in case you missed that, > try the attached. Thanks! I was able to get this to work. Also, I was able to generate a fairly clean patch for the version of javac we've been using to build the javafx compiler, so it is now feasible to for us to track javac. Yeah! -- --Per Bothner per.bothner at sun.com per at bothner.com http://per.bothner.com/ From Jonathan.Gibbons at Sun.COM Fri Aug 3 07:17:31 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 03 Aug 2007 07:17:31 -0700 Subject: problem building compiler with nb 6m10 In-Reply-To: <46B2E061.7010606@sun.com> References: <46B0BB75.1090509@sun.com> <46B2E061.7010606@sun.com> Message-ID: <71AE3D2B-23E7-4B0D-92B2-B01A2C8C77F5@sun.com> On Aug 3, 2007, at 12:59 AM, Per Bothner wrote: > > It seems disturbing that a high-profile Sun public open-source > project is unbuildable for a month ... Per, I am sorry for the inconvenience. We have been focussing our limited efforts on a single new build system for the compiler and related tools that will be used by Sun's Release Engineering, and compiler developers, and any other people interested in working on the compiler via Ant or NetBeans. This will replace the disparate build systems in use today by these different audiences. -- Jon G From Jonathan.Gibbons at Sun.COM Fri Aug 3 07:34:28 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 03 Aug 2007 07:34:28 -0700 Subject: jtreg: ignoring @ignored tests Message-ID: As many of you know (and are painfully aware!), and for mostly historical reasons, jtreg "processes" tests which have been temporarily disabled with an @ignore keyword, giving an Error result, which messes up an otherwise clean test run. Since in reality, "temporarily" has turned out to be somwhat longer than expected, I went to fix it. And as I figured the fix, I found that enough of the fix was already in place in all existing versions of jtreg that it can be used by everyone even now. It turns out that all @ignore-d tests have the "ignore" keyword set on them. So you can use the -keyword option to exclude tests with the ignore keyword by going -keyword:!ignore If you're running jtreg from a shell, you might need to escape the '!'. If you're running jtreg from Ant, you can provide this parameter via an element. -- Jon G From Per.Bothner at Sun.COM Fri Aug 3 09:46:21 2007 From: Per.Bothner at Sun.COM (Per Bothner) Date: Fri, 03 Aug 2007 09:46:21 -0700 Subject: problem building compiler with nb 6m10 In-Reply-To: <71AE3D2B-23E7-4B0D-92B2-B01A2C8C77F5@sun.com> References: <46B0BB75.1090509@sun.com> <46B2E061.7010606@sun.com> <71AE3D2B-23E7-4B0D-92B2-B01A2C8C77F5@sun.com> Message-ID: <46B35BDD.4010601@sun.com> Jonathan Gibbons wrote: > I am sorry for the inconvenience. We have been focussing our limited > efforts > on a single new build system for the compiler and related tools that > will be > used by Sun's Release Engineering, and compiler developers, and any other > people interested in working on the compiler via Ant or NetBeans. > This will replace the disparate build systems in use today by these > different > audiences. I'm very much looking forward to it! Until then, could Jesse's patch be checked in? (I should have bugged you earlier about the issue - you probably didn't realize that it really was an inconvenience for us. Partly our fault for going down the wrong path, using snapshots without svn. Fixed now, I believe.) -- --Per Bothner per.bothner at sun.com per at bothner.com http://per.bothner.com/ From peter at ahe.dk Fri Aug 3 10:15:56 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Fri, 3 Aug 2007 10:15:56 -0700 Subject: problem building compiler with nb 6m10 In-Reply-To: <46B35BDD.4010601@sun.com> References: <46B0BB75.1090509@sun.com> <46B2E061.7010606@sun.com> <71AE3D2B-23E7-4B0D-92B2-B01A2C8C77F5@sun.com> <46B35BDD.4010601@sun.com> Message-ID: If you're going through svn as setup by release engineering, you will have to wait a long time. Unfortunately, that is setup so it can take more than four weeks for a change to get through, see the discussion at the end of this: http://blogs.sun.com/ahe/entry/upcoming_compiler_fixes What you really need is patience while Jon fixes the real issue: direct access to a shared repository. Unfortunately, the path is blocked with obstacles surprisingly neither of technical nor legal nature. Cheers, Peter On 8/3/07, Per Bothner wrote: > Jonathan Gibbons wrote: > > I am sorry for the inconvenience. We have been focussing our limited > > efforts > > on a single new build system for the compiler and related tools that > > will be > > used by Sun's Release Engineering, and compiler developers, and any other > > people interested in working on the compiler via Ant or NetBeans. > > This will replace the disparate build systems in use today by these > > different > > audiences. > > I'm very much looking forward to it! > > Until then, could Jesse's patch be checked in? > > (I should have bugged you earlier about the issue - you probably > didn't realize that it really was an inconvenience for us. > Partly our fault for going down the wrong path, using snapshots > without svn. Fixed now, I believe.) > -- > --Per Bothner > per.bothner at sun.com per at bothner.com http://per.bothner.com/ > From Jonathan.Gibbons at Sun.COM Fri Aug 3 10:29:00 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 03 Aug 2007 10:29:00 -0700 Subject: problem building compiler with nb 6m10 In-Reply-To: References: <46B0BB75.1090509@sun.com> <46B2E061.7010606@sun.com> <71AE3D2B-23E7-4B0D-92B2-B01A2C8C77F5@sun.com> <46B35BDD.4010601@sun.com> Message-ID: <27CFF90B-28ED-4A20-A74E-89E2B8A8369D@Sun.COM> Peter, I believe Tim Bell is working on mirroring the internal staging repositories to alleviate the problem. -- Jon On Aug 3, 2007, at 10:15 AM, Peter Ah? wrote: > If you're going through svn as setup by release engineering, you will > have to wait a long time. Unfortunately, that is setup so it can take > more than four weeks for a change to get through, see the discussion > at the end of this: > http://blogs.sun.com/ahe/entry/upcoming_compiler_fixes > > What you really need is patience while Jon fixes the real issue: > direct access to a shared repository. Unfortunately, the path is > blocked with obstacles surprisingly neither of technical nor legal > nature. > > Cheers, > Peter > > On 8/3/07, Per Bothner wrote: >> Jonathan Gibbons wrote: >>> I am sorry for the inconvenience. We have been focussing our >>> limited >>> efforts >>> on a single new build system for the compiler and related tools that >>> will be >>> used by Sun's Release Engineering, and compiler developers, and >>> any other >>> people interested in working on the compiler via Ant or NetBeans. >>> This will replace the disparate build systems in use today by these >>> different >>> audiences. >> >> I'm very much looking forward to it! >> >> Until then, could Jesse's patch be checked in? >> >> (I should have bugged you earlier about the issue - you probably >> didn't realize that it really was an inconvenience for us. >> Partly our fault for going down the wrong path, using snapshots >> without svn. Fixed now, I believe.) >> -- >> --Per Bothner >> per.bothner at sun.com per at bothner.com http://per.bothner.com/ >> From Tom.Ball at Sun.COM Fri Aug 3 10:31:12 2007 From: Tom.Ball at Sun.COM (Tom Ball) Date: Fri, 03 Aug 2007 10:31:12 -0700 Subject: problem building compiler with nb 6m10 In-Reply-To: References: <46B0BB75.1090509@sun.com> <46B2E061.7010606@sun.com> <71AE3D2B-23E7-4B0D-92B2-B01A2C8C77F5@sun.com> <46B35BDD.4010601@sun.com> Message-ID: <46B36660.4000808@sun.com> We don't actually need a current javac source, just a recent publicly-available one (public svn repository, source bundle, whatever). We then apply a patch file to make the few changes we have (mostly access), but as a nice side-effect any changes Robert or Lubo pulled down get included in the patch, so we're then current. It's not a permanent solution, but it beats the current system these guys are using of emailing jar files to each other from a source management perspective. Generating and committing patch files is a pain, but there are a couple of advantages to this approach. First, anyone inside or outside the team can regenerate the source base that our extended javac.jar used, enabling source debugging and profiling of that code. Second, we fulfill our GPL obligation to make our changes publicly accessible. Third, we don't have to bother the javac team (Per, are you listening?) while they are working on a long-term solution. Tom Peter Ah? wrote: > If you're going through svn as setup by release engineering, you will > have to wait a long time. Unfortunately, that is setup so it can take > more than four weeks for a change to get through, see the discussion > at the end of this: > http://blogs.sun.com/ahe/entry/upcoming_compiler_fixes > > What you really need is patience while Jon fixes the real issue: > direct access to a shared repository. Unfortunately, the path is > blocked with obstacles surprisingly neither of technical nor legal > nature. > > Cheers, > Peter > > On 8/3/07, Per Bothner wrote: >> Jonathan Gibbons wrote: >>> I am sorry for the inconvenience. We have been focussing our limited >>> efforts >>> on a single new build system for the compiler and related tools that >>> will be >>> used by Sun's Release Engineering, and compiler developers, and any other >>> people interested in working on the compiler via Ant or NetBeans. >>> This will replace the disparate build systems in use today by these >>> different >>> audiences. >> I'm very much looking forward to it! >> >> Until then, could Jesse's patch be checked in? >> >> (I should have bugged you earlier about the issue - you probably >> didn't realize that it really was an inconvenience for us. >> Partly our fault for going down the wrong path, using snapshots >> without svn. Fixed now, I believe.) >> -- >> --Per Bothner >> per.bothner at sun.com per at bothner.com http://per.bothner.com/ >> From linuxhippy at gmail.com Wed Aug 8 12:43:49 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 8 Aug 2007 21:43:49 +0200 Subject: Howto disable server-class machine detection system wide? Message-ID: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> Hello, I recently upgraded my Linux-Laptop to 2GB Ram because I guess compatible memory won't be as cheap as now soon ;) However this means I've now a server-class machine, (Core2Duo + 2GB Ram), which is quite nerving because the server-compiler is used all the time, although I use this machine mostly for desktop apps. The only system-wide solution I found was to replace libjvm.so in /server with the client-jvm but I am not really happy with that. Are there better soltions to disable server-class machine detection _system wide_, like a global config file which contains options used all the time (also for webstart and the plugin)? Thank you in advance, lg Clemens From john.pampuch at sun.com Wed Aug 8 13:41:21 2007 From: john.pampuch at sun.com (John Pampuch) Date: Wed, 08 Aug 2007 13:41:21 -0700 Subject: Howto disable server-class machine detection system wide? In-Reply-To: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> References: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> Message-ID: <46BA2A71.1020109@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070808/f72e38d9/attachment.html From peter at ahe.dk Wed Aug 8 13:49:22 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Wed, 8 Aug 2007 13:49:22 -0700 Subject: Howto disable server-class machine detection system wide? In-Reply-To: <46BA2A71.1020109@sun.com> References: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> <46BA2A71.1020109@sun.com> Message-ID: This is off-topic for compiler-dev at openjdk. Please continue this discussion here: http://forum.java.sun.com/category.jspa?categoryID=41 Cheers, Peter On 8/8/07, John Pampuch wrote: > > Are you finding performance, startup time or other issues in this case? > > What kind of applications are you frequently using? How are you launching > them? > > Thanks, > > -John > > > Clemens Eisserer wrote: > Hello, > > I recently upgraded my Linux-Laptop to 2GB Ram because I guess > compatible memory won't be as cheap as now soon ;) > > However this means I've now a server-class machine, (Core2Duo + 2GB > Ram), which is quite nerving because the server-compiler is used all > the time, although I use this machine mostly for desktop apps. > > The only system-wide solution I found was to replace libjvm.so in > /server with the client-jvm but I am not really happy with that. > > Are there better soltions to disable server-class machine detection > _system wide_, like a global config file which contains options used > all the time (also for webstart and the plugin)? > > Thank you in advance, lg Clemens > > From Peter.Kessler at Sun.COM Wed Aug 8 13:56:51 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 08 Aug 2007 13:56:51 -0700 Subject: Howto disable server-class machine detection system wide? In-Reply-To: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> References: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> Message-ID: <46BA2E13.4020304@Sun.COM> Clemens Eisserer wrote: > Hello, > > I recently upgraded my Linux-Laptop to 2GB Ram because I guess > compatible memory won't be as cheap as now soon ;) > > However this means I've now a server-class machine, (Core2Duo + 2GB > Ram), which is quite nerving because the server-compiler is used all > the time, although I use this machine mostly for desktop apps. > > The only system-wide solution I found was to replace libjvm.so in > /server with the client-jvm but I am not really happy with that. > > Are there better soltions to disable server-class machine detection > _system wide_, like a global config file which contains options used > all the time (also for webstart and the plugin)? > > Thank you in advance, lg Clemens This topic has nothing to do with the Java compiler. Or anything to do with the OpenJDK project. It's a JVM usage question, and probably better suited to the Java Runtime Environment (JRE) forum on java.sun.com http://forum.java.sun.com/forum.jspa?forumID=32 If you post it there, you'll probably get responses from others who have addressed this problem. (If it is a problem.) ... peter From linuxhippy at gmail.com Wed Aug 8 15:26:42 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 9 Aug 2007 00:26:42 +0200 Subject: Howto disable server-class machine detection system wide? In-Reply-To: <46BA2A71.1020109@sun.com> References: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> <46BA2A71.1020109@sun.com> Message-ID: <194f62550708081526v44ccf5a0u7b0edfed5bc5aff@mail.gmail.com> Hello again, > Are you finding performance, startup time or other issues in this > case? Perceived performance and latency with GUI applications is my largest problem. > What kind of applications are you frequently using? How are you > launching > them? Java-Applets and Eclipse mostly, so more or less destop application which don't benefit from the longer compilation times/better code quality. > This topic has nothing to do with the Java compiler. Or anything > to do with the OpenJDK project. I already asked at forum.java.sun.com but got no response. As far as I can see there is no way for the official java binaries to disable server-class detection system-wide, right? If so, I'll file a bug-report. lg Clemens From Peter.Kessler at Sun.COM Wed Aug 8 16:10:07 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 08 Aug 2007 16:10:07 -0700 Subject: Howto disable server-class machine detection system wide? In-Reply-To: <194f62550708081526v44ccf5a0u7b0edfed5bc5aff@mail.gmail.com> References: <194f62550708081243h4b02939fvcaf6e5e493421199@mail.gmail.com> <46BA2A71.1020109@sun.com> <194f62550708081526v44ccf5a0u7b0edfed5bc5aff@mail.gmail.com> Message-ID: <46BA4D4F.9050000@Sun.COM> Clemens Eisserer wrote: > Hello again, > >> Are you finding performance, startup time or other issues in this >> case? > Perceived performance and latency with GUI applications is my largest problem. > >> What kind of applications are you frequently using? How are you >> launching >> them? > Java-Applets and Eclipse mostly, so more or less destop application > which don't benefit from the longer compilation times/better code > quality. > >> This topic has nothing to do with the Java compiler. Or anything >> to do with the OpenJDK project. > I already asked at forum.java.sun.com but got no response. As far as I > can see there is no way for the official java binaries to disable > server-class detection system-wide, right? > If so, I'll file a bug-report. > > lg Clemens I've replied to your post on http://forum.java.sun.com/thread.jspa?messageID=9814959 Let's take this discussion off of compiler-dev at openjdk.java.net. ... peter From Jonathan.Gibbons at Sun.COM Thu Aug 9 18:10:11 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 09 Aug 2007 18:10:11 -0700 Subject: KSL updated to b16 Message-ID: <46BBBAF3.9000100@sun.com> Team, I've finally figured out enough Subversion to update the KSL repository to the level of OpenJDK b16. (TeamWare, Mercurial, Subversion ... too many SCMs!) I would have done b17, except that it is missing the tests, because of an over-optimistic build optimization. Whoops. Now that I think I have it figured out, I'll try and keep the sources updated in a more timely manner. -- Jon From samkraju.java at gmail.com Thu Aug 9 20:57:08 2007 From: samkraju.java at gmail.com (Sam K. Raju) Date: Fri, 10 Aug 2007 09:27:08 +0530 Subject: Problem while building the HotSpot (javac) compiler Message-ID: Hi All, I downloaded the compiler source 'compiler-7-ea-src-b17-02_aug_2007.zip' from the download site and tried to build it in Netbeans but it showed an error message that their is no version-template.java file in the 'compiler\src\share\classes\com\sun\tools\javac\resources' directory. I had an old subversion of compiler and it had the version-template.java file. Now I want to know whether the file is intentionally removed from the bundle or by mistake. And if it is intentionally, then how can I build the source. Thanks, -- Sam K. Raju Software Engineer Mobile +919871984108 Email samkraju.java at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070810/f32e4739/attachment.html From Jonathan.Gibbons at Sun.COM Thu Aug 9 21:25:35 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 09 Aug 2007 21:25:35 -0700 Subject: Problem while building the HotSpot (javac) compiler In-Reply-To: References: Message-ID: <519CC462-2CDD-4EDA-B571-5BC73D751484@sun.com> Sam, (I'm not sure what HotSpot is doing in the subject line.) The file was renamed a while back, and the build files for use with this bundle were accidentally not updated. The easiest quickest workaround is to use an older copy of the file. -- Jon On Aug 9, 2007, at 8:57 PM, Sam K. Raju wrote: > Hi All, > I downloaded the compiler source 'compiler-7-ea-src- > b17-02_aug_2007.zip' from the download site and tried to build it > in Netbeans but it showed an error message that their is no version- > template.java file in the 'compiler\src\share\classes\com\sun\tools > \javac\resources' directory. I had an old subversion of compiler > and it had the version-template.java file. > Now I want to know whether the file is intentionally removed > from the bundle or by mistake. And if it is intentionally, then how > can I build the source. > > Thanks, > > > > -- > Sam K. Raju > Software Engineer > Mobile +919871984108 > Email samkraju.java at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070809/658c6588/attachment.html From Per.Bothner at Sun.COM Fri Aug 10 05:48:50 2007 From: Per.Bothner at Sun.COM (Per Bothner) Date: Fri, 10 Aug 2007 05:48:50 -0700 Subject: compiling to byte-code vs java Message-ID: <46BC5EB2.9060700@sun.com> This appears to be relevant to the issue of whether to compile "Java trees" or make use of javafx-specific code generation. The code is about generating Java vs bytecodes, but it also applies to whether we should re-write to Java ASTs or generate code directly from ExpressionBlock. I'll ask for more information, but the message seems to suggest that pushing values of the JVM stack is more efficient than using temporary variables (as you would have to when generating Java ASTs or Java source). -- --Per Bothner per.bothner at sun.com per at bothner.com http://per.bothner.com/ -------------- next part -------------- An embedded message was scrubbed... From: David Pollak Subject: Re: Language Role Call, and a Call to Action Date: Thu, 09 Aug 2007 08:08:04 -0700 Size: 8397 Url: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070810/08589aa4/attachment.nws From Jonathan.Gibbons at Sun.COM Fri Aug 10 07:21:51 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 10 Aug 2007 07:21:51 -0700 Subject: compiling to byte-code vs java In-Reply-To: <46BC5EB2.9060700@sun.com> References: <46BC5EB2.9060700@sun.com> Message-ID: <5F66B60C-F190-4155-A051-36CBB2E65050@sun.com> Per, I don't doubt that you might be able to do better by going straight to bytecodes. The issue was always that it was thought to be quicker and safer to create a compiler that went via Java trees. The optimizations could come in phase 2, once we have a working compiler. Until then, it is more important to create a compiler that works that to polish the bits. -- Jon On Aug 10, 2007, at 5:48 AM, Per Bothner wrote: > This appears to be relevant to the issue of whether to compile > "Java trees" or make use of javafx-specific code generation. > The code is about generating Java vs bytecodes, but it also > applies to whether we should re-write to Java ASTs or generate > code directly from ExpressionBlock. > > I'll ask for more information, but the message seems to > suggest that pushing values of the JVM stack is more efficient > than using temporary variables (as you would have to when > generating Java ASTs or Java source). > -- > --Per Bothner > per.bothner at sun.com per at bothner.com http://per.bothner.com/ > > From: David Pollak > Date: August 9, 2007 8:08:04 AM PDT > To: jvm-languages at googlegroups.com > Subject: Re: Language Role Call, and a Call to Action > Reply-To: jvm-languages at googlegroups.com > > > > > On 8/9/07, Charles Oliver Nutter wrote: > > parren wrote: > > On Aug 5, 10:59 pm, Charles Oliver Nutter > > wrote: > >> Please reply to this email with just a couple words describing what > >> group you represent (language implementation, library > implementation, > >> JVM implementation, employer, whatever) so we can get some sort > of tally > >> of who's on the line. > > > > I represent the Abacus Formula Compiler - a spreadsheet to JVM > > bytecode compiler used to let users customize computations inside > of, > > for example, financial applications. Still closed source, but > soon to > > be GPLed, at least. Uses a mini functional language internally that > > gets compiled (fold et al.). But: it currently aims at being fully > > decompilable by JODE to Java source so people can understand what it > > generated. Might preclude using new features the JVM is going to > > introduce. > > Interesting. You say you compile straight to bytecode though? What > about > just generating Java code as an intermediate step? I believe this > is how > Quercus works, and I know of a few others that do this rather than > bytecode generation. > > When I did the byte-code generator for the Integer spreadsheet, I > found there were efficiencies gained by keeping intermediate > results on the stack which one does not get with spreadsheet -> > Java -> byte-code. In some cases, I got 20%+ performance improvement. > > - Charlie > > > > > > > -- > lift, the fast, powerful, easy web framework > http://liftweb.net > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "JVM Languages" group. > To post to this group, send email to jvm-languages at googlegroups.com > To unsubscribe from this group, send email to jvm-languages- > unsubscribe at googlegroups.com > For more options, visit this group at http://groups.google.com/ > group/jvm-languages?hl=en > -~----------~----~----~----~------~----~------~--~--- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070810/32efcfd8/attachment.html From peter at ahe.dk Fri Aug 10 08:46:12 2007 From: peter at ahe.dk (=?ISO-8859-1?Q?Peter_Ah=E9?=) Date: Fri, 10 Aug 2007 08:46:12 -0700 Subject: compiling to byte-code vs java In-Reply-To: <5F66B60C-F190-4155-A051-36CBB2E65050@sun.com> References: <46BC5EB2.9060700@sun.com> <5F66B60C-F190-4155-A051-36CBB2E65050@sun.com> Message-ID: If you can demonstrate a 20% performance improvement, it could make sense for javac to be able to use the stack for intermediate results (either by adding this as an optimization or supporting special tree nodes that does not match Java source code). However, this could be a HotSpot issue instead. Cheers, Peter On 8/10/07, Jonathan Gibbons wrote: > Per, > > I don't doubt that you might be able to do better by going straight to > bytecodes. > The issue was always that it was thought to be quicker and safer to create > a > compiler that went via Java trees. The optimizations could come in phase > 2, > once we have a working compiler. Until then, it is more important to create > a compiler that works that to polish the bits. > > -- Jon > > > > > > On Aug 10, 2007, at 5:48 AM, Per Bothner wrote: > > This appears to be relevant to the issue of whether to compile > "Java trees" or make use of javafx-specific code generation. > The code is about generating Java vs bytecodes, but it also > applies to whether we should re-write to Java ASTs or generate > code directly from ExpressionBlock. > > I'll ask for more information, but the message seems to > suggest that pushing values of the JVM stack is more efficient > than using temporary variables (as you would have to when > generating Java ASTs or Java source). > -- > --Per Bothner > per.bothner at sun.com per at bothner.com http://per.bothner.com/ > > From: David Pollak > Date: August 9, 2007 8:08:04 AM PDT > To: jvm-languages at googlegroups.com > Subject: Re: Language Role Call, and a Call to Action > Reply-To: jvm-languages at googlegroups.com > > > > > On 8/9/07, Charles Oliver Nutter wrote: > > > > parren wrote: > > > On Aug 5, 10:59 pm, Charles Oliver Nutter > > > wrote: > > >> Please reply to this email with just a couple words describing what > > >> group you represent (language implementation, library implementation, > > >> JVM implementation, employer, whatever) so we can get some sort of > tally > > >> of who's on the line. > > > > > > I represent the Abacus Formula Compiler - a spreadsheet to JVM > > > bytecode compiler used to let users customize computations inside of, > > > for example, financial applications. Still closed source, but soon to > > > be GPLed, at least. Uses a mini functional language internally that > > > gets compiled (fold et al.). But: it currently aims at being fully > > > decompilable by JODE to Java source so people can understand what it > > > generated. Might preclude using new features the JVM is going to > > > introduce. > > > > Interesting. You say you compile straight to bytecode though? What about > > just generating Java code as an intermediate step? I believe this is how > > Quercus works, and I know of a few others that do this rather than > > bytecode generation. > > When I did the byte-code generator for the Integer spreadsheet, I found > there were efficiencies gained by keeping intermediate results on the stack > which one does not get with spreadsheet -> Java -> byte-code. In some > cases, I got 20%+ performance improvement. > > > - Charlie > > > > > > > > > > > > -- > lift, the fast, powerful, easy web framework > http://liftweb.net > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to jvm-languages at googlegroups.com > To unsubscribe from this group, send email to > jvm-languages-unsubscribe at googlegroups.com > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > From Per.Bothner at Sun.COM Sat Aug 11 04:26:11 2007 From: Per.Bothner at Sun.COM (Per Bothner) Date: Sat, 11 Aug 2007 04:26:11 -0700 Subject: compiling to byte-code vs java In-Reply-To: References: <46BC5EB2.9060700@sun.com> <5F66B60C-F190-4155-A051-36CBB2E65050@sun.com> Message-ID: <46BD9CD3.80500@sun.com> Jonathan Gibbons wrote: > I don't doubt that you might be able to do better by going straight to > bytecodes. The issue was always that it was thought to be quicker and > safer to create a compiler that went via Java trees. The > optimizations could come in phase 2, once we have a working compiler. > Until then, it is more important to create a compiler that works that > to polish the bits. To clarify: I did not implement BlockExpression and generate bytecode directly from it for performance reasons. I did so because that seems both cleaner and simpler than adding an extra compiler phase to re-write nested expressions into assignments to temporary variables. This allowed me to simplify the existing (but incomplete) code to handle object literals, as another example where a complex expressions needed a temporary local variable. (The object literal case can, I believe, be handled using LetExpr, which is a special case of BlockExpression.) However, Robest made the point that implementing BlockExpresssion by direct code generation would generate code that HotSpot would not be able to optimize as well. From what John Rose and others have said on the jvm-languages list, we need not be concerned about this - generating code to leave the BlockExpression value on the JVM stack should be at least no worse. Peter Ah? wrote: > If you can demonstrate a 20% performance improvement, it could make > sense for javac to be able to use the stack for intermediate results > (either by adding this as an optimization or supporting special tree > nodes that does not match Java source code). However, this could be a > HotSpot issue instead. There was some surprise on the jvm-languages as this result, and it was indeed suggested this might be a HotSpot bug. -- --Per Bothner per.bothner at sun.com per at bothner.com http://per.bothner.com/ From leszekp at Safe-mail.net Mon Aug 20 05:18:52 2007 From: leszekp at Safe-mail.net (leszekp at Safe-mail.net) Date: Mon, 20 Aug 2007 08:18:52 -0400 Subject: Reusable and replaceable compiler parts Message-ID: Hello A "classic" compiler, javac more or less too, is composed of a few parts: - lexer (scanner) - parser - semantic checker - in javac it is done by tree walkers - optimizer, tree transformer, etc - code generator If an api to above parts/modules existed they might be reused separately. Possible uses are in example: - replace lexer and parser by other ones. This way various frontends may be constructed, in example ruby, python, scripting languages etc - bypass parser, directly construct abstract syntex tree, may be used by a jsp compiler - replace backend, output to another language instead of bytecodes Of course an interface to compiler parts should be standarized somehow. Abstract syntax trees probably should be modelled less around java syntax and more around jvm operations. I think modularization it's the future of compiler tools in general as there will be more and more demand for domain specific languages. Leszek Piotrowicz From mcconnell at dpml.net Mon Aug 20 09:41:12 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Tue, 21 Aug 2007 02:11:12 +0930 Subject: Reusable and replaceable compiler parts In-Reply-To: References: Message-ID: <003901c7e348$eb793c50$0301a8c0@julia> Leszek: I agree with argument and I think the work going on under the 294 and 277 JSRs (under the Module Project) [1] will have an important role to play in this subject. However - I must also note that the javac compiler falls into that grey area of bootstrapping the solution and being a part of the solution. Assuming the modularization activities pull together as a formal part of the SE7, I figure that the sort of customization you are suggesting will fall into the feasible spectrum (but 294/277 inclusion will be a prerequisite). Cheers, Steve. [1] OpenJDK Module Project http://openjdk.java.net/projects/modules/ -----Original Message----- From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev-bounces at openjdk.java.net] On Behalf Of leszekp at Safe-mail.net Sent: Monday, 20 August 2007 9:49 PM To: compiler-dev at openjdk.java.net Subject: Reusable and replaceable compiler parts Hello A "classic" compiler, javac more or less too, is composed of a few parts: - lexer (scanner) - parser - semantic checker - in javac it is done by tree walkers - optimizer, tree transformer, etc - code generator If an api to above parts/modules existed they might be reused separately. Possible uses are in example: - replace lexer and parser by other ones. This way various frontends may be constructed, in example ruby, python, scripting languages etc - bypass parser, directly construct abstract syntex tree, may be used by a jsp compiler - replace backend, output to another language instead of bytecodes Of course an interface to compiler parts should be standarized somehow. Abstract syntax trees probably should be modelled less around java syntax and more around jvm operations. I think modularization it's the future of compiler tools in general as there will be more and more demand for domain specific languages. Leszek Piotrowicz From lahoda at gmail.com Mon Aug 20 09:50:42 2007 From: lahoda at gmail.com (Jan Lahoda) Date: Mon, 20 Aug 2007 18:50:42 +0200 Subject: @SuppressWarnings("deprecation") does not not work correctly? Message-ID: <87d9996a0708200950pfbf8f1crc54bc11e573a8a22@mail.gmail.com> Hi, when I try to compile the following piece of code with "-Xlint:deprecation", it produces /tmp/JavaApplication1/src/javaapplication1/Main.java:7: warning: [deprecation] java.rmi.RMISecurityException in java.rmi has been deprecated This does not seem right to me, as JLS 9.6.1.5 says that: "a Java compiler must not report any warning identified by one of *S1, ... , Sk* if that warning would have been generated as a result of the annotated declaration or any of its parts" I read this in such a way that even the type of the variable should be covered by the SuppressWarnings. Is this a bug or do I misread the specification? I have tested this on: [snip]/jdk17/bin$ ./java -version java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b18) Java HotSpot(TM) Server VM (build 1.7.0-ea-b18, mixed mode) Thanks, Jan ------------------------------------------------------------------------------- package javaapplication1; public class Main { public static void main(String[] args) { @SuppressWarnings("deprecation") java.rmi.RMISecurityException ex; } } ---------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070820/26e9453b/attachment.html From Jonathan.Gibbons at Sun.COM Mon Aug 20 09:56:37 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 20 Aug 2007 09:56:37 -0700 Subject: @SuppressWarnings("deprecation") does not not work correctly? In-Reply-To: <87d9996a0708200950pfbf8f1crc54bc11e573a8a22@mail.gmail.com> References: <87d9996a0708200950pfbf8f1crc54bc11e573a8a22@mail.gmail.com> Message-ID: <5CBB0C83-AA52-4EA7-86D5-7640EC6F3ABC@sun.com> Jan, That looks like a bug. Please feel free to file a bug report. -- Jon G. On Aug 20, 2007, at 9:50 AM, Jan Lahoda wrote: > Hi, > when I try to compile the following piece of code with "- > Xlint:deprecation", it produces > > /tmp/JavaApplication1/src/javaapplication1/Main.java:7: warning: > [deprecation] java.rmi.RMISecurityException in java.rmi has been > deprecated > > This does not seem right to me, as JLS 9.6.1.5 says that: > "a Java compiler must not report any warning identified by one of > S1, ... , S k if that warning would have been generated as a result > of the annotated declaration or any of its parts" > > I read this in such a way that even the type of the variable should > be covered by the SuppressWarnings. Is this a bug or do I misread > the specification? > > I have tested this on: > [snip]/jdk17/bin$ ./java -version > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b18) > Java HotSpot(TM) Server VM (build 1.7.0-ea-b18, mixed mode) > > Thanks, > Jan > > ---------------------------------------------------------------------- > --------- > package javaapplication1; > > public class Main { > > public static void main(String[] args) { > @SuppressWarnings("deprecation") > java.rmi.RMISecurityException ex; > } > > } > ---------------------------------------------------------------------- > ------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20070820/5b1c9659/attachment.html From jesse.glick at sun.com Thu Aug 23 20:08:20 2007 From: jesse.glick at sun.com (Jesse Glick) Date: Thu, 23 Aug 2007 23:08:20 -0400 Subject: @SuppressWarnings("deprecation") does not not work correctly? In-Reply-To: <87d9996a0708200950pfbf8f1crc54bc11e573a8a22@mail.gmail.com> References: <87d9996a0708200950pfbf8f1crc54bc11e573a8a22@mail.gmail.com> Message-ID: Jan Lahoda wrote: > when I try to compile the following piece of code with > "-Xlint:deprecation", it produces > > /tmp/JavaApplication1/src/javaapplication1/Main.java:7: warning: > [deprecation] java.rmi.RMISecurityException in java.rmi has been deprecated > > @SuppressWarnings("deprecation") > java.rmi.RMISecurityException ex; I found and filed this some time ago: http://bugs.sun.com/view_bug.do?bug_id=6460147 -J. -- jesse.glick at sun.com netbeans.org ant.apache.org hudson.dev.java.net http://google.com/search?q=e%5E%28pi*i%29%2B1 From ted at tedneward.com Sat Aug 25 21:36:45 2007 From: ted at tedneward.com (Ted Neward) Date: Sat, 25 Aug 2007 21:36:45 -0700 Subject: Reusable and replaceable compiler parts In-Reply-To: <003901c7e348$eb793c50$0301a8c0@julia> References: <003901c7e348$eb793c50$0301a8c0@julia> Message-ID: <002501c7e79a$b7cdb4c0$27691e40$@com> I'm curious--what part of JSR 277's charter do you think directly yields a result of a modular compiler? It seems something of a stretch to make that connection, so I'm curious as to the logic at work there. (No offense intended; I'm genuinely curious.) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev- > bounces at openjdk.java.net] On Behalf Of Stephen J. McConnell > Sent: Monday, August 20, 2007 9:41 AM > To: compiler-dev at openjdk.java.net > Subject: RE: Reusable and replaceable compiler parts > > > Leszek: > > I agree with argument and I think the work going on under the 294 and > 277 > JSRs (under the Module Project) [1] will have an important role to play > in > this subject. > > However - I must also note that the javac compiler falls into that grey > area > of bootstrapping the solution and being a part of the solution. > Assuming > the modularization activities pull together as a formal part of the > SE7, I > figure that the sort of customization you are suggesting will fall into > the > feasible spectrum (but 294/277 inclusion will be a prerequisite). > > Cheers, Steve. > > [1] OpenJDK Module Project > http://openjdk.java.net/projects/modules/ > > > > > -----Original Message----- > From: compiler-dev-bounces at openjdk.java.net > [mailto:compiler-dev-bounces at openjdk.java.net] On Behalf Of > leszekp at Safe-mail.net > Sent: Monday, 20 August 2007 9:49 PM > To: compiler-dev at openjdk.java.net > Subject: Reusable and replaceable compiler parts > > Hello > > A "classic" compiler, javac more or less too, is composed of a few > parts: > - lexer (scanner) > - parser > - semantic checker - in javac it is done by tree walkers > - optimizer, tree transformer, etc > - code generator > > If an api to above parts/modules existed they might be reused > separately. > Possible uses are in example: > > - replace lexer and parser by other ones. This way various frontends > may > be constructed, in example ruby, python, scripting languages etc > - bypass parser, directly construct abstract syntex tree, may be used > by a jsp compiler > - replace backend, output to another language instead of bytecodes > > Of course an interface to compiler parts should be standarized somehow. > Abstract syntax trees probably should be modelled less around java > syntax > and more around jvm operations. I think modularization it's the future > of > compiler tools in general as there will be more and more demand for > domain specific languages. > > Leszek Piotrowicz > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.1/962 - Release Date: > 8/20/2007 1:08 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.6/971 - Release Date: 8/24/2007 2:59 PM From mcconnell at dpml.net Mon Aug 27 00:55:59 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Mon, 27 Aug 2007 17:25:59 +0930 Subject: Reusable and replaceable compiler parts In-Reply-To: <002501c7e79a$b7cdb4c0$27691e40$@com> References: <003901c7e348$eb793c50$0301a8c0@julia> <002501c7e79a$b7cdb4c0$27691e40$@com> Message-ID: <001b01c7e87f$b6810d70$0301a8c0@julia> Ted wrote: > I'm curious--what part of JSR 277's charter do you think directly yields a > result of a modular compiler? It seems something of a stretch to make that > connection, so I'm curious as to the logic at work there. (No offense > intended; I'm genuinely curious.) Ted, The 277 charter does not directly deal with anything specific concerning modularization of a compiler. However, JSR 277 (and the 294 sister JSR) deals with the more general subject of modularization. The Module Project is currently working on specifications, low-level JRE services, and tools - that may make a substantive difference to the way in which functional modularization is delivered within the JRE. Of particular importance is the relationship between runtime module loading and ServiceLoader which is used as a service extension point across a number of javax packages (tools, imageio, management, naming) and internal implementation classes. The significant link between "compiler modularization" and 277 is in the potential improvements in runtime integrity that 277-based modularization can deliver over and above the current JRE extension mechanisms. The compiler project is to some extent ahead of the game here in that the Tools API is a relatively recent addition that leverages ServiceLoader as a core extension mechanism - and as a consequence the incorporation of module-based service loading into ServiceLoader would deliver a significant expansion to the potential scale of extensions (because it directly addresses scalability of the extension mechanism and elimination of class conflict through module isolation). I should point out that the relationship between 277 and ServiceLoader and the overall subject of service location via modules (or module identifiers) is not currently defined (although there is an internal strawman document within the expert group dealing with the subject). As such, my comments should be viewed as speculative - however, I expect to see more concrete details on this subject as more documentation and code-drops come out of the Module Project. Cheers, Steve. -------------------------- Stephen J. McConnell mailto:mcconnell at dpml.net http://www.dpml.net From pugh at cs.umd.edu Thu Aug 30 11:56:24 2007 From: pugh at cs.umd.edu (Bill Pugh) Date: Thu, 30 Aug 2007 14:56:24 -0400 Subject: Bug in classfile spec Section 4.8.18 Message-ID: <324F99AD-6B08-4291-829D-62B04A37E710@cs.umd.edu> Alex, There is a bug in the classfile spec, section 4.8.18: > The value of the num_parameters item gives the number of parameters > of the method represented by the method_infostructure on which the > annotation occurs. (This duplicates information that could be > extracted from the method descriptor.) Actually, num_parameters duplicates information that could be extracted from the signature, not from the descriptor. Spelling out the squirrelly correspondence between parameters in a Runtime(Inv|V)isibleParameterAnnotations and the actual parameters is probably worth while. I just found a bug in ASM due to this. Bill From Jonathan.Gibbons at Sun.COM Fri Aug 31 13:42:25 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 31 Aug 2007 13:42:25 -0700 Subject: langtools in b20 Message-ID: <46D87D31.8010006@sun.com> Gang, Andreas just stopped by my office to tell me that the work for the langtools/ separation has made it into the master workspace this morning. This means you all will be able to see it in build 20, coming soon. -- Jon