> > Man, this thread contains a lot of FUD about how GC works (or doesn't > work). > > First point, Java heap must be contiguous for the current GC > implementations. > I'll hold my hand up, I'm definitely wrong on that case (should check my assumptions first).
> 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). > 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. > 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. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/20bKeDtFTuAJ. 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.
