Mr. Shudo,
I'm not aware of any commercial JIT today that compiles the same method
simultaneously. This is probably because today even if a JIT is re-entrant
and the locking/contention is minimal, there is no clear benefit from
running multiple "jit_me()" simultaneously. (I use "jit_me" to refer to the
stub function that invokes the compiler. Vtable's method entries are
initialized with the pointers to "jit_me"). If each of the multiple jittings
has incomplete profile information, it is probably better if the Execution
Manager consolidates the profile information and then let one jitting
proceed in order to generate the best code with more complete picture.
Multiple jittings are more likely as multicore becomes prevalent, but there
is no requirement that they be done on the same method.
Regarding using separate jit threads vs. using application threads to do the
jitting, I think Harmony should support both. Harmony should also support
a hybrid approach that is in use today. The hybrid apporach uses application
threads for jitting and uses a separate jit-thread for re-jitting. When a
method is encountered for the first time, the running application thread
performs jitting and replaces the "jit_me" stub with the jitted code. Today,
typically at most one application thread will do the "jit_me" for the same
method, because running many instances of jit_me() function on the same
method hasn't been shown to yield clear benefit yet. Furthermore, since
typically there is only re-jitting thread today, there won't be simultaneous
rejitting of the same method either. On multicores, re-jittings can take
advantage of the otherwise-idle cores to do expensive jitting to generate
higher-quality code, while the application thread performs fast jittings.
Thanks,
Steve Liao, Intel Managed Runtime Division
On 11/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> From: Steve Shih-wei Liao <[EMAIL PROTECTED]>
>
> > - Re-entrant JIT: Many JITs are not re-entrant. When running, for
> instance,
> > MTRT in SPECJVM, because multiple threads are running, multiple JITTing
> may
> > happen concurrently if there is no locking. The Execution Manager can
> put
> > locks before each JITTing in order to ensure that no multiple JITTing is
> > going on concurrently.
>
> Do you know an actual JIT compiling the same method simultaneously?
>
>
> HotSpot VM has a thread dedicated to JIT compilation and the compiling
> thread receive a compilation request from a queue.
>
> A JIT I have developed took another way in which a thread executing an
> application compiles the application. The JIT allows multiple threads
> to do JIT compilation simultaneously but a method is not compiled
> multiple times because of appropriate locks assined to each stage
> of JIT compilation.
>
> There are choices on the relationship between threads and JIT
> compilation:
>
> - Separated threads dedicated to JIT compilation.
> - Number of locks by JIT gets fewer?
> - Compilation takes much time in case that there are many active
> application threads. It leads to further starvation.
> Note that HotSpot VM has -Xbatch option to lighten this problem.
> - Exploits more processors remaining?
>
> - Application threads which also perform JIT compilation.
> - Exploits multiple processors for JIT compilation naturally.
>
>
> Kazuyuki Shudo [EMAIL PROTECTED] http://www.shudo.net/
>
>
