IBM VM 1.4.1 -- Allocation failure that doesn't make sense

Thread view:

Andrew Clute - 22 Mar 2004 13:45 GMT

I am using the IBM VM 1.4.1SR1 on a RHEL 3.0 box. I have verbosegc
turned on and I got the following output this morning from the GC:

<AF[5]: Allocation Failure. need 524 bytes, 31726137 ms since last AF>
<AF[5]: managing allocation failure, action=0 (496330792/536869376)>
<GC(612): GC cycle started Mon Mar 22 07:15:56 2004
<GC(612): freed 2213344 bytes, 92% free (498544136/536869376), in 66
ms>
<GC(612): mark: 54 ms, sweep: 12 ms, compact: 0 ms>
<GC(612): refs: soft 4 (age >= 32), weak 175, final 46, phantom 0>
<AF[5]: completed in 68 ms>

If I am reading this correctly, at one point 524 bytes were tried to be
obtained, but there was no contingous block of memory that was 524 bytes
long in a heap that had ~500Megs of free space. Is that correct?

How is it possible that at that time, with ~92% free, that the 8% used
was fractionated so much over the entire heap that 524 bytes couldn't be
found? It looks to me like he VM is saying that after this GC, which
freed up ~22M, that that 22M is really the only workspace the VM has at
that point to allocate new request for memory from.

What am I missing here? Is there something I can do to mimimize this?

as an FYI -- we are using -Xms512m -Xmx1024m

Thanks!

-Andrew

Reply to this Message

Michael Amling - 22 Mar 2004 16:14 GMT

> I am using the IBM VM 1.4.1SR1 on a RHEL 3.0 box. I have verbosegc
> turned on and I got the following output this morning from the GC:
[quoted text clipped - 17 lines]
> freed up ~22M, that that 22M is really the only workspace the VM has at
> that point to allocate new request for memory from.

It was 92% free after gc. Maybe before gc, there were a lot of
allocated but unreachable Objects?

--Mike Amling

Reply to this Message

Andrew Clute - 22 Mar 2004 23:04 GMT

> > I am using the IBM VM 1.4.1SR1 on a RHEL 3.0 box. I have verbosegc
> > turned on and I got the following output this morning from the GC:
[quoted text clipped - 22 lines]
>
> --Mike Amling

Actually, no it was 92% as well before the GC. Look at the line right
before the GC starts:

<AF[5]: managing allocation failure, action=0 (496330792/536869376)>

That is the status of the heap before the GC cycle, and it has
496330792 bytes free, or ~92%!!!!

The GC cycle only freed up 2213344 bytes, and so the next line has the
new total for the heap of 498544136 bytes, which is also ~92%. Which
makes sense, because there isn't much in the heap.

So, it is *really* odd that it was 92% before the GC, but was so
fragmented that it couldn't allocate 524 bytes

Reply to this Message

Ben_ - 26 Mar 2004 18:33 GMT

action=0 ???

I can't find this reason code in "IBM Developer Kit and Runtime Environment,
Java 2 Technology Edition, Version 1.4.1, Service Refresh 1, Diagnostics
Guide" (http://www-106.ibm.com/developerworks/java/jdk/diagnosis/):
"
The number that is associated with action determines the type of garbage
collection that is being done:
action=1 means a preemptive garbage collection cycle.
action=2 means a full allocation failure.
action=3 means that a heap expansion takes place.
action=4 means that all known soft references are cleared.
action=5 means that stealing from the transient heap is done.
action=6 means that free space is very low.
"

Although it's in "Chapter 17. z/OS problem determination", I'd suppose the
list above applies to any platform.

Reply to this Message

IBM VM 1.4.1 -- Allocation failure that doesn't make sense

Free Magazines