Xiao-Feng,
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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
