On 8/18/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 8/18/06, Andrey Chernyshev <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
