Hello All, in general we do not have any objections to implement such functionality, but as far as I understand this will be quite unique TM feature (no other threading library have this, or give me a link) which is intended to improve performance. And if we going to extend TM interface for this, I would like to have any performance data beforehand, do we any data?
Thank you. Nik. On 10/25/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
Xiao-Feng, I think there should be no problem to get this to work. But, I also agree with Mikhail that it could be benefitial to have data directly available in TLS without additional pointer dereference. If we will have corresponding interface function to allocate more then one void pointer at once in TLS it can be used as optimization. -- Ivan On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > On 10/25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > > > Why do we need multiple slots? Can't we use just one slot, which > > > stores a pointer to a user data structure (the GC_Thread_Info in this > > > case)? > > > > > > > Yes you can store a pointer. But in this case you can't tell that you have > > constant offset from fs[14] to your data for all threads. So you can't > > inline your helper in JIT. > > Why? As long as we keep the offset_of_free to the pointer be constant > and known to JIT helper, we only need an additional dereference to get > the "free" value. > > We have two constant offsets, one is the pointer (to gc_tls_data) > offset in fs[14], the other is the "free" offset in gc_tls_data. > > Thanks, > xiaofeng > > -- > > Mikhail Fursov
