Steve Liao wrote: > I was just wondering if a unified format (more than a unified interface) > makes sense for Harmony. One advantage is to allow GC to enumerate > without relying on JIT. Any other benefit?
Of course, both ways could work. At a high level, the stack maps are a data structure created by the JIT compiler and used by the GC. Following OO-design principles, the code that interprets the maps should be associated with the data structure itself. Thus, it really isn't part of the JIT or the VM. Your question asks should there be one such type of data structure or should we allow different types for each compiler, if desired. Although "one type fits all" seems more attractive (less code in the system), I think we have to be careful about not imposing design decisions on the JIT. For example, in Jikes RVM the approach that the non-optimizing (i.e., "baseline") and optimizing compilers take to finding the stack maps are very different. The optimizing compiler does a live analysis on all reference types, and thus, has a (potentially) different stack map for GC point in a method. On the other hand, the baseline compiler does not perform any real register allocation, so it can get away with a much simpler stack map data structure. Therefore, at least in this design space, it is advantageous not to require the uniform data structure on all compilers. > In this scheme, JIT records the compiler > version (baseline or optimizing) and at runtime if a stack map is > needed by GC, the same version is invoked to recompile the method and > recover the stack map. Although this could work, one needs to be careful because when a GC is invoked space is typically scarce, and thus, performing an arbitrary compile (to get the stack map) may be problematic. I believe this becomes more obvious in a Java-in-Java approach (the compiler and application share the same heap), but one could argue it is also an issue in a non-Java implemented VM, as memory is really just memory, whether it is given to the Java heap or the C runtime. Mike
