harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Date Wed, 25 Oct 2006 12:51:54 GMT
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 <ivan.volosyuk@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 <xiaofeng.li@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 <ivan.volosyuk@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
>

Mime
View raw message