You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Fursov <mi...@gmail.com> on 2006/10/24 14:28:39 UTC
[drlvm][gc] TLS access from GC: a proposal to refactor the code
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 pointer to VM_thread
VM_thread struct keeps GC information inlined: Byte
_gc_private_information[GC_BYTES_IN_THREAD_LOCAL];
The proposal is to keep the GC information in HyThread inlined. Doing this
we will have static offsets for GC data in TLS and avoid extra memory access
for every alloc request.
I tried to refactor gc_cc to use TM directly and the patch is in JIRA:
http://issues.apache.org/jira/browse/HARMONY-1949
GC gurus, please review the patch for gc_cc
Could we do the same for gcv5 and gcv4?
After it's ready we can remove the third parameter from
extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size,
Allocation_Handle type,
void *thread_pointer);
method and inline GC allocation fast-path in JIT
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Ivan Volosyuk <iv...@gmail.com>.
+1
--
Ivan
Intel Enterprise Solutions Software Division
On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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 <mi...@gmail.com> wrote:
> > Xiao-Feng,
> >
> >
> > On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
> >
> >
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
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,
Allocation_Handle type, void *thread_pointer);
On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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.
>
> --
> Mikhail Fursov
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/25/06, Nikolay Kuznetsov <ni...@gmail.com> 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.
>
The patch 1949 emulates this behaviour without the support. The only
negative impact is the syntax. Instead of mapping the whole structure to
memory we have to operate with fields by offsets:
void set_tls_current_free(unsigned char* v) {*(unsigned char**)(tls_base
+ tls_offset_current) = v;}
void set_tls_current_cleaned(unsigned char* v) {*(unsigned
char**)(tls_base + tls_offset_clean) = v;}
void set_tls_current_ceiling(unsigned char* v) {*(unsigned
char**)(tls_base + tls_offset_ceiling) = v;}
As for your request for additional performance data: I do not have any
today. But I put this in my TODO list.
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <ni...@gmail.com> 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 <iv...@gmail.com> 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 <xi...@gmail.com> wrote:
> > > On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > > > On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Nikolay Kuznetsov <ni...@gmail.com>.
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 <iv...@gmail.com> 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 <xi...@gmail.com> wrote:
> > On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > > On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
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 <xi...@gmail.com> wrote:
>
> No problem, I can modify GCv5 for this. Thanks, -xiaofeng
>
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
No problem, I can modify GCv5 for this. Thanks, -xiaofeng
On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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.
> Another part of the question is interface.
> Xiao-Feng, could you make GCv5 to access TLS with TM but not VM? In other
> words make the third parameter of the method unused, so I can remove it at
> all:
> extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size,
> Allocation_Handle type, void *thread_pointer);
>
> ?
>
> --
> Mikhail Fursov
>
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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.
Another part of the question is interface.
Xiao-Feng, could you make GCv5 to access TLS with TM but not VM? In other
words make the third parameter of the method unused, so I can remove it at
all:
extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size,
Allocation_Handle type, void *thread_pointer);
?
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Ivan Volosyuk <iv...@gmail.com>.
Sure, the limitation exists. We can broke it even with older
interfaces, but now we have quite pessimistic approach and don't use
even a quarter of it. I do not suggest to keep everything there, just
the most performance critical fields. With that interface we have much
flexibility there and can do fine tuning for better performance.
--
Ivan
On 10/25/06, Evgueni Brevnov <ev...@gmail.com> 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 arbitrary size TLS which
> seems to be required in case we want to allocate memory for keeping
> whole structures in it.
>
> Thanks
> Evgueni
>
> On 10/25/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > Well, AFAIU this part of Mikhail's proposal is not mandatory for all
> > GCs. You can use original interface functions for GCv5: malloc GC TLS
> > structure and install only one pointer into TLS.
> >
> > The only thing we need to change is to make GC to access and allocate
> > its data by itself (for greater modularity).
> > --
> > Ivan
> >
> > On 10/25/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > 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 <iv...@gmail.com> 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
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
Ivan, agree. The multi-slot TLS allocation is only a superset that
keeps backward compatibility.
Btw, I was familiar with Linux TLS implementation (in Linuxthreads),
it was arranged into multiple-levels (like the inode blocks for a file
in filesystem). So the supported number of TLS keys can be large. I
haven't checked current TLS implementation (in NPTL), but I guess it
has no problem to support our demands. (Well, we can't guarantee how
native code in an application would use TLS, to be conservative is
safe anyway.)
Thanks,
xiaofeng
On 10/25/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> On 10/25/06, Salikh Zakirov <Sa...@intel.com> 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 for
> > > doing so. It can be a problem to implement arbitrary size TLS which
> > > seems to be required in case we want to allocate memory for keeping
> > > whole structures in it.
> >
> > Currently TM provides this service by using just *1* OS-level TLS slot.
> > The keys are allocated from a hythread_t structure:
> >
> > thread/src/thread_private.h
> > 166 typedef struct HyThread {
> >
> > 312 /**
> > 313 * Array representing thread local storage
> > 314 */
> > 315 void *thread_local_storage[10];
> >
> >
> > So, it seems reasonable to use 3 of them for GC, 1 for VM and 1 for JIT.
>
> GCv5 may have different demand for the TLS data, but IMHO some of
> performance critical data can be made directly available in TLS and
> some less signicant may be accessed indirectly.
>
> --
> Ivan
> Intel Enterprise Solutions Software Division
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 10/25/06, Salikh Zakirov <Sa...@intel.com> 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 for
> > doing so. It can be a problem to implement arbitrary size TLS which
> > seems to be required in case we want to allocate memory for keeping
> > whole structures in it.
>
> Currently TM provides this service by using just *1* OS-level TLS slot.
> The keys are allocated from a hythread_t structure:
>
> thread/src/thread_private.h
> 166 typedef struct HyThread {
>
> 312 /**
> 313 * Array representing thread local storage
> 314 */
> 315 void *thread_local_storage[10];
>
>
> So, it seems reasonable to use 3 of them for GC, 1 for VM and 1 for JIT.
GCv5 may have different demand for the TLS data, but IMHO some of
performance critical data can be made directly available in TLS and
some less signicant may be accessed indirectly.
--
Ivan
Intel Enterprise Solutions Software Division
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Salikh Zakirov <Sa...@Intel.com>.
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 arbitrary size TLS which
> seems to be required in case we want to allocate memory for keeping
> whole structures in it.
Currently TM provides this service by using just *1* OS-level TLS slot.
The keys are allocated from a hythread_t structure:
thread/src/thread_private.h
166 typedef struct HyThread {
312 /**
313 * Array representing thread local storage
314 */
315 void *thread_local_storage[10];
So, it seems reasonable to use 3 of them for GC, 1 for VM and 1 for JIT.
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Evgueni Brevnov <ev...@gmail.com>.
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 arbitrary size TLS which
seems to be required in case we want to allocate memory for keeping
whole structures in it.
Thanks
Evgueni
On 10/25/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> Well, AFAIU this part of Mikhail's proposal is not mandatory for all
> GCs. You can use original interface functions for GCv5: malloc GC TLS
> structure and install only one pointer into TLS.
>
> The only thing we need to change is to make GC to access and allocate
> its data by itself (for greater modularity).
> --
> Ivan
>
> On 10/25/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> > 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 <iv...@gmail.com> 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
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Ivan Volosyuk <iv...@gmail.com>.
Well, AFAIU this part of Mikhail's proposal is not mandatory for all
GCs. You can use original interface functions for GCv5: malloc GC TLS
structure and install only one pointer into TLS.
The only thing we need to change is to make GC to access and allocate
its data by itself (for greater modularity).
--
Ivan
On 10/25/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> 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 <iv...@gmail.com> 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
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <iv...@gmail.com> 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 <xi...@gmail.com> wrote:
> > On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > > On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <xi...@gmail.com> wrote:
> On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
>
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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.
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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 = thread_get_tls_data( gc_tls_key);
> > free = *(gc_tls_data_ptr + offset_of_free_in_gc_tls);
> >
> > Can't this work? Sounds like I missed something?
> >
> Xiao-Feng,
> Yes we talking about the same functionality.
> The problem with your example is that TM has no such an API :)
>
> The only method we have is 'hythread_tls_alloc (hythread_tls_key_t*
> handle);' and it allocates sizeof(void*) bytes in TLS struct.
> And the method we need is:
> 'hythread_tls_alloc (hythread_tls_key_t* handle, size_t bytes);' or
> 'hythread_tls_alloc (hythread_tls_key_t* handle, size_t numSlots);' where
> numSlots for GC is ~ sizeof(GC_Thread_Info)/sizeof (void*)
>
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)?
Thanks,
xiaofeng
> --
> Mikhail Fursov
>
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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 = thread_get_tls_data( gc_tls_key);
> free = *(gc_tls_data_ptr + offset_of_free_in_gc_tls);
>
> Can't this work? Sounds like I missed something?
>
Xiao-Feng,
Yes we talking about the same functionality.
The problem with your example is that TM has no such an API :)
The only method we have is 'hythread_tls_alloc (hythread_tls_key_t*
handle);' and it allocates sizeof(void*) bytes in TLS struct.
And the method we need is:
'hythread_tls_alloc (hythread_tls_key_t* handle, size_t bytes);' or
'hythread_tls_alloc (hythread_tls_key_t* handle, size_t numSlots);' where
numSlots for GC is ~ sizeof(GC_Thread_Info)/sizeof (void*)
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 = thread_get_tls_data( gc_tls_key);
free = *(gc_tls_data_ptr + offset_of_free_in_gc_tls);
Can't this work? Sounds like I missed something?
Thanks,
xiaofeng
On 10/25/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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.
>
>
> Xiao-Feng,
> I completely agree that allocation of continues memory space to map a
> struct to it instead of allocation of each field separately is more
> convenient for TM clients.
> The problem is that we do not have such an interface today. It's not a hard
> task to add such an interface to TM we have and implement it. Let's get TM
> gurus approval or comments on it.
>
> TM gurus, are there any design problems to allocate N continues slots in TLS
> storage at once?
>
>
> --
> Mikhail Fursov
>
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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.
Xiao-Feng,
I completely agree that allocation of continues memory space to map a
struct to it instead of allocation of each field separately is more
convenient for TM clients.
The problem is that we do not have such an interface today. It's not a hard
task to add such an interface to TM we have and implement it. Let's get TM
gurus approval or comments on it.
TM gurus, are there any design problems to allocate N continues slots in TLS
storage at once?
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <mi...@gmail.com> wrote:
> Xiao-Feng,
>
>
> On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
>
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
Xiao-Feng,
On 10/25/06, Xiao-Feng Li <xi...@gmail.com> 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
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Xiao-Feng Li <xi...@gmail.com>.
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)? This
can keep the GC_Thread_Info of GC (or Allocator structure in GCv5). I
think this is important for modularity. Thanks.
Thanks,
xiaofeng
On 10/24/06, Mikhail Fursov <mi...@gmail.com> wrote:
> 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 pointer to VM_thread
> VM_thread struct keeps GC information inlined: Byte
> _gc_private_information[GC_BYTES_IN_THREAD_LOCAL];
>
> The proposal is to keep the GC information in HyThread inlined. Doing this
> we will have static offsets for GC data in TLS and avoid extra memory access
> for every alloc request.
> I tried to refactor gc_cc to use TM directly and the patch is in JIRA:
> http://issues.apache.org/jira/browse/HARMONY-1949
> GC gurus, please review the patch for gc_cc
>
> Could we do the same for gcv5 and gcv4?
> After it's ready we can remove the third parameter from
>
> extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size,
> Allocation_Handle type,
> void *thread_pointer);
>
> method and inline GC allocation fast-path in JIT
>
>
> --
> Mikhail Fursov
>
>
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/24/06, Evgueni Brevnov <ev...@gmail.com> 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
Before you move GC info into HyThread you do not have persistent and equal
for all threads offset from TLS base (fs[14]) to thread-local fields of GC.
That is you can't inline object allocation into JIT with the current design.
--
Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Posted by Evgueni Brevnov <ev...@gmail.com>.
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 <mi...@gmail.com> wrote:
> 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 pointer to VM_thread
> VM_thread struct keeps GC information inlined: Byte
> _gc_private_information[GC_BYTES_IN_THREAD_LOCAL];
>
> The proposal is to keep the GC information in HyThread inlined. Doing this
> we will have static offsets for GC data in TLS and avoid extra memory access
> for every alloc request.
> I tried to refactor gc_cc to use TM directly and the patch is in JIRA:
> http://issues.apache.org/jira/browse/HARMONY-1949
> GC gurus, please review the patch for gc_cc
>
> Could we do the same for gcv5 and gcv4?
> After it's ready we can remove the third parameter from
>
> extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size,
> Allocation_Handle type,
> void *thread_pointer);
>
> method and inline GC allocation fast-path in JIT
>
>
> --
> Mikhail Fursov
>
>