Good question! I'll reply according to the 4 areas in the previous email: abstracting over the mode of execution, asynchronous compilation, reentrancy, and supporting the mixing of JIT and interpreter. The Execution Manager (EM) could be designed to host both JIT as well as interpreter. The EM could also contain the execution policy. For example, interpret excusively or interpret until certain thresholds are crossed then JIT. One way of doing this is to have the EM build an internal configuration data structure to would hold the execution policy. The policy would be loaded via a *.properties file or even developer time makefile parameters.
There are a number of ways to support asynchronous compilation/re-compilation. For example, a timer based approach would sample method hotness for a time interval of "X", then recompile the hotest methods first in a separate thread. The java app threads continue without disruption. Harmony JVM needs to be designed to support non-reentrant JITs as a default. It also needs to be designed to take advantage of reentrant JITs. This is particularly important as the industry moves to multicore. To have clean, easy to maintain Execution Manager interfaces, there needs to be well thought out JIT ABI to C/C++ ABIs. This will allow activation records from JIT code to interoperate with activation records from an interpreter written in C/C++. Although this is messy and tedious work, getting the ABI issues sorted out early will make development of pluggable JITs and interpreters much easier. This in turn will allow Harmony to support a larger number of active developers/committers than would otherwise be possible. Steve Liao, Intel Managed Runtime Division On 10/31/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > So what does that interface look like? Have any suggestions? > > geir > > On Oct 30, 2005, at 8:51 PM, Steve Shih-wei Liao wrote: > > > Sure. (I had been out of country until last weekend.) > > Since there is a reason to support both JITs and interpreters, we > > should > > keep the option open to have interpreters and JITs. > > > > I think the modular interface from the VM core to Execution Engines > > should > > support both JITs and interpreters. Execution Engine interface should > > abstract over the mode of execution. This will cover a wide > > spectrum of the > > market segments. Cell phone environment may demand an interpreter or a > > light-weight JIT with small memory footprint. Server market segment > > probably > > prefers a powerful JIT. > > > > The issues of supporting both JITs and interpreters include: > > > > - Asynchronous compilation: Execution Manager can have a time-based > > interrupt to invoke Execution Engines to recompile. > > > > - 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. > > > > But if we want to allow concurrent JITTing, I think the JIT needs > > to be > > changed to stateless and some VM data structures that a JIT > > accesses needs > > to be changed to allow concurrency. > > > > - For the mixing of native frames and Java frames, who should own > > the stack > > layout (format of JIT and interpreter stack layout)? Probably VM? For > > example, GC should talk to that owner for the root set. > > Any thoughts? > > Steve Liao, Intel Managed Runtime Division > > On 10/2/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > >> > >> What don't you emerge it? :) > >> > >> geir > >> > >> On Oct 2, 2005, at 7:17 PM, Steve Shih-wei Liao wrote: > >> > >> > >>> Good email thread! Lots of different opinions have been expressed. > >>> It seems > >>> there are valid reasons to support both JIT and interpreter in > >>> Harmony VM. > >>> Looking into the future, it seems the Harmony modular framework > >>> needs to > >>> allow both JIT and interpreter modules to be plugged in. > >>> Designing a VM modular framework to accommodate JIT as well as > >>> interpreter > >>> brings up entirely new design topics. Perhaps a new thread on these > >>> issues > >>> will emerge. > >>> Steve Liao, Intel Managed Runtime Division > >>> On 9/23/05, Graeme Johnson <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> > >>>> "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 09/22/2005 > >>>> 06:34:44 AM: > >>>> > >>>> > >>>> > >>>>> [SNIP] > >>>>> > >>>>> > >>>>>> Geir> Basic thought is yes, I always figured we'd have this > >>>>>> pluggable, with > >>>>>> Geir> an interpreter for ease of porting, and then platform- > >>>>>> specific JIT. > >>>>>> > >>>>>> It seems to me that there's a design question here. For > >>>>>> instance, if > >>>>>> you want to eventually take interpreted code and compile it > >>>>>> (when it > >>>>>> is "hot"), for full pluggability your JIT(s) and your > >>>>>> interpreter need > >>>>>> to agree on some set of bookkeeping details in order to make this > >>>>>> possible. OTOH, you could make other decisions that make this > >>>>>> problem > >>>>>> go away, for instance having a single choice of execution > >>>>>> engine up > >>>>>> front; so the "fast JIT" and the "optimizing JIT" are just part > >>>>>> of the > >>>>>> same code base and only need to talk to each other, and can be > >>>>>> built > >>>>>> in an ad hoc way. > >>>>>> > >>>>>> > >>>>>> Personally I'd be just as happy if we only had a JIT. There are > >>>>>> already plenty of interpreters out there. > >>>>>> > >>>>>> > >>>>> > >>>>> But I would think that we'd want both, right? An interpreter that > >>>>> builds on anything to ensure wide platform portability, with > >>>>> the the > >>>>> ability to augment with a JIT for those platforms for which people > >>>>> are interested in creating a JIT... > >>>>> > >>>>> > >>>> > >>>> Our experience with the J9 virtual machine has shown that > >>>> supporting both > >>>> interpreter and JIT solutions provides a valuable degree of > >>>> flexibility. > >>>> > >>>> Bytecode interpreters have several advantages: > >>>> > >>>> - Portability: Support for rapid bootstrapping of new platforms by > >>>> virtue > >>>> of being easier to port. > >>>> > >>>> - Size: Very compact interpreters (<100K) can be constructed for > >>>> memory > >>>> constrained environments. > >>>> > >>>> - Flexibility: A well-written interpreter is easy to modify for > >>>> research > >>>> or experimental purposes and can trivially support runtime- > >>>> pluggable > >>>> features like debug and instrumentation. > >>>> > >>>> Admittedly, supporting combined interpreter/JIT modes does require > >>>> careful > >>>> > >>>> attention to stack frame design and associated stack walking code. > >>>> And > >>>> yes, the transition between interpreted and native code (either > >>>> JIT'ed or > >>>> JNI) requires some special handling. However, good stack frame > >>>> design is > >>>> critical to efficiently supporting several other critical areas of > >>>> the JVM > >>>> > >>>> including exception throw, GC, and debug support. > >>>> > >>>> IMO the relatively small amount of extra code to maintain the > >>>> interpreter > >>>> and extra stack walk support is well worth the effort. > >>>> > >>>> Graeme Johnson > >>>> J9 VM Team, IBM Canada. > >>>> > >>>> > >>> > >>> > >> > >> -- > >> Geir Magnusson Jr +1-203-665-6437 > >> [EMAIL PROTECTED] > >> > >> > >> > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > >
