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 06:13:27 GMT
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.

Thanks,
xiaofeng

On 10/25/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> Xiao-Feng,
>
>
> On 10/25/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > 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)?
>
>
> The current hythread API we have allows to allocate keys for void* sized
> values only.
> Let's ask TM developers why can't we allocate N*(void*) sized values with a
> single key?
>
> The situation we have is rather simple: VM_thread does not allow you to have
> static offsets (so your helper could not be efficiently inlined) and to
> access to a data in VM_thread you have to perform +1 memory access in
> comparison with access to HyThread fields.
>
>
> This
> > can keep the GC_Thread_Info of GC (or Allocator structure in GCv5). I
> > think this is important for modularity. Thanks.
> >
>
> Here we have different vision what modularity is. Thread Manager is
> responsible to work with threads, so I do not understand why VM should
> delegate all of the API of TM that is needed by different components? In
> this case VM must do it for every component, not only for TM, isn't it?
>
> The same is with VM_thread: the way it keeps gc_private_data is a hack that
> brokes the design. What if GC needs more TLS slots than available in
> VM_thread? What if a component XYZ needs TLS data? Will we add it to
> VM_thread xyz_private_data[N] field?
>
>
>
>
> --
> Mikhail Fursov
>
>

Mime
View raw message