harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Date Wed, 25 Oct 2006 07:43:47 GMT
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 <mike.fursov@gmail.com> wrote:
> On 10/25/06, Xiao-Feng Li <xiaofeng.li@gmail.com> 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
>
>

Mime
View raw message