harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew French" <matt...@camary.co.za>
Subject Re: Terminology etc
Date Thu, 26 May 2005 09:17:39 GMT
Steve Blackburn said:
> 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...
> I think "merging" the OS and VM memory managers is a big step and
> outside the immediate goals of Harmony.

I am not even sure if merging the OS and VM memory managers is worthwhile

One reason is a hardware constraint: most hardware handles virtual memory
in pages, typically 4kb at a time. So managing memory at a granular level
will result in a lot of wasted space.

A more pragmatic reason is that as the number of allocated items grows it
takes more and more time to allocate and free memory. Or you gave memory
fragmentation issues. Or more often than not you have both problems.

The operating system uses a similar technique to APR memory pools and for
a similar reason. It allows it to ignore all memory leaks and just dump
the memory of an entire process.

(Although I am sure you know all this already - but I think it should be
stated that the OS and VM memory managers solve entirely different

Maybe a more interesting approach would be to have a VM that supports
OS-like allocation. This could be useful in container applications like
JBoss - reload the EJB application and remove all references to the
previous instance. Think of it as an in-VM stop and start.

Even so this would require non-standard extensions, and JBoss already
solves most of the issues around reloading. We already have a loong list
of issues to solve, and this should not even come onto that list...

- Matthew

View raw message