Russ Trotter wrote:
The change to use mark&sweep for GC didn't appear to solve the problem
of the choppy audio, but it got me thinking and I ran a "vm_stat" while
dragging the mouse cursor around with eclipse during one of the problem
sessions where the audio is crackly. i noticed that there's a flurry of
page faults as i'm moving the cursor around (usually up to 200 of them)
and I wondered how my VM params are affecting this behavior.
First, I'm surprised you're seeing any page-faults at all, since you said
earlier that there's about 1 GB of free (unused) RAM available. I think
Mac OS X sets aside swap space on disk for each process's VM (virtual
memory, not virtual machine), but I thought it wouldn't use the space until
it actually has to spill pages to disk.
Second, if there are that many page-faults, maybe they're copy-on-write
faults or something that doesn't hit the disk but still requires kernel
intervention, which might then block less urgent actions such as iTunes
reading disk blocks to play music. A flurry of those could murder latency
in iTunes. A solution would require forcing the copy-on-writes to occur
with more opportune timing.
On the other hand, if the page-faults ARE hitting the disk, then that alone
could break up the audio, since you then have a contested disk resource.
Why the disk would be hit at all with 1 GB of free RAM is a mystery to me,
and I would suggest investigating that avenue should evidence support it.
I use the
stock eclipse configuring (the eclipse.ini) with the one modification
where I specify -Xmx512m. I leave the -Xms40m alone.
If you start with a small heap, then the JVM has to grow it many times
before it reaches the max. If you start with a large heap, say half the
max, then it takes a longer time before the JVM has to grow it, and growth
happens fewer times. Growing the heap usually takes more resources (time,
CPU, etc.) than simply rearranging it or doing a GC. Starting bigger may
be worthwhile.
If Eclipse is swapping at all, a GC may have to page in large amounts of
heap just to determine reachability. If the heap contents are rearranged,
then that all has to be swapped out again, too. This has to occur even if
the objects are low-priority or even inactive but reachable at the moment
of GC.
Depending on how the heap is being used, swapping can lead to unrecoverable
thrashing of the VM system competing with GC and with other disk activity.
For example, see:
<http://lists.apple.com/archives/java-dev/2005/Aug/msg00053.html>
I doubt you're in the same boat here with Eclipse, but it's still a useful
illustration of unexpected consequences of heap parameters.
If something like -Xms256m DOES reduce the page-faulting and the choppy
audio, then I think it's worth investigating why pages are faulting at all,
given the phys memory available. vm_stat can distinguish copy-on-write and
other details of paging, so it might help us make better suggestions if you
post some of your results.
-- 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
