harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Sun, 20 Aug 2006 07:53:05 GMT
On the 0x1C9 day of Apache Harmony Mikhail Fursov wrote:
> Would id be possible to add the Java TLS API into VMThreadManager like:
> > long  tlsAlloc(); // returns a key for new local storage entry
> > tlsSet(long key, long dataAddr); // stores a pointer to memory addr
> > for the given key
> > long tlsGet(long key); // returns memory addr for the given key
> > void tlsFree(long key); //  releases the given entry in TLS
> > ?

> > The benefit of that approach could be that fs14 knowledge is localized
> > within the threading module and is not exposed to any other VM
> > component like GC or JIT.
> >
> Once JIT is responsible to generate TLS access magic, that is platform
> dependent by itself, I do not understand how you can hide this knowlegde
> from JIT. If  vmmagic uses abstract TLS access operation like described
> above but not FS[14] it's impossible to teach JIT to generate FS[14] access
> using vmmagic :)

As far as I understand, Andrey proposes to have a number of low-level
JIT vmmagics (like .. fs[14], etc.) and write high-level accessors
like tlsSet, tlsGet using these magics. Andrey says, it helps to
localize low-level vmmagic usage in one place. JIT<->threading tight
dependence persists here in form of low-level accessors.

But.. I see one major disadvantage here. You should write your tlsSet
and tlsGet in Java and in a system-dependent way. This is what I think
we should avoid.

The alternative method is to allow tlsSet and tlsGet be vmmagic
themselves. Now system-dependent code is hidden within a JIT. The
JIT<->Threading is probably more tight here because JIT takes more
code as vmmagic. Another obvious disadvantage is that JIT has to do
more here. 

Hm, but I like this way more. The idea is quite elegant: hide
system-dependent implementation details in high-level magics and let
JIT optimize them out. Provide a slow implementation in API in case
JIT does not recognize the magic. I Hope, there will be not a lot of
large high-level system-dependente vmmagics around. In this case this
approach is ideal for me.

Egor Pasko, Intel Managed Runtime Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message