William Groppe wrote:
>The performance is better then the original machine, but still swings
>wildly. Plus the fact that there is a full 4 second GC pass.
I've done more testing, and I believe I have an explanation.
--Conditions and Configuration--
I configured my 500 MHz dual-G4 (1 GB real RAM) for 1 CPU and 256 MB RAM,
then rebooted:
sudo nvram boot-args="cpus=1 maxmem=256"
I created 100 test-files of exactly 2 MB each, using my earlier program
FileMake. These were the only tested data-set.
I started Activity Monitor.app, and set it to display Disk Activity, at 1
sec intervals.
Then I ran both my "improved" FileIO test, and the original RawIOBenchmark
test. Verbose GC was always enabled.
Over the course of multiple test runs, I used different heap-sizes, always
given as identical -Xmx and -Xms values. Heap-sizes tested were 32m, 64m,
and 128m (megabytes).
Tests were run on Mac OS X versions 10.3.5 and 10.4.2. Behavior was
similar, though noticeably worse on 10.4.2, probably due to the OS
consuming more of the limited RAM capacity.
--Tests and Analysis--
The FileIO program never triggered GC, even when run with a 32 MB heap.
The reported read speeds varied from about 10 to about 30 MB/s. Activity
Monitor showed lots of reading, but no disk writes.
There was a pattern of files periodically reading slower, about 200 ms vs.
the typical 70-90 ms. This turned out to be due to Activity Monitor's
sampling activity. When Activity Monitor wasn't running, there were no
elapsed times exceeding 100 ms in any FileIO run.
Analysis of FileIO's behavior -- The limited physical RAM means limited
disk-cache space, so none of the files are staying in cache (100 files * 2
MB = 200 MB), and subsequent runs of the same program on the same files
re-reads them from disk. Therefore, speed is primarily determined by the
disk speed. Variability can arise due to rotational latency, seek latency,
and uncontrollable non-contiguous disk-allocation (where the file
physically resides on the disk).
There was a measurable competition for resources with Activity Monitor.
It's unclear whether this was solely for CPU, or for disk-reading, or what.
(Remember this was all on a single 500 MHz G4 CPU, with an old video card
incapable of Q2DX.)
The RawIOBenchmark with a 128 MB heap triggered a similar GC as William
described for the 256 MB Mac mini, and the problem was repeatable. There
was also a similar (and repeatable) slow-down in read speed appearing well
before the GC itself occurred. Activity Monitor showed substantial
disk-write activity coincident with the onset of reported disk-read
slowdowns from the test app.
When RawIOBenchmark was run with a 64 MB heap, GC was triggered 3 times
over the course of the 100 files. However, there was no pre-GC onset of
file-read slowdown. The range of elapsed times was fairly uniform, though
scattered over the range of about 60-200 ms, strongly weighted in the range
of 70-100 ms for all 2 MB files. This range was similar to the range of
times exhibited by the earlier FileIO test, which exhibited no GCs at all
over the same 100 files. (The same pattern of 200 ms times coincident with
Activity Monitor's update was also evident.)
Analysis of RawIOBenchmark's behavior -- With a 64 MB heap, the file-read
performance is similar to FileIO. RawIOBenchmark, however, triggers
several GCs because it's reading each file into a new buffer, which it then
discards, and must eventually reclaim in a GC. Nevertheless, the measured
file-read performance is roughly on par with the more memory-frugal FileIO
test.
With a 128 MB heap, however, RawIOBenchmark is a very different beast. The
pre-GC onset of file-read slowdowns is coincident with disk-writes
appearing in Activity Monitor. Yet no apps are overtly writing to disk.
Therefore this is almost certainly disk-swapping of RawIOBenchmark itself.
As soon as RawIOBenchmark starts contending with itself for disk-access,
performance goes to hell in a hand-basket. When a GC is finally triggered,
all the swapped-out memory must then be swapped in, run through the GC
pass, and rearranged in a newly reduced heap. Swapping then continues
apace, as additional files are read into buffers and discarded. So once
swapping occurs, the program never really recovers, and the measured
file-read figures remain dismal, because the program continues competing
with itself for disk-access. The competition occurs at two different
levels: the overt or apparent level is the file-read test, the covert or
virtual level is disk-swapping.
--Summary--
The short explanation is that RawIOBenchmark is squandering a scarce
resource, memory, which eventually causes swapping, which then competes
with what RawIOBenchmark is supposed to be measuring: disk speed. The
measurement process ends up interfering with the thing being measured.
Whether this interference also occurs (overt reads vs. swapping) in the
original program of interest (the one with 100 KB image-files on disk) is
unknown. One would have to measure the original program in a meaningful
way, to find out what it's really doing.
Giving a Java app a large heap (e.g. 128 MB) doesn't mean that it actually
gets that entire amount of memory available at once. Acting as if it does
may lead to surprises when the app does not take measures to limit the
frequency with which memory must be reclaimed. Memory is not unlimited,
and large heaps aren't necessarily huge tracts of unfettered space.
Swapping can occur on machines with limited physical memory.
I'll close by saying that I ran similar ranges of tests with maxmem=512,
and there was no swapping even with 128 MB heaps. So upgrading the Mac
mini to 512 MB of physical RAM would change the program and file-read
behavior substantially, most likely for the better. Whether it will also
solve the problem in the original program where images were cached in
disk-files, I can't begin to guess.
--References--
Disabling a CPU on a Multi-CPU System:
<http://developer.apple.com/qa/qa2001/qa1141.html>
Reducing the Size of Physical Memory in Open Firmware:
<http://developer.apple.com/qa/qa2001/qa1099.html>
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
