RVM

OutOfMemoryError when allocating a 200 MB tab

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 3.0.1
  • Fix Version/s: 3.1.0
  • Component/s: MMTk: GenMS
  • Labels:
    None
  • Environment:
    Linux IA32 in host and target with production config (GenMS GC). The machine is a bi xeon with 2GB of RAM with a 32 bit Debian GNU/Linux
  • Number of attachments :
    0

Description

When allocating a 200 MB tab, a OOM is thrown. Here is a code which lead to a OOM :

package lip6.jikesrvm.bench;

public class Test
{
public static final int NB_ELEM = 200 * 1024 * 1024 / 4;
private static int[] tab;

public static void main(String args[])

{ tab = new int[NB_ELEM]; }

};

The program is run with rvm -cp barrier/bin -Xms1G -Xmx1.5G -X:processors=all lip6.jikesrvm.bench.Test

This perfectly run with sun JVM or with NB_ELEM set at 20 * 1024 * 1024

Issue Links

is superceded by

Bug - A problem which impairs or prevents the functions of the product. RVM-823 Fix heap growth manager's reporting of heap size

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. RVM-647 Allow nursery to be discontiguous

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. RVM-822 Improve failure mode for out-of-address-space errors

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Grove added a comment -

My guess would be that this indicates that MMTk has broken up the virtual address space such that it is unable to find 200Mb of free contiguous space to satisfy the request.

Show
David Grove added a comment - My guess would be that this indicates that MMTk has broken up the virtual address space such that it is unable to find 200Mb of free contiguous space to satisfy the request.
Hide
Permalink
Thomas Preud'homme added a comment -

I did a few test and it seems that the bug appears at 200MB of memory ask precisely. There is no problem with a 199 MB tab allocation. It sounds like a hard coded limit in Jikes for me, but maybe it is just a coincidence.

Show
Thomas Preud'homme added a comment - I did a few test and it seems that the bug appears at 200MB of memory ask precisely. There is no problem with a 199 MB tab allocation. It sounds like a hard coded limit in Jikes for me, but maybe it is just a coincidence.
Hide
Permalink
Steve Blackburn added a comment -

I have found that it works fine if you use a full heap collector (Immix or MarkSweep) and explicitly set the minimum heap size. Seems that there is at least one bug in the heap growth manager and its reporting of current heap size.

Show
Steve Blackburn added a comment - I have found that it works fine if you use a full heap collector (Immix or MarkSweep) and explicitly set the minimum heap size. Seems that there is at least one bug in the heap growth manager and its reporting of current heap size.
Hide
Permalink
Steve Blackburn added a comment -

OK, so there's also some kind of a bug in the discontiguous space allocation. For some reason it is failing to find large chunks of discontiguous space which are in fact available. Not a problem for full heap GC, which is interesting. Investigating further.

Show
Steve Blackburn added a comment - OK, so there's also some kind of a bug in the discontiguous space allocation. For some reason it is failing to find large chunks of discontiguous space which are in fact available. Not a problem for full heap GC, which is interesting. Investigating further.
Hide
Permalink
Steve Blackburn added a comment -

Thomas,

Your immediate problem should have been fixed by r15632. Please follow up if there is still a problem.

The problem was that in the generational collector, the nursery is by default limited to a fixed amount of virtual memory. If an object does not fit in this space, allocation fails with an out of memory error. I have fixed things now so that any such allocation will go to the large object space.

I'm not closing this yet, because I still have a handful of followups:

1. The heapgrowth manager needs to be fixed, as per my previous note.

2. We probably should re-explore discontiguous nurseries (it is all there, just a matter of flipping a boolean)

3. We need to update the MMTk tutorial now

4. We should probably change the failure mode for out-of-address-space failures

Show
Steve Blackburn added a comment - Thomas, Your immediate problem should have been fixed by r15632. Please follow up if there is still a problem. The problem was that in the generational collector, the nursery is by default limited to a fixed amount of virtual memory. If an object does not fit in this space, allocation fails with an out of memory error. I have fixed things now so that any such allocation will go to the large object space. I'm not closing this yet, because I still have a handful of followups: 1. The heapgrowth manager needs to be fixed, as per my previous note. 2. We probably should re-explore discontiguous nurseries (it is all there, just a matter of flipping a boolean) 3. We need to update the MMTk tutorial now 4. We should probably change the failure mode for out-of-address-space failures
Hide
Permalink
Thomas Preud'homme added a comment -

I've just tested r15632 and it works indeed perfectly well.

Thanks for the fix, it was very quick.

Show
Thomas Preud'homme added a comment - I've just tested r15632 and it works indeed perfectly well. Thanks for the fix, it was very quick.
Hide
Permalink
Steve Blackburn added a comment -

I just updated the tutorial and Daniel has a bunch of refactoring in-flight which among other things changes the handling of OOMs.

Show
Steve Blackburn added a comment - I just updated the tutorial and Daniel has a bunch of refactoring in-flight which among other things changes the handling of OOMs.
Hide
Permalink
David Grove added a comment -

Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.

Show
David Grove added a comment - Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.
Hide
Permalink
Steve Blackburn added a comment -

Each of the three residual issues arising from this entry are subsumed by other issues. The specific problem that lead to this JIRA was fixed, as noted above.

Show
Steve Blackburn added a comment - Each of the three residual issues arising from this entry are subsumed by other issues. The specific problem that lead to this JIRA was fixed, as noted above.

People

  • Assignee:
    Steve Blackburn
    Reporter:
    Thomas Preud'homme
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: