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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
