Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 35805 invoked from network); 26 Oct 2006 04:17:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Oct 2006 04:17:18 -0000 Received: (qmail 96612 invoked by uid 500); 25 Oct 2006 06:21:24 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 96565 invoked by uid 500); 25 Oct 2006 06:21:23 -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 96556 invoked by uid 99); 25 Oct 2006 06:21:23 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2006 23:21:23 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of mike.fursov@gmail.com designates 64.233.182.190 as permitted sender) Received: from [64.233.182.190] (HELO nf-out-0910.google.com) (64.233.182.190) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2006 23:21:12 -0700 Received: by nf-out-0910.google.com with SMTP id d4so437154nfe for ; Tue, 24 Oct 2006 23:20:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GS/6bQijVpGC2h+KWhFKm+0hkz/40Xgk+yQ9o2Af51KGva+Se6jPAdxHZIVbJ+Uxo5XPGtX8xKvEF1t2ZMP/0zmf5Ei97T/Oa8UwVxIXoj0N9CoqGFjCXIZbZg5ycVmuqNd/+/2Vyb/CeIS0zd7dL5M3JQIKsB2kTPKDuyPHw50= Received: by 10.78.166.7 with SMTP id o7mr288280hue; Tue, 24 Oct 2006 23:20:50 -0700 (PDT) Received: by 10.78.180.1 with HTTP; Tue, 24 Oct 2006 23:20:50 -0700 (PDT) Message-ID: Date: Wed, 25 Oct 2006 13:20:50 +0700 From: "Mikhail Fursov" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code In-Reply-To: <9623c9a50610242313v21401f9bq8730e212e5b62261@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15824_16357489.1161757250150" References: <9623c9a50610241901j5c66fe85s8adc0c8de95ff233@mail.gmail.com> <9623c9a50610242313v21401f9bq8730e212e5b62261@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_15824_16357489.1161757250150 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/25/06, Xiao-Feng Li wrote: > > Mikhail, I guess there is miscommunication. I didn't suggest to put GC > TLS data to VM_Thread, I think it should have its own TLS key. My > suggestion is to use single key for GC TLS data block pointer, then > use an additional dereference for a GC TLS data field. Xiao-Feng, I completely agree that allocation of continues memory space to map a struct to it instead of allocation of each field separately is more convenient for TM clients. The problem is that we do not have such an interface today. It's not a hard task to add such an interface to TM we have and implement it. Let's get TM gurus approval or comments on it. TM gurus, are there any design problems to allocate N continues slots in TLS storage at once? -- Mikhail Fursov ------=_Part_15824_16357489.1161757250150--