Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 89174 invoked from network); 26 Oct 2006 06:57:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Oct 2006 06:57:36 -0000 Received: (qmail 16530 invoked by uid 500); 25 Oct 2006 07:44:21 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 16490 invoked by uid 500); 25 Oct 2006 07:44:21 -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 16481 invoked by uid 99); 25 Oct 2006 07:44:20 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 00:44:20 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com designates 64.233.182.187 as permitted sender) Received: from [64.233.182.187] (HELO nf-out-0910.google.com) (64.233.182.187) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 00:44:09 -0700 Received: by nf-out-0910.google.com with SMTP id m18so497460nfc for ; Wed, 25 Oct 2006 00:43:47 -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:content-transfer-encoding:content-disposition:references; b=MNT2ryBEbA5C8NW20aYKRuu9hSH+2lKbxbJu83tStSWJDvgH00LSMqu2PXY1LPg6/Qc4MxAhrig30vS6USOVhNrWsAJbtA34bOoGrH3gk1BR7Xx5yI6vNaeANEdBWr/8U8hPOWDMJC2sQQdyfexUnJQF0vv8XR20iPPGaGnOeHg= Received: by 10.78.94.37 with SMTP id r37mr418885hub; Wed, 25 Oct 2006 00:43:47 -0700 (PDT) Received: by 10.78.154.18 with HTTP; Wed, 25 Oct 2006 00:43:47 -0700 (PDT) Message-ID: <9623c9a50610250043t5f79502dqab09b92d42b2f86f@mail.gmail.com> Date: Wed, 25 Oct 2006 15:43:47 +0800 From: "Xiao-Feng Li" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9623c9a50610241901j5c66fe85s8adc0c8de95ff233@mail.gmail.com> <9623c9a50610242313v21401f9bq8730e212e5b62261@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Hi, Mikhail, how about this: In GC thread init: gc_tls_data_ptr = malloc_gc_tls_data(sizeof(GC_Thread_Info) ); gc_tls_key = thread_create_tls_key(); thread_set_tls_data( gc_tls_key, gc_tls_data_ptr); To fast alloc: gc_tls_data_ptr = thread_get_tls_data( gc_tls_key); free = *(gc_tls_data_ptr + offset_of_free_in_gc_tls); Can't this work? Sounds like I missed something? Thanks, xiaofeng On 10/25/06, Mikhail Fursov wrote: > 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 > >