🚀 go-pugleaf

Mike Manning wrote:
> 
> While researching an OutOfMemoryException, when all appearances are that
> there is memory available, I discovered that several others have had
> this problem.

[...]

I've changed test a bit to print only once per 100 entries to make it
run faster.

[...]
DATA: 0% free  total = 4128768 free = 7840 count = 110000
DATA: 0% free  total = 4128768 free = 5320 count = 110100
DATA: 0% free  total = 4128768 free = 2800 count = 110200
Caught java.lang.OutOfMemoryError
null
java.lang.OutOfMemoryError
        <<no stack trace available>>
FAILED: 0% free  total = 4128768 free = 280 count = 110300

This is under JDK1.3


Under JDK1.2 + hotspot program tries to gc desperately, almost stopping
program at
DATA: 3% free  total = 4063232 free = 131552 count = 113300
DATA: 3% free  total = 4063232 free = 131200 count = 113400
DATA: 3% free  total = 4063232 free = 130192 count = 113500
DATA: 3% free  total = 4063232 free = 128592 count = 113600

which is bad, but distant from 37% you were talking about.


Under JDK1.2 classic

DATA: 8% free  total = 4194296 free = 344016 count = 101600
DATA: 8% free  total = 4194296 free = 341968 count = 101700
DATA: 8% free  total = 4194296 free = 345424 count = 101800
Caught java.lang.OutOfMemoryError
null
java.lang.OutOfMemoryError
FAILED: 8% free  total = 4194296 free = 343848 count = 101900

Worst of all, still 8% is more acceptable than 37%. I've run all
programs for 500000 iterations, I'm not sure if it makes a difference.

Note that this program is quite syntetic - in classic vm a lot of memory
will be used in handles, not object data. Maybe they have some problems
with such number of handles. Anyway, under both hotspots, outcome is
quite good I think.

Artur