harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Renaud BECHADE" <renaud.bech...@numerix.com>
Subject RE: Terminology etc
Date Thu, 26 May 2005 01:44:02 GMT
>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.

(Beware: I am speaking from a pure user perspective, as I never wrote a JVM
by myself)

When I was doing benchmarks for Docomo phones and so, it appeared there were
practically two big issues with the GC:

1/ memory fragmentation: code can not allocate objects anymore (yes, some
implementations are real crap, but this is nothing compared to the CG shit
they embed in: on some occasions /interpreted/ java code was just 10 times
to 50 times faster than the 'native' implementations, because, well, we used
reasonably optimized algorithms instead of crappy dummy naïve
implementations), as it means memory has to be 'repacked' once in a while,
this leads to item 2:
2/ random performances: in real-time and/or GUI applications this is
particularly critical, as one cannot afford to block the VM for a few
seconds for a GC pass at random times (again we had surprises). 

So far as JIT is concerned, I think the question is more like a
psychological issue, as early JIT were not, well, real-time-wise acceptable.
AOT is of course OK. Performance can be an issue IMHO, as people are trying
to code more and more in 'safe' languages, and for numerical algorithms,
interpreted code is just not acceptable most of the times [1]. Of course
rapid boot is a must have.

A good VM for embedded systems can mean a revolution on development methods,
as it is relatively easy to build emulators (and then, for instance, test
numerical algorithms with a descriptive model of the physical parts of the
system; this is for instance a research subject in robotics, as it is costly
and sometimes really dangerous to have a robot go mad during physical
tests). That being said, embedded system developers can be really, really,
really, really conservative so that this will probably take some times to
happen.

Also, formal code checks are probably easier on JVM bytecode than on full
bloated C code... (That is another point in favor of JVM-based embedded
systems)

I guess that OS-kernel-VM or OS-in-Java systems suffer the same kind of
constraints.

Regards,

RB

[1] By the way, if the Java language committee took some time to add
operators... 

-----Original Message-----
From: Weldon Washburn [mailto:weldonwjw@gmail.com] 
Sent: Wednesday, May 25, 2005 11:33 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Terminology etc

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


Mime
View raw message