Mikhail, we want to seperate the GC module from TM so that only limited VM APIs are accessed from GC. That means, we want a simpler API to get GC thread info than accessing GC TLS data individually. Using info.get_tls_current_free() to access a field info of GC TLS data looks like not very elegant. Can't we deference once to get the field info from (GC TLS data pointer + offset_of_free_in_GC_tls)? This can keep the GC_Thread_Info of GC (or Allocator structure in GCv5). I think this is important for modularity. Thanks.
Thanks, xiaofeng On 10/24/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
All, I propose changing the method GC accesses TLS data. The main problem is that GC stores it's data in VM_thread struct that has no constant offset from the TLS base (e.g. from the address stored in fs[14] ). The structure we have today is: fs[14] keeps pointer to HyThread* HyThread keeps pointer to VM_thread VM_thread struct keeps GC information inlined: Byte _gc_private_information[GC_BYTES_IN_THREAD_LOCAL]; The proposal is to keep the GC information in HyThread inlined. Doing this we will have static offsets for GC data in TLS and avoid extra memory access for every alloc request. I tried to refactor gc_cc to use TM directly and the patch is in JIRA: http://issues.apache.org/jira/browse/HARMONY-1949 GC gurus, please review the patch for gc_cc Could we do the same for gcv5 and gcv4? After it's ready we can remove the third parameter from extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size, Allocation_Handle type, void *thread_pointer); method and inline GC allocation fast-path in JIT -- Mikhail Fursov
