[kaffe] What is the rationale for Kaffe's VM memory limits? (The "-mx" and "-ss" switches.)

[Mark J Roberts]

Dalibor Topic:
> The patch has (at least) one problem, it relies on Runtime.exit()
> to print the map of stack traces. Apparently it seems to be hard
> to get freenet to exit(). So I'm not sure how to proceed from
> here: if it is possible to tell a freenet node to shut down
> through exit(), that would be helpful, otherwise  I could add a
> thread that prints out the map in regular intervals.

I'll hack something together and reply with that stack trace map as
soon as I have the time.

I suspected that Sun's implementation also had the memory limit. I
haven't used a proprietary JVM in ages, so I can't say whether Kaffe
is much worse. Freenet is a really bloated program no matter how you
run it, in any case.

It's entirely reasonable that a user would _want_ his OS to page out
data. The working set nearly always constitutes only a small share
of a program's allocated memory.

I don't see why the frequency of garbage collection relates to
this--that blurb explicitly suggests that reducing its frequency
through allowing more "slack" is a false optimization. What's more,
if any JVM were crazy enough to wait until the heap limit is hit
before invoking the GC ("helps determine when a garbage collection
(GC) will take place"), even lightweight programs will consume an
average of half the heap limit in memory.

So I'm not at all persuaded that Sun is doing anything remotely sane
with that limit, or that Kaffe needs to fall into the same trap.