You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/08/16 23:12:37 UTC
[drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Windows uses ia32 segment register fs:14 for fast thread-local storage
access. I think Linux somehow uses the gs segment register. Assuming
we would like to access thread-local memory from vmmagic, below is a
first stab at a design. The intention is to not disrupt existing
vmmagic design and also keep things as clear and type-safe as
possible.
Add the following new classes to vmmagic:
public class SegmentRegister
{ /*intentionally empty*/ }
public final class SegmentRegisterFS extends SegmentRegister
{/*intentionally empty*/ }
public final class SegmentRegisterGS extends SegmentRegister
{/*intentionally empty*/ }
Add a few new methods to vmmagic Address class:
public int loadInt(SegmentRegister segReg);
public long loadLong(SegmentRegsiter segReg);
public void store(int value, SegmentRegister segReg);
public void store(long value, SegmentRegister segReg);
Some sample Java code to see how the above would work in real life:
Address addr = Address.fromInt(0x14);
SegmentRegisterFS segFs = new SegmentRegisterFS();
int tlsPtr = addr.loadInt(segFs);
/*
Thinking about how a "C" jvm like DRLVM is constructed, tlsPtr would
be pointing at a C data struct. Let's assume the following layout for
the C data struct
struct jvm_thread_block {
char * name of thread;
lock_t current_lock_held;
status current_state_of_thread;
blah, blah, blah...
int jit_private_data[16]; //assume this is offset 0x38 from start of
jvm_thread_block
int gc_private_data[16];
blah, blah, blah...
}
*/
/*
The JIT (or GC) would access their thread-local storage area via Java
code as follows
*/
Address addr2 = Address.fromInt(tlsPtr);
Offset ofs = Offset.fromInt(0x38);
//read jit_private_data[0]
int privateData = addr2.loadInt(ofs);
//read jit_private_data[1]
ofs = ofs.plus(0x4);
int privateData = addr2.loadInt(ofs);
---------------- end of code example
Of course, the offset into the JVM data struct is fragile and an edit
of the JVM thread block's header file could cause nasty surprises. On
the other hand, this data struct does not change very often. In
practice, it should not be any greater risk than what C header files
already impose on software engineering.
Comments?
--
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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Weldon Washburn <we...@gmail.com>.
On 8/18/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 8/18/06, Andrey Chernyshev <a....@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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1CB day of Apache Harmony Robin Garner wrote:
> > The alternative method is to allow tlsSet and tlsGet be vmmagic
> > themselves. Now system-dependent code is hidden within a JIT. The
> > JIT<->Threading is probably more tight here because JIT takes more
> > code as vmmagic. Another obvious disadvantage is that JIT has to do
> > more here.
> This is a slightly less general approach than what I suggested here:
>
> > My thoughts on the thread-local storage issue is that it's a more
> > general issue of accessing > shared data structures from the Java
> > side of the fence. So perhaps a method such as
> >
> > Object org.vmmagic.utility.accessVmStructure(<identifier>)
> >
> > where the identifier is some abstract constant that identifies all of
> > the vm-specific data structures one might want to access. Some of
> > them might be slots in the tls area, but others might be elsewhere in
> > the VM.
>
> As long as vmmagic is processed by the JIT after some constant
> propagation takes place it should be quite possible to compile this
> down to an optimal sequence of instructions.
Good idea, thanks! Let's start using it one day :)
> > Hm, but I like this way more. The idea is quite elegant: hide
> > system-dependent implementation details in high-level magics and let
> > JIT optimize them out. Provide a slow implementation in API in case
> > JIT does not recognize the magic. I Hope, there will be not a lot of
> > large high-level system-dependente vmmagics around. In this case this
> > approach is ideal for me.
>
> I agree completely, and heartily recommend using a small number of
> high-level features for these things. When I first started work
> porting MMTk, the interface to the VM had a large number of ad-hoc
> methods for accessing all sorts of things. The present state of
> vmmagic reflects a lot of work and thought by quite a few people on
> how to abstract over the many low-level mechanisms that the VM and
> MMTk used to use to interact.
>
> The idea of providing a slow implementation of higher level vmmagic in
> Java is interesting, but begs the question of which vmmagics you are
> ultimately going to use to implement *them*.
I am proposing to make no extra vmmagic for the slow implementation of
VM-specific accessors. We can make accessors using JNI calls directly
to VM (just like now in DRLVM)
> Finding the right level of abstraction has a payoff on both sides of
> the fence - the java code is cleaner, and there should be less work on
> the JIT side to implement a single general-purpose mechanism.
100% agree :)
--
Egor Pasko, Intel Managed Runtime 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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to
vmmagic
Posted by Robin Garner <ro...@anu.edu.au>.
Egor Pasko wrote:
> On the 0x1C9 day of Apache Harmony Mikhail Fursov wrote:
>
>> 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
>>> ?
>>>
>
> <snip>
>
>
>>> 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 :)
>>
>
> As far as I understand, Andrey proposes to have a number of low-level
> JIT vmmagics (like .. fs[14], etc.) and write high-level accessors
> like tlsSet, tlsGet using these magics. Andrey says, it helps to
> localize low-level vmmagic usage in one place. JIT<->threading tight
> dependence persists here in form of low-level accessors.
>
> But.. I see one major disadvantage here. You should write your tlsSet
> and tlsGet in Java and in a system-dependent way. This is what I think
> we should avoid.
>
> The alternative method is to allow tlsSet and tlsGet be vmmagic
> themselves. Now system-dependent code is hidden within a JIT. The
> JIT<->Threading is probably more tight here because JIT takes more
> code as vmmagic. Another obvious disadvantage is that JIT has to do
> more here.
>
This is a slightly less general approach than what I suggested here:
> My thoughts on the thread-local storage issue is that it's a more
general issue of accessing > shared data structures from the Java side
of the fence. So perhaps a method such as
>
> Object org.vmmagic.utility.accessVmStructure(<identifier>)
where the identifier is some abstract constant that identifies all of
the vm-specific data structures one might want to access. Some of them
might be slots in the tls area, but others might be elsewhere in the VM.
As long as vmmagic is processed by the JIT after some constant
propagation takes place it should be quite possible to compile this down
to an optimal sequence of instructions.
> Hm, but I like this way more. The idea is quite elegant: hide
> system-dependent implementation details in high-level magics and let
> JIT optimize them out. Provide a slow implementation in API in case
> JIT does not recognize the magic. I Hope, there will be not a lot of
> large high-level system-dependente vmmagics around. In this case this
> approach is ideal for me.
>
>
I agree completely, and heartily recommend using a small number of
high-level features for these things. When I first started work porting
MMTk, the interface to the VM had a large number of ad-hoc methods for
accessing all sorts of things. The present state of vmmagic reflects a
lot of work and thought by quite a few people on how to abstract over
the many low-level mechanisms that the VM and MMTk used to use to interact.
The idea of providing a slow implementation of higher level vmmagic in
Java is interesting, but begs the question of which vmmagics you are
ultimately going to use to implement *them*.
Finding the right level of abstraction has a payoff on both sides of the
fence - the java code is cleaner, and there should be less work on the
JIT side to implement a single general-purpose mechanism.
---------------------------------------------------------------------
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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1C9 day of Apache Harmony Mikhail Fursov wrote:
> 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
> > ?
<snip>
> > 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 :)
As far as I understand, Andrey proposes to have a number of low-level
JIT vmmagics (like .. fs[14], etc.) and write high-level accessors
like tlsSet, tlsGet using these magics. Andrey says, it helps to
localize low-level vmmagic usage in one place. JIT<->threading tight
dependence persists here in form of low-level accessors.
But.. I see one major disadvantage here. You should write your tlsSet
and tlsGet in Java and in a system-dependent way. This is what I think
we should avoid.
The alternative method is to allow tlsSet and tlsGet be vmmagic
themselves. Now system-dependent code is hidden within a JIT. The
JIT<->Threading is probably more tight here because JIT takes more
code as vmmagic. Another obvious disadvantage is that JIT has to do
more here.
Hm, but I like this way more. The idea is quite elegant: hide
system-dependent implementation details in high-level magics and let
JIT optimize them out. Provide a slow implementation in API in case
JIT does not recognize the magic. I Hope, there will be not a lot of
large high-level system-dependente vmmagics around. In this case this
approach is ideal for me.
--
Egor Pasko, Intel Managed Runtime 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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Mikhail Fursov <mi...@gmail.com>.
On 8/18/06, Andrey Chernyshev <a....@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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Andrey Chernyshev <a....@gmail.com>.
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 <xi...@gmail.com> wrote:
> On 8/18/06, Robin Garner <ro...@anu.edu.au> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
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
Re: [drlvm][vm,
mmtk] adding thread-local storage functionality to vmmagic
Posted by Robin Garner <ro...@anu.edu.au>.
> On 8/18/06, Robin Garner <ro...@anu.edu.au> 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.
It strikes me that this single intrinsic is extensible and just as easily
implemented as the JIT specific ones. And heads off a potentially messy
proliferation of ad-hoc methods right at the start.
>> 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.
Because an annotation that is seen by the JIT gives it the opportunity to
check the type of the declared instance with the VM structure it
corresponds to. I think dismissing annotations as syntactic sugar is a
bit unfair.
> Thanks,
> xiaofeng
>
cheers,
Robin
---------------------------------------------------------------------
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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 8/18/06, Robin Garner <ro...@anu.edu.au> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to
vmmagic
Posted by Robin Garner <ro...@anu.edu.au>.
Egor Pasko wrote:
> On the 0x1C8 day of Apache Harmony Mikhail Fursov wrote:
>
>> Egor,
>> Why do you think we need to support platform specific issues in helpers? Is
>> there any example that shows that we can't write a helper without reference
>> platform details?
>>
>
> It depends on how much of a helper code we want to write in Java. We
> can always say: "hey, this is platform-dependent, let it be a whole
> vmmagic and let JIT take care". If it is a large piece of code,
> it is not good to code it down in JIT IR(s) and is better written in
> Java. I think, we all agree here.
>
> As a 1 more example ... maybe some day we decide to inline fast-path
> of spinlocks.
>
> Which is a) a helper b) is platfrom-dependent.
>
> Implementing fast-path-spins in JIT IR is not a lot to do. But
> specifying the interface and updating all components (JITs) to handle
> that way of interaction on all platforms .. may make a burden. Coding
> spin-locking in Java would make it difficult to write optimal (think of
> explicitly parallel architectures...)
>
> Both approaches seem to be quite complicated here. But all-in-JIT
> approach seems to have more chances to be faster here.
>
> Thus, it would be good to have both:
> * vmmagic (inlined by JITs)
> * helpers (partially) written in Java (using vmmagic)
> and decide how fine-grained those magics should be depending on
> specific situation.
>
>
>> I think we should avoid #ifdef's in Java as much as we can.
>>
>
> Yes, my vision is the same. At least, until we come accross a large
> piece of system-dependent code that is good to be inlined by JIT. I
> think, it is not likely to happen, large pieces of code tend to work
> longer :) and inlining them does not give so much benefit..
>
>
Jikesrvm uses "//-#if" style constructs for platform-specific codes, and
it's something we are working hard to get rid of. I think it's
something you should definitely avoid at all costs.
One possible alternative is to use annotations instead, and the
preprocessing infrastructure that goes with them. But it's always
better to try to abstract over the particular concern somehow.
As a last resort, write platform-specific versions of whole classes, and
selectively include them at compile time. Of course chase down the
platform specific bits so they are as small as possible.
My thoughts on the thread-local storage issue is that it's a more
general issue of accessing shared data structures from the Java side of
the fence. So perhaps a method such as
Object org.vmmagic.utility.accessVmStructure(<identifier>)
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.
-- robin
---------------------------------------------------------------------
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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1C8 day of Apache Harmony Mikhail Fursov wrote:
> Egor,
> Why do you think we need to support platform specific issues in helpers? Is
> there any example that shows that we can't write a helper without reference
> platform details?
It depends on how much of a helper code we want to write in Java. We
can always say: "hey, this is platform-dependent, let it be a whole
vmmagic and let JIT take care". If it is a large piece of code,
it is not good to code it down in JIT IR(s) and is better written in
Java. I think, we all agree here.
As a 1 more example ... maybe some day we decide to inline fast-path
of spinlocks.
Which is a) a helper b) is platfrom-dependent.
Implementing fast-path-spins in JIT IR is not a lot to do. But
specifying the interface and updating all components (JITs) to handle
that way of interaction on all platforms .. may make a burden. Coding
spin-locking in Java would make it difficult to write optimal (think of
explicitly parallel architectures...)
Both approaches seem to be quite complicated here. But all-in-JIT
approach seems to have more chances to be faster here.
Thus, it would be good to have both:
* vmmagic (inlined by JITs)
* helpers (partially) written in Java (using vmmagic)
and decide how fine-grained those magics should be depending on
specific situation.
> I think we should avoid #ifdef's in Java as much as we can.
Yes, my vision is the same. At least, until we come accross a large
piece of system-dependent code that is good to be inlined by JIT. I
think, it is not likely to happen, large pieces of code tend to work
longer :) and inlining them does not give so much benefit..
--
Egor Pasko, Intel Managed Runtime 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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Weldon Washburn <we...@gmail.com>.
On 8/17/06, Mikhail Fursov <mi...@gmail.com> wrote:
> Weldon,
> I agree that we need TLS access in vmmagic, but I thought about slightly
> different and more primitive implementation.
> Writing something like this:
> SegmentRegisterFS segFs = new SegmentRegisterFS();
> or this:
> SegmentRegisterGS segGs = new SegmentRegisterGS();
>
> we add the knowledge of the platform to Java code. (+ 'new' operation is not
> used (constructor is private) for the most of the MMTk types)
> My proposal is to write something like this:
>
> Address addr = TLS.getAddressByOffset(offset_in_TLS)
Good idea!
>
> and to forget about platform related problems. Leave it to JIT or VM to
> decide how to access to TLS on particular platform.
>
>
>
> Egor,
> Why do you think we need to support platform specific issues in helpers? Is
> there any example that shows that we can't write a helper without reference
> platform details? I think we should avoid #ifdef's in Java as much as we
> can.
>
>
>
>
> --
> 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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Mikhail Fursov <mi...@gmail.com>.
Weldon,
I agree that we need TLS access in vmmagic, but I thought about slightly
different and more primitive implementation.
Writing something like this:
SegmentRegisterFS segFs = new SegmentRegisterFS();
or this:
SegmentRegisterGS segGs = new SegmentRegisterGS();
we add the knowledge of the platform to Java code. (+ 'new' operation is not
used (constructor is private) for the most of the MMTk types)
My proposal is to write something like this:
Address addr = TLS.getAddressByOffset(offset_in_TLS)
and to forget about platform related problems. Leave it to JIT or VM to
decide how to access to TLS on particular platform.
Egor,
Why do you think we need to support platform specific issues in helpers? Is
there any example that shows that we can't write a helper without reference
platform details? I think we should avoid #ifdef's in Java as much as we
can.
--
Mikhail Fursov
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Weldon Washburn <we...@gmail.com>.
On 17 Aug 2006 14:01:51 +0700, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x1C8 day of Apache Harmony Weldon Washburn wrote:
> > Windows uses ia32 segment register fs:14 for fast thread-local storage
> > access. I think Linux somehow uses the gs segment register.
>
> In general, it is implementation-specific (not older kernels).
>
> Here is a good link for that:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4915203
I took a look. It mentions some kernels use GS register, some have an
TLS related API that uses the LDT and some use the upper 10 bits of
ESP as a unique thread value. The upper 10 can then be used as an
index or hash into a JVM data struct that holds thread local data.
We need some approach to handle old linux kernels that use ESP. Maybe
add a compiler instrinsic that returns the current ESP contents
shifted right by 22 bits. Something like:
int index = espShiftedRightBy22Bits();
>
> I wonder, how to handle system-dependent code with Java vmmagic :(
> A simple if-then-else would make an #ifdef replacement?
Good point. We should have a project-wide standard on "java #ifdef".
Feel free to propose something.
>
> --
> Egor Pasko, Intel Managed Runtime 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
>
>
--
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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1C8 day of Apache Harmony Weldon Washburn wrote:
> Windows uses ia32 segment register fs:14 for fast thread-local storage
> access. I think Linux somehow uses the gs segment register.
In general, it is implementation-specific (not older kernels).
Here is a good link for that:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4915203
I wonder, how to handle system-dependent code with Java vmmagic :(
A simple if-then-else would make an #ifdef replacement?
--
Egor Pasko, Intel Managed Runtime 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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Weldon Washburn <we...@gmail.com>.
On 8/18/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > struct jvm_thread_block {
> > char * name of thread;
> > lock_t current_lock_held;
> > status current_state_of_thread;
> > blah, blah, blah...
> > int jit_private_data[16]; //assume this is offset 0x38 from start of
> > jvm_thread_block
> > int gc_private_data[16];
> > blah, blah, blah...
> > }
>
> Another way to store GC or JIT specific data in thread blocks could be:
>
> // In GC code - store GC data
> int gc_key = VMThreadMgr.tlsAlloc();
> VMThreadMgr.tlsSet(gc_key, gcDataBlockAddr);
>
> // Retirive GC data:
> VMThreadMgr.tlsGet(gc_key);
>
> In this case, GC or JIT don't have to be aware of the internal
> structure of a thread block.
I like the above idea. If the JIT really can make the above fast, I
would like to use it to associate MMTk thread specific objects to
DRLVM's thread-local data struct. To be clear, there is the issue of
compiling VMThreadMgr.tlsGet(key); with the C compiler and also with
the JIT. Optimistically, the JIT can replace this call with a
"vmmagic-like" intrinsic. The JIT will need to be able to call a
JIT/VM api during compile to learn the address arithmetic needed to
materialize the fs:14 pointer to "key" in DRLVM's thread struct.
Compiling the above with the C compiler is a different story. We
can't hack on the C compiler to include VM specific intrinsics. There
may be cases in C code where you need to get to thread local storage
quickly and have to revert to using __asm {mov eax, fs:[14];.......}
> Except the performance, are there any reasons why we may need to keep
> the fields like "gc_private_data" in the thread block?
I know I will need to stuff MMTk's thread specific collection and
allocation objects in the gc_private_data area. Then pull them out
quickly at runtime. While this job could be done using an ugly hack,
it would be best with straight forward integration into DRLVM. I will
send more MMTk/DRLVM design integration details within a week. I am
actively working on this area right now.
>
>
> > Of course, the offset into the JVM data struct is fragile and an edit
> > of the JVM thread block's header file could cause nasty surprises. On
> > the other hand, this data struct does not change very often. In
> > practice, it should not be any greater risk than what C header files
> > already impose on software engineering.
>
> I think the problem is that C/C++ isn't the only language which is
> defacto used in drlvm. JIT encoder internal API, lil, asm are the
> examples of other languages.
I would really like to see lil disappear. Ideally, all asm is
generated by the JIT. Even if we have to drop down to using the code
emitter to generate the asm, it should always be the domain of the
JIT. Thus either write in Java w/ vmmagic or JIT emitted asm or
somewhere between the two (class file annotations, ugly bytecode
edits,etc).
>Java/vmmagic may probably join this set
> as well. As a result, it may be very difficult to intercept every
> instance of access to the internals of a thread structure in case
> there will be a need to change it.
> On the other hand, I guess the bugs which can be caused by the misuse
> of the thread block are not the ones which can be easily identified...
OK. I agree. I volunteer to help clean up this code. But it will
have to happen after MMTk and GCV5 are on track.
>
> Thanks,
> Andrey.
>
---------------------------------------------------------------------
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
Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Posted by Andrey Chernyshev <a....@gmail.com>.
> struct jvm_thread_block {
> char * name of thread;
> lock_t current_lock_held;
> status current_state_of_thread;
> blah, blah, blah...
> int jit_private_data[16]; //assume this is offset 0x38 from start of
> jvm_thread_block
> int gc_private_data[16];
> blah, blah, blah...
> }
Another way to store GC or JIT specific data in thread blocks could be:
// In GC code - store GC data
int gc_key = VMThreadMgr.tlsAlloc();
VMThreadMgr.tlsSet(gc_key, gcDataBlockAddr);
// Retirive GC data:
VMThreadMgr.tlsGet(gc_key);
In this case, GC or JIT don't have to be aware of the internal
structure of a thread block.
Except the performance, are there any reasons why we may need to keep
the fields like "gc_private_data" in the thread block?
> Of course, the offset into the JVM data struct is fragile and an edit
> of the JVM thread block's header file could cause nasty surprises. On
> the other hand, this data struct does not change very often. In
> practice, it should not be any greater risk than what C header files
> already impose on software engineering.
I think the problem is that C/C++ isn't the only language which is
defacto used in drlvm. JIT encoder internal API, lil, asm are the
examples of other languages. Java/vmmagic may probably join this set
as well. As a result, it may be very difficult to intercept every
instance of access to the internals of a thread structure in case
there will be a need to change it.
On the other hand, I guess the bugs which can be caused by the misuse
of the thread block are not the ones which can be easily identified...
Thanks,
Andrey.
On 8/17/06, Weldon Washburn <we...@gmail.com> wrote:
> Windows uses ia32 segment register fs:14 for fast thread-local storage
> access. I think Linux somehow uses the gs segment register. Assuming
> we would like to access thread-local memory from vmmagic, below is a
> first stab at a design. The intention is to not disrupt existing
> vmmagic design and also keep things as clear and type-safe as
> possible.
>
> Add the following new classes to vmmagic:
>
> public class SegmentRegister
> { /*intentionally empty*/ }
> public final class SegmentRegisterFS extends SegmentRegister
> {/*intentionally empty*/ }
> public final class SegmentRegisterGS extends SegmentRegister
> {/*intentionally empty*/ }
>
> Add a few new methods to vmmagic Address class:
>
> public int loadInt(SegmentRegister segReg);
> public long loadLong(SegmentRegsiter segReg);
>
> public void store(int value, SegmentRegister segReg);
> public void store(long value, SegmentRegister segReg);
>
> Some sample Java code to see how the above would work in real life:
>
> Address addr = Address.fromInt(0x14);
>
> SegmentRegisterFS segFs = new SegmentRegisterFS();
>
> int tlsPtr = addr.loadInt(segFs);
>
> /*
> Thinking about how a "C" jvm like DRLVM is constructed, tlsPtr would
> be pointing at a C data struct. Let's assume the following layout for
> the C data struct
>
> struct jvm_thread_block {
> char * name of thread;
> lock_t current_lock_held;
> status current_state_of_thread;
> blah, blah, blah...
> int jit_private_data[16]; //assume this is offset 0x38 from start of
> jvm_thread_block
> int gc_private_data[16];
> blah, blah, blah...
> }
> */
>
> /*
> The JIT (or GC) would access their thread-local storage area via Java
> code as follows
> */
>
> Address addr2 = Address.fromInt(tlsPtr);
> Offset ofs = Offset.fromInt(0x38);
> //read jit_private_data[0]
> int privateData = addr2.loadInt(ofs);
> //read jit_private_data[1]
> ofs = ofs.plus(0x4);
> int privateData = addr2.loadInt(ofs);
>
>
> ---------------- end of code example
>
> Of course, the offset into the JVM data struct is fragile and an edit
> of the JVM thread block's header file could cause nasty surprises. On
> the other hand, this data struct does not change very often. In
> practice, it should not be any greater risk than what C header files
> already impose on software engineering.
>
> Comments?
>
> --
> 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
>
>
--
Andrey Chernyshev
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