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]
