Hi Weldon,
One reason is that Harmony will need to plug in GCs other than MMTk.
Absolutely. MMTk was designed from the outset with this in mind (at the
time Jikes RVM already had another set of collectors).
Another reason is that in the long term the JVM's memory manager (GC)
probably ends up being merged with the OS's memory manager.
Hmmm. This is not at all obvious to me. I can imagine closer coupling
of the VM and OS scheduluers. I understand why the GC may need to
cooperate more with the OS than it currently does
(http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf), but the interfaces
required for that are thin and coarse grained. I think "merging" the OS
and VM memory managers is a big step and outside the immediate goals of
Harmony.
Most OS
kernels are written in ansi C today. A Harmony migration path that
allows JVM/OS integration would serve this project well.
I think that's a long bow to draw as far as motivating the use of C!
Harmony is intended to be OS-neutral as far as I know. Thus I can't
imagine it not working through some OS abstraction layer, which will
make it irrelevant what language a particular OS kernel is written in.
If we really want to be that forward looking, we should probably be
writing in Java or C#, as that is where the cutting edge of OS research
is headed anyway ;-) (http://jnode.org,
http://research.microsoft.com/os/singularity/).
Interesting. I remember hearing that free list allocators are useful
for embedded applications where RAM is constrained. In the embedded
market, I remember hearing an interpreter is preferred because the
footprint bloat of adding a JIT is unacceptable. Also for many
embedded situtions, the performance of the java code is not the top
concern. In other words, inlining GC alloc and write barrier is not
useful to the embedded JVM marketplace. Do you foresee or know of
uses other than embedded where a free list allocator is useful? If
anyone in the embedded JVM market is reading the above, can you
confirm/deny the above statements?
I agree with some of what you say. However, another context is realtime
work in performance critical contexts (this sort of work is happening in
the leading commercial VMs right now). Moreover, even in an embedded
context, precompiled, optimized code (libraries for example) remains
important. I could go on at length about this, but in short, I think
that having a system that is general enough to allow you to do that,
whilst attaining a performance advantage to boot is a good idea. I'm
all for folks writting memory mangers in C if they like. I'm just
pointing out that as we both agree, performance critical elements of the
memory manger will want to be expressed in Java (or bytecode or IR)
regardless of what you write the rest of it in.
I am curious what inlining the entire free list allocator does to code
size. I worry about code bloat. Perhaps you can send me pointers to
the analysis.
I also worry about code bloat. We have a "porky" regression test that
checks some of this systematically. As far as the free list goes, you
need to realize that the compiler *statically* evaluates the sizeclass
selection code I sent in my last email, reducing it all down to a simple
compile-time constant which is used to index the free list. There is no
code bloat issue there---to the contrary, this removes the need for the
instruction associated with a method despatch and replaces them all with
a simple constantl. Kathryn McKinley and I wrote a paper on this
subject (in the context of write barriers).
http://cs.anu.edu.au/~Steve.Blackburn/pubs/abstracts.html#writebarrier-ismm-2002
Cheers,
--Steve
