We obviously do need to provide an access from the Java code to internal VM structures such as VM thread block. It will be good if we can utilize vmmagic for accessing the registers, and in particular accessing win32 "fast TLS" at fs14.
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 fs14 usage could be implementation details of the TLS API which is provided by the threading module of the VM. In DRLVM, this threading module is partially described by the Java class called java.lang.VMThreadManager. 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 ? It's implementation in VMThreadManager may internally use vmmagic and fs14 for implementing fast TLS access model specifically for win32 and do some other tricks with GS or ESP on Linux. In this case the allocated keys could be just some offsets in the data structure (e.g. storage iteslf) located at fs14. 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. Note1: In the thread manager recently suggested at Harmony 1125, the problem of fast access to TLS from the components other than thread manager itself to some extent was solved by providing VM helper called "get_tls_helper" - it represents the code to be inlined by the JIT (see drlvm/vm/thread/src/thread_helpers.cpp) whenever TLS read is needed. The difference is only in the language used for that helper - in Harmony 1125 this was JIT encoder API, but it can probably be written in Java with help of 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? Thanks, Andrey, On 8/18/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 8/18/06, Robin Garner <[EMAIL PROTECTED]> wrote: > > Object org.vmmagic.utility.accessVmStructure(<identifier>) This is a good idea to keep in mind. We can introduce it when needed. At the moment for service fast-path inlining, I guess specific JIT intrisics are enough. > or even better, declare object instances with a pragma annotation > > @IntrinsicDataStructure("name") > MutatorContext myMutatorContext; > > and the compiler generates code to fetch the address. Has better type > safety, potentially. hmm, I am not sure how this syntactic suger can have better type safety. Thanks, xiaofeng --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrey Chernyshev 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]