harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Date Wed, 25 Oct 2006 04:58:02 GMT

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.

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message