Excelent point. Performance data is quite needed to make this change. But how we can obtain it without a prototype? What about making experimental patch to measure performance of this optimization? We can safely drop it if it doesn't make sense. -- Ivan
On 10/25/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
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
