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 <mike.fursov@gmail.com> 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
>
>
|