From owner-freebsd-java Thu Mar 21 15:46:39 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 EBBA437B421 for ; Thu, 21 Mar 2002 15:46:17 -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 QAA18717; Thu, 21 Mar 2002 16:45:49 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g2LNjjQ10606; Thu, 21 Mar 2002 16:45: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: <15514.28841.407418.877991@caddis.yogotech.com> Date: Thu, 21 Mar 2002 16:45:45 -0700 To: Bill Huey Cc: Nate Williams , Greg Lewis , java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update In-Reply-To: <20020321234309.GA1607@gnuppy.monkey.org> References: <200203201509.PAA29782@sorley.cogsci.ed.ac.uk> <20020320201858.GA3125@gnuppy.monkey.org> <15512.61557.26582.852492@caddis.yogotech.com> <20020320233301.GA4011@gnuppy.monkey.org> <15513.7648.287464.414451@caddis.yogotech.com> <20020321000145.GA4319@gnuppy.monkey.org> <20020321142512.A65790@misty.eyesbeyond.com> <20020321063724.GA6657@gnuppy.monkey.org> <15514.3199.968025.626479@caddis.yogotech.com> <20020321234309.GA1607@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 > > Actually, mutexes almost always slow things down, so I doubt it's an > > optimization issue. It's probably to ensure a method is completely > > JIT'd before they allow execution of the new version. > > It's almost certainly a mixture of things including properly > synchronizing the JIT process. But in the case JITing, you have > a common dictionary that you have to protect so that the possiblity > of multipule threading compiling block into it can proceed in > a non-racy manner. They allow multiple JIT compile threads? That seems like a problem waiting for a solution. Are you *sure*? I can't exactly say if this is the case just > yet, but it would make sense if all the executing threads where > able to JIT blocks and/or manage a pool of thread doing the > compiling and inserting the results into a common data structure. Actually, it wouldn't, since a JIT like HotSpot JITS on-the-fly as code is found to be useful in compiling. Traditional JITs compile *everything* at the beginning, so there aren't as many races and such, since no-code is executed until the compilation is complete. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message