harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Slava Shakin" <vyacheslav.p.sha...@gmail.com>
Subject Re: [drlvm][threadmanager] Fast thread local data access
Date Fri, 20 Oct 2006 13:48:45 GMT
I like the proposal about delegation of encoding to another responsible 
component (TM in this case). Or shall we call it binary inlining of VM 
helpers?
It seems to fix the remaining minor modularity issues we failed to solve 
with magics.

We could introduce something like TLSLoadMacroInst in CG which encoding 
would be delegated to TM.

My minor concern is that TM imposes additional register constraints on 
TLSLoadMacroInst receiver operand (EAX), but this makes generated code only 
very slightly worse in case of fs:[14h] load and all alternatives I thought 
about are more complicated.

I think a generic encoding interface exposed by a component could return for 
a given helper a mask of affected registers, description of input and return 
parameters, and should not produce any other side effects including VM calls 
or exception throwing. BTW implementing a similar description mechanism for 
traditional VM helpers will also help modularity. Instead of helpers, we 
could think about extensible magics framework where magics are 
expanded/encoded by responsible components.

Overall, we could probably start with the TLS-only specific solution 
provided that gen_hythread_self_helper doesn't change any register except 
for EAX on any OS.

--
Slava Shakin

"Artem Aliev" <artem.aliev@gmail.com> wrote in message 
news:187bb05d0610200402y39f4791dk5a46f42fb20a2651@mail.gmail.com...
> Mikhail,
>
> Right now the TM uses vm helper approach for the fast TLS access.
> See vm/thread/src/thread_helpers.cpp:
> fast_tls_func* get_tls_helper(hythread_tls_key_t key);
>
> It looks reasonable for performance, to divide it in two part,
> get_tls_pointer_accesor() and get_tls_storage_offset().
>
> First one is already implemented but not added to interface:
>
> /**
>  *  Generates tmn_self() call.
>  *  The code should not contains safepoint.
>  *  The code uses and doesn't restore eax register.
>  *
>  *  @return tm_self() in eax register
>  */
> char* gen_hythread_self_helper(char *ss) {
> #ifdef FS14_TLS_USE
>    //ss = mov(ss,  eax_opnd,  M_Base_Opnd(fs_reg, 0x14));
>    *ss++ = (char)0x64;
>    *ss++ = (char)0xa1;
>    *ss++ = (char)0x14;
>    *ss++ = (char)0x00;
>    *ss++ = (char)0x00;
>    *ss++ = (char)0x00;
> #else
>    ss = call(ss, (char *)hythread_self);
> #endif
>    return ss;
> }
>
>
> It will be also good to make order on TLS usage
>
> 1. refactor HyThread->jit_private_data, to be usual TSL data.
> 2. add hythread_get_tls_suspend_request_offset function for JIT
> back-branch polling.
> 3. refacor vm_get_gc_thread_local() to use hythread TLS directly.
>
> I'm looking forward for a patch from you.
>
> Thanks
> Artem
>
> On 10/20/06, Mikhail Fursov <mike.fursov@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
> 




---------------------------------------------------------------------
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