harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Fri, 18 Aug 2006 13:39:59 GMT
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.
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?


> 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.


-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message