harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Sun, 20 Aug 2006 09:19:37 GMT
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


Mime
View raw message