From owner-freebsd-java Thu Mar 28 21:26:55 2002 Delivered-To: freebsd-java@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 24BDC37B404 for ; Thu, 28 Mar 2002 21:26:51 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA04287; Thu, 28 Mar 2002 22:26:46 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g2T5QjK22330; Thu, 28 Mar 2002 22:26:45 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.64276.424513.449922@caddis.yogotech.com> Date: Thu, 28 Mar 2002 22:26:44 -0700 To: Bill Huey Cc: Anthony Green , Brian Behlendorf , freebsd-java@FreeBSD.ORG Subject: Re: [press@apache.org: PRESS RELEASE: ASF Reaches Agreement with Sun to Allow Open Source Java Implementations] In-Reply-To: <20020329004939.GA1639@gnuppy.monkey.org> References: <20020328002610.GA2023@gnuppy.monkey.org> <20020327221634.M1335-100000@yez.hyperreal.org> <20020328064218.GA2973@gnuppy.monkey.org> <1017330145.2206.84.camel@dhcppc2> <20020329004939.GA1639@gnuppy.monkey.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > The performance of the resulting binaries is good. It's competitive > > with state-of-the-art JIT systems. Meaning... sometimes faster, > > sometimes slower. When it's faster, it can be much faster. For > > instance, certain crypto operations used in SSL can run 10x faster than > > state-of-the-art commercial JITs. > > What about garbage collection speed for short lived objects ? > > That's critical for folks doing a lot of String manipulation and dealing > with the GUI framework generating EventObject-s every where. Actually, GC speed is for short lived objects is not necessarily more important than GC spedd for long lived objects. GC speed in general is important, regardless of the lifetime of the object. However, if you do a good job on short-lived objects, it allows the program to have a smaller working set, and *may* (depending on the algorithm used) allow the GC portion that deals with long-term objects to work faster. This is the basis for many two-tiered GC systems, which have been implemented in all of the JIT's to date. (Including the Sun supplied JIT developed by Borland in the JDK1.1 days). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message