harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][vm, mmtk] adding thread-local storage functionality to vmmagic
Date Mon, 21 Aug 2006 09:49:17 GMT
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


Mime
View raw message