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 <[EMAIL PROTECTED]> wrote:
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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
