harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weldon Washburn <weldon...@gmail.com>
Subject Re: Terminology etc
Date Wed, 25 May 2005 14:32:45 GMT
On 5/25/05, Steve Blackburn <Steve.Blackburn@anu.edu.au> wrote:
> I agree it is orthogonal to the language chosen to write the JIT. It
> is not orthogonal to the language chosen to write the GC.
> As you say, you really want the barrier expressed in either Java,
> bytecode or IR.  So you could write your GC in C and then specially
> code up your barriers and allocation sequences in Java or bytecode
> (coding in IR immediately introduces a dependence between your GC and
> a particular compiler).  In this case you're no longer coding in C (to
> paraphrase Geir ;-).  You're coding in Java|bytecode|IR and C.  Perhaps
> the mix of Java and C within a core element of the GC would be
> manageable.  But why torture yourself?  More importantly, if your goal
> is performance, modularity and flexibility (MMTk supports 8 or so GC
> algorithms), then treating barrier implementations as a special case
> is needless pain.

One reason is that Harmony will need to plug in GCs other than MMTk.
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.  Most OS
kernels are written in ansi C today.  A Harmony migration path that
allows JVM/OS integration would serve this project well.

> A much better example is the allocation sequence for a free list
> allocator (a non moving allocator is an important choice in some
> settings).

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

> As I said above, I don't forsee inter-module calling as a likely
> source of performance concerns.  I have advocated right from the
> outset and will continue to advocate a framework that allows modules
> to be written in either Java or C.
> I hope this clarifies some of the issues.

Thanks Steve for the clarification.  This helps.
  -- Weldon

> Cheers,
> --Steve

View raw message