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 02:01:54 GMT
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.


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

View raw message