Hi,
> Memory is generally never given back to the OS as it's a very very tricky > thing to do. To give memory pack you need to guarantee 100% that you have no > pointers to anything in the space you're about to give back or you risk a > SEGV. In some cases, dealloc does nothing. > > I would of thought that is something the GC needs to do anyway. If it's not > 100% certain that a segment of memory is free of back references doesn't it > risk data corruption if the memory reused for more managed objects in the > same VM? I may be missing something, but seems like both problems are > equally hard (or essentially the same). I was tired and sick... ha, sick and tried ;-) when I first responded. how about I put it more succinctly , GC works in Java heap, which is a data structure built in a contiguous chunk of memory allocated from C heap. It reserves *all* the memory it needs and then mallocs out of the reserved space. Java heap data structure does resize it's self using ergonomics settings (the parallel collector data structures are easily adaptive because the algorithm requires application thread to be halted while CMS being mostly concurrent has to struggle with using a multi-threaded thread safe data structure (not easy)). The OOP (ordinary object pointer) does not have to be a direct pointer into memory. However, in openJDK it happens to be so. Which means that as objects are moved by the collector, the collector is obliged to find everything pointing to that object and swizzle the pointer or in the case of G1, lay down a pointer in the remembered set. In the case of the old Azul VM, they set an OS trap that was triggered when something attempted to use that address. The trap swizzled the pointer in hardware. So, memory is still allocated but the top of heap marker is moved according to what hotspot resets it to at the end of a GC cycle (another reason why CMS is less adaptive, the resetting of data structures happens during an non-STW phase). With G1 came the move to use regions. Regions are maintained on a free list so while it seems like it maybe possible to return regions back to the OS, that would only be possible if the right regions were put onto the free list. So, it might be a future option but we're not there just yet. BTW, it's very common to have data structures that size themselves at startup and then remain fixed in size for the duration of the run time. A number of them are found in the kernel such as process heap, bit map for file descriptors.... > > Should one let a JVM take as much heap as is possible? I think it's a pretty > dangerous thing to do. If you let the JVM take *all* memory, what happens > when it runs out. Current if the JVM runs out of memory (not native C heap > but Java heap) there is still something the JVM can do to try to recover. > Even is native heap is seemingly exhausted, there are guard pages put into > the process that allow the JVM to try to do something reasonable. > > If an implementation was not constrained by requiring a contiguous heap and > there was plenty of resources available, then a reasonable action could be to > reserve more memory from the OS. It needn't take all the memory, it could be > smart and look at available resources and system configuration (e.g. > over-commit limits) and fall back to existing means to dealing with a rapidly > exhausting heap, before the OOM killer kicks in. This would allow the > default configuration of a JVM to be much more conservative with its initial > startup defaults. The 1/4 of resources always seemed to me like an overly > aggressive default. That is the way it current works, you take what you need and reserve the rest. If you have an OOME you've generally got a problem, a bug in your application and it would behove you to fix the bug. If you have a temporary high water mark, use the parallel collector. It handles this situation very very well. I've got evidence of that from a JVM supporting a website that I bet everyone on this list uses (sorry can't name it) that is subject to spikes in load every time something happens in webosphereland. > Current implementations (including Azul's) are all encumbered by these > restrictions. Azul just happens to be a bit smarter at the moment in how they > manage it. But even they are constrained as to what they can do by the > underlying hardware/OS. In fact, they run in a hacked up OS that is > specifically tuned for their JVM. Nothing wrong with this but.... > > The way that Gil Tene's explains it, their OS changes would be generally > applicable to all managed VMs. I.e. it is an API change for the interaction > between the user application and OS for managing memory. However, I guess > that it may only be applicable if the GC compacted memory in a pattern > similar to Azul's. Gil has a dream and a dream team that can implement it. However, what he wants to do requires that he gets a number of groups out side of his sphere of influence to accept his vision. I am totally in Gil's camp w.r.t the changes that he'd like to see coming from Intel and the Linux camp. However, both groups seem to have other priorities at the moment. I predict that Gil will be successful with the Linux camp. I'm not so sure about Intel. That said, Azul is pushing the boundaries of what a collector can do but they've not solved the problems that the Oracle HotSpot team and the IBM team haven't been able to solve just yet. I suspect once they do, the artificial OOM errors that you all are complaining about will go away. Regards, Kirk -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
