Good idea. We can use it in fast path of GC allocation. We can have fast TLS base access compiled in managed code + constant already known offset of TLS-fields used by GC. Can be significant speedup in comparison to current scheme. One thing to care about is intercomponent communication of TLS values offsets used by GC. -- Ivan
On 10/20/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
All, The TM architecture implies any component that needs to store threadlocal data to reserve a slot: extern HY_CFUNC IDATA VMCALL hythread_tls_alloc PROTOTYPE((hythread_tls_key_t* handle)); The key can be used to get/set the allocated memory before its freed. The problem is that JIT must know the final offset of the memory inside of the TLS local struct to emit optimized code. The examples are: BBP, escape analyzer, fast-helpers... We can solve the task by adding this method to the TM interface: size_t hythread_tls_get_storage_offset(hythread_tls_key_t handle); Is it OK? If yes, could I do this or anyone else wants to do it by himself? -- Mikhail Fursov
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
