Timothy Wall wrote:
>once I narrowed down the suspect block of C code, I could properly
>instrument (using clock() was sufficient, given the delays I was
>seeing). turns out the allocation of memory for the instruction
>block (malloc) was asking for over 1G of memory due to a bug in an
>assembler-generated constant. The OS was providing it (!), although
>it took a while to do so.
Ouch.
You can sometimes narrow down gross misbehaviors using Activity
Monitor.app. It almost certainly would have shown the consumption of the
unexpected 1GB+ of memory, and that would have been a big clue. There'd be
another clue in the System Memory pane: Page ins/outs.
When virtual memory kicks in, it can kill performance, and Page ins/outs
shows cumulative counts of page-ins and page-outs. This is very handy for
getting a big picture, even if you don't know exactly what's causing
paging, and even if there are no page-outs. The system will abandon
read-only pages it can page-in, e.g. code, in order to get RAM space. It
will generally do this before paging-out, because a page-in takes only a
read, while a page-out takes a write and a read.
-- 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
