harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Fri, 18 Aug 2006 17:03:36 GMT
On 8/18/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 8/18/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> >
> > One suggestion that I would made is to never write anywhere in GC or
> > JIT or any other VM module any code which would access fs14 directly,
> > using the TLS.getAddressByOffset(offset_in_TLS) vmmagic call or
> > whatever.
>
>
> I think you are right to emphasize the problem that we should not provide an
> access to the structure stored in fs[14] by itself.
> By writing
> TLS.getAddressByOffset(offset_in_TLS)
> I mean that there is some safe place in TLS struct we can access to. The
> example of such struct was in the first letter from Weldon:
> struct jvm_thread_block {
>    <<private vm data>>
>    int user_data[100];  //<-  offset_in_TLS is started from this point
> }
>
>
> 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
> > ?
>
>
> Yes, my vision that this is the  best way: allow to TLS clients to reserve
> slots in TLS in runtime.
> The only disadvantage is that Weldon's way to extend the TLS struct could be
> implemented very easy. The reservation of TLS slots in runtime won't allow
> to a writer of a helper to use constants in code. So it can slow down the
> development becase it requires more features to support on vmmagic level
> from the very beggining.

I understand it is extra work for JIT developer.  It is really your
decision if you can do this extra work.  And when you can do it.

> Would we agree to use Weldon's way first time and to move to the dynamic
> allocation of TLS slots in the future if needed?

Either approach is OK with me.

>
>
> > 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 :)
>
>
>
> Note2: TLS access is not the only place needed by the JIT for inlining
> > threading calls. Another example would be monitorenter & exit calls,
> > see other functions in thread_helpers.cpp of the Harmony-1125. May be
> > they will look more simpler if rewritten with vmmagic?
>
>
> Is the "fast path" for mon-enter is just to do locked compare and exchange
> operation? AFAIK vmmagic has an API to lock, so the support of TLS and calls
> is enough.

Yes, there is facility in vmmagic for atomic read-modify-write.  I
don't need it for MMTk just yet.  Thus I am not pushing on Jitrino.JET
to finish this work just yet.

It would be worth while to try to prototype monenter and monexit code
using vmmagic.  As far as I remember the common case for DRLVM
monenter is a compareandswap of 4 bytes of memory with and int that
holds thread ID.  The CAS fails if the contents of memory are not
zero.  If this is the case, it should be straight forward to use
vmmagic for monenter.  Thoughts?
>
>
> --
> Mikhail Fursov
>
>


-- 
Weldon Washburn
Intel Middleware Products 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


Mime
View raw message