From harmony-dev-return-18605-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu Nov 09 17:51:59 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 50502 invoked from network); 9 Nov 2006 17:51:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Nov 2006 17:51:59 -0000 Received: (qmail 27590 invoked by uid 500); 9 Nov 2006 17:52:04 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 26961 invoked by uid 500); 9 Nov 2006 17:52:03 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 26952 invoked by uid 99); 9 Nov 2006 17:52:03 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Nov 2006 09:52:03 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [66.11.181.4] (HELO griffin.griffaction.ca) (66.11.181.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Nov 2006 09:51:50 -0800 Received: from [127.0.0.1] (helo=[127.0.0.1]) by griffin.griffaction.ca with esmtp (Exim 4.50 #1 (Debian)) id 1GiE3l-0000wd-V3 for ; Thu, 09 Nov 2006 12:51:30 -0500 Message-ID: <4553698F.5060900@sablevm.org> Date: Thu, 09 Nov 2006 12:46:55 -0500 From: Etienne Gagnon User-Agent: Debian Thunderbird 1.0.2 (X11/20060927) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Class unloading support - tested one approach References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com> <5836de490611080250l6dfbd38cw8778f7a055373d82@mail.gmail.com> <4551B83D.9020706@anu.edu.au> <4551CBDB.90004@anu.edu.au> <12385bbd0611081501q6411fb07pa67f96ffdfa5028a@mail.gmail.com> <1163028107.5241.1.camel@localhost> <4552B9F2.8060809@sablevm.org> <4552D103.80600@anu.edu.au> <45534C19.1010303@sablevm.org> <12385bbd0611090928k7b8b24f3o2c66b9b6e1ee18fb@mail.gmail.com> In-Reply-To: <12385bbd0611090928k7b8b24f3o2c66b9b6e1ee18fb@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB4641B012DECE597B80E2B73" X-Virus-Checked: Checked by ClamAV on apache.org --------------enigB4641B012DECE597B80E2B73 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ivan Volosyuk wrote: > We will get rid of false sharing. That's true. But it still be quite > expensive to write those '1' values, because of ping-ponging of the > cache line between processors. I see only one solution to this: use > separate mark bits in vtable per GC thread which should reside in > different cache lines and different from that word containing gcmap > pointer. Thinking about it... Doesn't the "object vtable" suffer from the same problem, anyway? It's probably worse, as it will be quite unfeasible to try to locate them in the "right" cache lines! Yep, another point against object-vtables... Etienne -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ --------------enigB4641B012DECE597B80E2B73 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFU2mPjyrJi4rH84gRAgGxAJ9w654cyri3HWA15WyGcslrxeST7gCfR6S0 +XcY9vkO7YSUjuQzYrESH/k= =bZzc -----END PGP SIGNATURE----- --------------enigB4641B012DECE597B80E2B73--