From owner-freebsd-java Thu Mar 21 15:43:35 2002 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by hub.freebsd.org (Postfix) with ESMTP id CDBCD37B420 for ; Thu, 21 Mar 2002 15:43:20 -0800 (PST) Received: from billh by gnuppy.monkey.org with local (Exim 3.35 #1 (Debian)) id 16oCD7-0000QR-00; Thu, 21 Mar 2002 15:43:09 -0800 Date: Thu, 21 Mar 2002 15:43:09 -0800 To: Nate Williams Cc: Greg Lewis , java@FreeBSD.ORG Subject: Re: Mozilla core... & HotSpot update Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15514.3199.968025.626479@caddis.yogotech.com> User-Agent: Mutt/1.3.27i From: Bill Huey 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 On Thu, Mar 21, 2002 at 09:38:23AM -0700, Nate Williams wrote: > 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. > > Nate 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. 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. There you still have to protect a common resouce via a mutex of some sort. That's just basic to threading systems. And having common coarse grained lock would add a lot contention, so it would make sense to push that down to each subsystem. No work last night, I was possibly slightly poisoned by being around the reminience of burning plastics from a burnt car. You know, cynanide and all... I'm fine today. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message