+1 -- Ivan Intel Enterprise Solutions Software Division
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> wrote: > 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 > >
