This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Unexpected OutOfMemoryError...


I have an application that is having some trouble with some allocations
throwing
an OutOfMemory exception when there is enough memory (or at least, it looks
like
there should be).

I attached a test that reproduces the error.

Basically, what the test demonstrates is: we attempt to make an allocation
using
JvNewByteArray(). It fails and throws an OutOfMemoryError exception, but there
is in fact enough memory.

In test_1(), we catch the exception, call System::gc() and try again. It works
and only needs one retry. 
This test proves that there was in fact enough memory. I assumed that when an
allocation was attempted and failed, the allocator would try to free some
memory (run the gc()) and try again. If it fails, throw and exception... It
doesn't look like it is doing it... Isn't that wrong?

In test_2(), we catch the exception and just try again. We DON'T CALL
System::gc() in this test. It manages to recover from the exception most of the
time at the very first retry. But sometimes it needs three retries and
sometimes
four.
This test is just weird. I get the exception, try again without calling
System::gc() and most of the time it works... I don't think there was enough
time for the gc to run between these two calls... What is going on here???

In test_3(), we do the same thing as in test_1() but we with an unrolled loop.
It manages to recover from the exception in the first retry a few times, but
once it fails the first retry, it won't recover.

I have no clue what to make of this :-)... Play around with the test, I think
it
will be easy to understand why I'm puzzled... If someone could take a look and
give me some input, I would be grateful :-)

Basically, our solution for the time being was to call GC_set_max_heap_size()
with 100M. Not very nice, and probably didn't truly solve the problem, just
made it less likely to happen.

Attachment: test_OutOfMemory.rar
Description: application/rar-compressed


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]