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] | |
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] |