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,
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, Mikhail, how about this:
In GC thread init:
gc_tls_data_ptr = malloc_gc_tls_data(sizeof(GC_Thread_Info) );
gc_tls_key = thread_create_tls_key();
thread_set_tls_data( gc_tls_key, gc_tls_data_ptr);
To fast alloc:
gc_tls_data_ptr =
On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, Mikhail, how about this:
In GC thread init:
gc_tls_data_ptr = malloc_gc_tls_data(sizeof(GC_Thread_Info) );
gc_tls_key = thread_create_tls_key();
thread_set_tls_data( gc_tls_key,
Xiao-Feng,
Even if you do not need to have constant offsets, it's better to use TM
directly to allocate TLS slots.
In this case we can remove extra code from VM: the computation of the third
parameter in the next method:
extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size,
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
+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
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
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
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
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.
Ok, I understand it and agree. Today I'm going do the measurements/changes
only for gc_cc.
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
No problem, I can modify GCv5 for this. Thanks, -xiaofeng
On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
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
Thank you.
Just tell me when GCv5 is ready and I'll clean VM part. + This is not the
first priority task today.
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
No problem, I can modify GCv5 for this. Thanks, -xiaofeng
--
Mikhail Fursov
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
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
Evgueni Brevnov wrote:
Hi Guys,
Just one little note from me... AFAIK Window and Linux have limitation
on the number of TLS slots which can be allocated for any particular
thread. I believe here is strong (probably performance) reasons for
doing so. It can be a problem to implement
On 10/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Evgueni Brevnov wrote:
Hi Guys,
Just one little note from me... AFAIK Window and Linux have limitation
on the number of TLS slots which can be allocated for any particular
thread. I believe here is strong (probably performance) reasons
All,
I propose changing the method GC accesses TLS data.
The main problem is that GC stores it's data in VM_thread struct that has no
constant offset from the TLS base (e.g. from the address stored in fs[14]
).
The structure we have today is:
fs[14] keeps pointer to HyThread*
HyThread keeps
Mikhail,
I was under impression that both VM_thread and HyThread structures are
stored into TLS. Am I missing something?
Thanks
Evgueni
On 10/24/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
All,
I propose changing the method GC accesses TLS data.
The main problem is that GC stores it's data in
On 10/24/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Mikhail,
I was under impression that both VM_thread and HyThread structures are
stored into TLS. Am I missing something?
Evgueni,
GC info is stored in VM_thread.
VM_thread is stored in HyThread as a pointer. HyThread is stored in TLS
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
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
21 matches
Mail list logo
