From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6543 invoked by alias); 8 May 2011 23:01:48 -0000 Received: (qmail 6482 invoked by uid 22791); 8 May 2011 23:01:46 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,TW_GC X-Spam-Check-By: sourceware.org Received: from relay02.pair.com (HELO relay02.pair.com) (209.68.5.16) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sun, 08 May 2011 23:01:32 +0000 Received: (qmail 91639 invoked from network); 8 May 2011 23:01:31 -0000 Received: from 195.135.221.2 (HELO g159.suse.de) (195.135.221.2) by relay02.pair.com with SMTP; 8 May 2011 23:01:31 -0000 X-pair-Authenticated: 195.135.221.2 Date: Sun, 08 May 2011 23:01:00 -0000 From: Gerald Pfeifer To: Steven Bosscher cc: gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Subject: Re: [wwwdocs] Use regular

markup for java/projects.html In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-2133373664-1304895703=:3911" Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2011-q2/txt/msg00039.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-2133373664-1304895703=:3911 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-length: 3214 On Sat, 30 Apr 2011, Steven Bosscher wrote: >> 2011-04-26  Gerald Pfeifer   >> >>        * projects.html: Use regular

markup for section headers >>        instead of fake tables. > The "Compiler improvements" section is 10 years behind on GCC's > development (tree-ssa!). The "recently released" jMocha is from 2000 > and I can't find it anywhere for download. The "Open JVM Integration" > is obsolete. There is very little on this page that is still useful > information for someone willing to contribute to GCJ... Hard to disagree, Steven. It's just that I am not to well aware of what's happening in Java land. I was hoping my patch made it easier for someone with more background to update this page in terms of contents, but seeing that nobody took action on your analysis I cooked up the patch below which I plan on committing in a couple of days. Gerald 2011-05-09 Gerald Pfeifer * projects.html: Update name of java mailing list. (Plugin for Mozilla): Remove section. (Compiler Improvements): Remove tree inlining item. (Benchmark infrastructure): Remove reference to jMocha. Index: projects.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/java/projects.html,v retrieving revision 1.34 diff -u -r1.34 projects.html --- projects.html 26 Apr 2011 20:25:34 -0000 1.34 +++ projects.html 8 May 2011 22:59:49 -0000 @@ -12,7 +12,7 @@ to see someone pick up and run with. If you're interested in any of these, be sure to send a note with your questions, ideas or intentions to the java-discuss +href="mailto:java@gcc.gnu.org">java mailing list. Similarly, if you would like to see a project listed here that isn't, send a patch for this HTML file to the java-patches list. @@ -27,18 +27,6 @@

-

Plugin for Mozilla

- -

-Mozilla is open-source web browser, -designed for standards compliance, performance and portability. The -Open JVM Integration project (OJI) is a Mozilla sub-project, and is -working to extend the browser to allow Java virtual machines to be -plugged into Mozilla. A gij based plugin would be very nice indeed -(gijzilla?). -

- -

Benchmark infrastructure

@@ -49,8 +37,7 @@

Bryce McKinlay has put -together a list of some benchmarks that run on GCJ. IBM has also -recently released a set of "micro benchmarks" called jMocha. +together a list of some benchmarks that run on GCJ. Building some infrastructure around these would be incredibly useful.

@@ -97,11 +84,6 @@

Compiler improvements

    -
  • We'd like gcj to do tree-level inlining like the C++ - compiler. We're most of the way there (when compiling - from Java source code), since gcj already represents - entire functions as trees.
    • -
  • Once we have tree-level inlining, we can use it to sometimes eliminate unnecessary synchronizations. Combined with a simple "no escape" flag, this could also --8323584-2133373664-1304895703=:3911--