Jerry wrote:
>I'm wondering if it is actually the shared archive building thing which is
>happening and something is broken in the code which determines that the
>archive needs building. It's supposed to be built once per Java install,
>but maybe it's being built once per boot instead. I'd definitely try and
>run Shark or Sampler to see if there are any clues in the VM native code
>profiling and also run fs_usage to see if the archive is being written to
>and not just read from.
Yup, if the disk is being hogged for some reason, then class-loading will
be drastically slowed. At this point, the first thing to figure out is
where the time is spent. We don't yet know where that is. Once we know
where, we can narrow down exactly what, then why.
Activity Monitor shows disk activity and is simple to use. If it shows
heavy disk activity, then follow up with fs_usage (see 'man fs_usage' and
'man sudo') to narrow down the file. But if disk activity is normal, then
fs_usage just generates a lot of output that reveals little.
These reported elapsed times are just insane:
real 0m59.110s
user 0m0.101s
sys 0m0.152s
real 0m45.576s
user 0m0.205s
sys 0m0.120s
When I've seen disparities like this before, it usually involves swapping
or other disk-hogging. Runaway network traffic might also cause this, but
'java -version' does no networking, so I doubt it. Or is this machine
sharing files?
The posted profile data points a finger at ClassLoader.loadClass(), but
that's all I can see. Unfortunately, the data doesn't illuminate where the
real time is being spent. However, a simpler real-time profile might:
java -Xprof -version
It emits a profile to stdout when the program ends. Its profile is
measured in ticks, which are real-time sample events (100 ticks/sec, as I
recall). If the disk is slow, then huge tracts of real time will be spent
in a small number of file-related classes or in loadClass(). If something
else is slow, then time accrues there.
Be sure to watch Disk Activity in Activity Monitor while the command is
running, to get a sense of the overall system behavior. Context is crucial.
Are there any third-party extensions, kext's, or other additions on this
slow machine, or is it a stock standard OS install?
Is this a brand-new machine, which Spotlight might still be doing a
full-scale indexing on?
If it's not brand new, how long has this problem been happening? The
original post just says "I noticed...".
Double-check that Energy Saver isn't set to a short disk-sleep period.
It's unlikely, but conceivable.
-- 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
