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. _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe