Hi Kirk, Thank you for the detailed reply.
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. > I live in hope :-). I guess a lot of the venting on this thread is a result of the difference between the constraints of the current implementations and being able to see what is possible (or different elsewhere). > 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.... > Yep, we do that too, mostly bounded buffers between threads. > 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. > I guess what I find annoying is the memory reservation is, from the user's perspective, only a constraint. It obviously simplifies the implementation, however as a user it doesn't buy me anything. Set the value to low and I can run out of memory with resources still available on the box, set it too high, either the app doesn't start or (as happened yesterday in one of our test environments) the guest OS can over commit virtual memory and the host OS's OOM killer takes out the guest. Not much that Java can do in that case. To be more objective, you're right, if you experience an OOME you're missing a step in the understanding of your software. Maybe a missing load test. > 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. > It always inspiring to speak to Gil. I like that Azul are not content to settle with what's available and are constantly reaching for what's possible. I think their proposed memory interface changes will get through sooner rather than later, although the scheduler changes will be a tougher sell to the linux crowd. As for the Intel side, who knows. If they could see the potential for a hardware load value barrier outside of Java, perhaps. Although there are a hugh number of features in the Intel chips driven by the gaming industry (e.g. write-combining buffers), so perhaps the Java crowd could have some influence too :-). I think that it's awesome that Gil and his team are even trying. Mike. -- 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/-/bDGDQOGBVNYJ. 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.
