On 1 Oct 2011, at 03:42, Maidak Alexander J wrote:
>>> I have a T5240 running Solaris 10u9 (144488-07) and using java "1.6.0_23".
>>> Doing a simple "/bin/java -version" is terribly slow and and takes many
>>> seconds (12-30+). Looking at the startup with truss I see, it hang for
>>> many seconds on:
>>>
>>> open64("/dev/dtrace/helper", O_RDWR) = 3
>>
>> Can you post a snippet of 'truss -d' output surrounding the
>> open64()?
>
> 0.5686 open64("/dev/dtrace/helper", O_RDWR) = 3
> 49.5328 ioctl(3, (('d'<<24)|('t'<<16)|('h'<<8)|3), 0xFFBFEC18) = 0
By default, a library containing a USDT provider will offer the
corresponding DOF, stored in one of its ELF sections, to the
kernel's DTrace framework. It will do so whether or not any of the
probes are to be instrumented; the mechanism involves code
insinuated into the object's _init() during compilation with
'dtrace -G'.
I suspect that you are witnessing libjvm.so supplying the hotspot
provider and the jstack() action. You should be able to confirm
this by running 'pstack' against the process during the time that
it appears to be hanging; you should see this library's _init()
near the top of the stack. I would then be interested in verifying
that the same library is in use on your unaffected machines.
For short-lived processes with a lot of DOF the behaviour
described above may well result in unacceptable performance. The
solution is to regenerate the offending library with dtrace's
(undocumented) "lazyload" option. In the meantime, setting
DTRACE_DOF_INIT_DISABLE, as you have done, has (if I remember
correctly) precisely the same result. Note that deferred loading
of the DOF introduces a subtle change in behaviour for libjvm.so:
the jstack() action won't work unless you attempt to instrument a
pid or USDT probe in the java process.
R
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
