Bryan Pendleton wrote:
One thing I don't understand about this code is the line.
int sz = (int)((memUsed + junk.length/2)/junk.length);
Why is it not just memUsed/junk.length?
Also is it likely a jvm bug that we end up with 9 or are we making
wrong assumptions about what the jvm will return for totalMemory() and
freeMemory()?
I'm guessing this is trying to round up.
How about this guess at what the calculation is doing. The coder
was seeing inexact results from the mem calculation, and because
the math is integer knew there was some fudge room. So by adding
junk.length/2 it meant that if the return mem was about + or - 5000
bytes from the "real" answer then the calculated answer would be right.
gc seems to be what most of the google links recommend. Some even have
sleeps to make sure gc gets to do it's work. When we can assume jdk15
then there are some references to using the profiling interfaces to get
"real" sizes from the jvm, though those look pretty complicated and may
cause security manager issues.
It looks like this code expects that:
- on a 32 bit machine, memUsed will be appx 40,000, junk.length will be
10,000
and we will compute sz = 4
- on a 64 bit machine, memUsed will be appx 80,000, junk.length will be
10,000
and we will compute sz = 8
Does it sometimes return 4, and sometimes return 9, all on the same
machine?
I don't think this is likely to be a JVM bug. I think it's more likely
that this code just isn't very robust.
thanks,
bryan
