Re: Question about memory size and performance

Attila Szegedi wrote:
> On 2007.12.11., at 12:45, Endre Stølsvik wrote:
>
>> The communications between the kernel and the GC could be even tighter:
>>
>> "Kernel: dude, I'm really in bad need of some memory now, could you
>> please free some? You don't REALLY need those 1.5 gigabytes, do you?"
>
>  From my long gone days of Windows programming, I remember Windows sent
> out a WM_COMPACTING message to all top-level windows (your non-UI
> processes could create an "invisible window" for purposes of getting
> such notifications) when it was low on virtual memory. I remember I even
> filed a RFE in Sun's bug database years ago telling them it might be a
> good idea to run a full GC when the JVM process receives WM_COMPACTING.
> Strangely enough, Sun's bug database no longer brings up anything when
> searching for WM_COMPACTING.
>
> Anyway, I agree that having the OS notify the processes when it's low on
> memory is a good option to have, but I believe it should be sent out
> only when the system is approaching its virtual memory limit, not
> physical memory limit. It should be a last-ditch attempt to prevent
> running out of virtual memory.

Well, I don't agree on this - or at least, there could be two messages.

Since GC can be thought of as some advanced VM stuff (remember that GC
nowadays use Compacting collection, and that the JVM resizes the heap if
"too much" memory is available, see later), it could do well to
cooperate with the VM system. It is much better that a huge process
sheds some of its memory, than to page things to disk.
   A Java process won't shed memory unless it has 70% above what it
needs, and then it won't shed more than down to 30%. If the VM could ask
the GC to "eh, please shed some _now_, could you", it might get a way
faster action than having to dump things to disk. And if that particular
JVM is not in actual use right now (it's minimized), then it won't
matter AT ALL.

Don't always think serverside for Java.

>
>> "Kernel: Okay, so Rome is burning, and I'll evict some of your stash now
>> - have any preferences, do you?"
>
> I'm not sure whether that makes sense. Virtual memory managers typically
> use LRU strategies, maybe enhanced to also factor in the cost of writing
> out a dirty page (therefore being biased toward ditching clean pages
> from physical memory earlier). I'm not sure if application-specific
> intelligence could enhance things here.

That is a point - but the JVM could possibly do a GC at that point,
compact its memory usage (thus switching a bit around on its active
pages), and then tell which pages are good to go - its just a harsher
variant of the above ("I'm not nice anymore, I WILL kill some of your
pages - but you may optionally give a hint of which").

Just a thought - and it would possibly not cost very much to include
such features once you start to write this Kernel/VM-to-Process interface.

>
>> "Process: I'd like to really fatten up - but how much may I ask for and
>> still not go into The BadLands?" (aka Swap).
>
> Hm... I'm not sure if kernel could give a reliable answer to this one,
> as it depends on what other processes on the box are also doing.
> Physical memory is also used by the OS for other purposes than keeping
> the processes' working sets (i.e. for filesystem caching), so this'd
> again be a hard thing to get right (that is, use it in a way that
> actually increases the overall performance of the system).

This I certainly don't agree on - of course the VM may tell you
approximately how much memory there are left in the system - type "free"
on any Unix box, and you have the answer.

Note that this is more of a Server-style idea, single-purpose: Instead
of using -Xmx4096m, you could do a -XmxMAX or something. If this
cooperated with the VM in a manner as described on the first idea
("Kernel: I'm low on mem, shed now!"), one could have the heap size
float along the maximum possible. Do note that I in particular think of
soft-reffed caches in this case, which I think is a common case for
server side heavy-memory uses: the "excess" memory would always be used
for caching, and when the kernel needed us to free some memory, it would
be the soft references that had to go.

See, an underlying idea I have, is that the application might be a
better judge of what is smart to evict, than the VM system.  The
application might have more sophisticated ideas of what objects are good
to go. If they cooperated, instead of the VM doing very coarse-grained
decisions based on actual memory pages, things could possibly go smoother.

To bring this back to java again, one would need a callback thing from
System that forwarded the call from the kernel: "Please see if you can
free 36 megabytes".

This recall system is quite possible to implement on the application
side: I've just written such a system to get fine-grained control over a
bunch of BufferedImages residing in memory, using a somewhat
sophisticated cache. The cache first needs to obtain a "memory lease"
from the "memory landlord" in bytes to be allowed to do the
BufferedImage allocation (it is very easy to pretty accurately calculate
the need of a BufferedImage). If the landlord goes low on memory, it
"calls back" some of the leases - first it does a "soft round", asking
the cache to "please release X amount", but if this doesn't work, it
goes brutal, demanding specific leases back. It's really quite nice, and
would be really cool if I could use a dynamic mem max, instead of the
very fixed max I now use in the landlord.
   And this is supposed to be a Desktop app, btw..!

Do note JSR 284 (and 278):
http://jcp.org/en/jsr/detail?id=284
http://jcp.org/en/jsr/detail?id=278

Endre.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com