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