Comments on: Java Memory Management Improvement Proposal

By: Tim

Tim — Mon, 22 Dec 2008 03:38:45 +0000

Your proposed solution sounds a lot like just having separate processes (JVMs).

By: Rob Di Marco

Rob Di Marco — Fri, 31 Oct 2008 16:29:04 +0000

@R Hayes Very good suggestion to the problem IF I can control the safe abort of the resource threads. In my above example with Fisheye however, I am using a third party application and reliant on their developers to put the hooks into their runtime processes.

By: R Hayes

R Hayes — Fri, 31 Oct 2008 14:45:22 +0000

Rather than trying to sort out which objects belong to which thread (not an easy problem!), have a watchdog thread that monitors memory usage (see Runtime.freeMemory(), Runtime.totalMemory(), Runtime.maxMemory()), and kills dispensible threads if memory exhaustion approaches.

Please don’t literally kill the threads; instead, program in a safe abort (or suspend to external storage) method. Thread.kill is not thread-safe.

By: Rob Di Marco

Rob Di Marco — Fri, 31 Oct 2008 12:24:46 +0000

@Kirk You are right that the objects allocated on the heap localized to the thread that eventually causes the OOM will be dumped first. But the problem is that there is no guarantee that the resource hogging thread will be the one that triggers the OOM error. It could be a “lighter” thread that causes the OOM and has its objects released.

By: Kirk

Kirk — Fri, 31 Oct 2008 05:51:22 +0000

OOME was a bit of a shock to me when I first ran into it in 97. Prior I’d been working with Smalltalk virtual machines and in particular, the GemStone virtual machine. That VM was connected to database which meant that is could spill memory onto disk. However, Java can’t and if you want it to play nicely with other applications, you need to define some limits. Otherwise a troubled app/thread could cause the VM to consume the entire machine. That said, allocating a portion of heap to a thread is possible. In fact it’s already being done. As long as you keep all reference localized to a thread (relies on escape analysis), objects should be allocated on heap that is localized to the thread. I believe (but would need to check and confirm) that this size of this space is both capped and configurable.

By: Rob Di Marco

Rob Di Marco — Thu, 30 Oct 2008 22:55:29 +0000

@Dave You are entirely correct about this being a feature of real-time JVMs. But my problem does not require a full real-time implementation. I am not interested in determinism. For example, I don’t require isolation from GC pauses. While I could use a real-time JVM, I’d rather some of the memory features be ported to the standard JVM.

By: Dave

Dave — Thu, 30 Oct 2008 19:28:35 +0000

Heap segmentation is already a feature of real-time JVMs. Look into JSR 1 to find out what sort of capabilities are available. I will warn you that managing this sort of thing is not as easy as it sounds.

By: ctwise

ctwise — Thu, 30 Oct 2008 18:37:36 +0000

I would much prefer getting rid of min/max heap sizes and permanent generation sizes altogether. I see no reason why I have to figure out the appropriate size of a JVM instead of having it work like every other application, pulling memory as needed from the OS and giving it back when it releases objects. I understand the technical problems but it’s high time they went away for desktop/server uses.

By: David Hofmann

David Hofmann — Thu, 30 Oct 2008 14:17:07 +0000

Do others see value in this proposal?
Definitely