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