Yes, this can be an optimization. I am not very sure if we can get obvious performance improvement with this. I am usually conservative with interface change. :-) Since neither Windows nor Linux provides this kind of native support, I am guessing they have their rationality.
We probably want to delay this optimization in TM until we have evidance for it, since what Mikhail wants is just to inline GC tls data access easily. Thanks, xiaofeng 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
