harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: Terminology etc
Date Wed, 25 May 2005 22:16:15 GMT
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 

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

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




View raw message