|
From mailing list and private discussions, I believe there is a common problem with how the spaces are defined.
1) a user runs a benchmark and gets an OOME I believe this change is important but we also need at least to document how the size of a space can be increased to avoid the OOME. I can have a look at it, but I don't think it makes a whole lot of sense since with discontiguous spaces (which we've had for a year or so now), spaces no longer run out of virtual memory. (Although it DID make sense back when Peter made the request since back then spaces could and did get exhausted, and likewise, I think the Sun VM has fixed sized spaces).
So to know what space a failing allocation is going to may be of incidental interest but in general doesn't tell us much about why we got the OOME now that we're using discontiguous spaces. Do my comments make sense, Ian? I'm happy to have a look at improving the output in any case, so no need to close this tracker, but I just wanted to point out that it is no longer the case this will provide what Peter was originally asking for because the system no longer works that way. OK. As noted in 619, there are still some spaces (such as the PLOS) which use contiguous spaces (i'd forgotten about the PLOS when writing the above). For these spaces, the problem remains a real one. I'll try to address this.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
OutOfMemory exceptions should indicate which space was exhausted
1. The reason for the OOME: "<space> is full", or "Page budget exhausted".
2. The allocator that is being used: "Failed allocation to <space>, etc".
And then of course we could combine the two