Java (6u21) DTrace Probleme

Es gibt ein Performance-Problem, wenn Programme eigene DTrace-Provider (?) bereitstellen. Diese werden beim Starten
des Programms bzw. beim Laden einer Library von ld.so.1 in den Kernel geladen.
Bei Java befinden sich die DTrace-Teile in /usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libjvm.so. Generell sind diese im sog. DOF
(DTrace Object Format) in einem ELF-File gespeichert, in einer Section “.SUNW_dof”. Z.B. in der libjvm.so:

Section Header[16]:  sh_name: .SUNW_dof
    sh_addr:      0x9f9dc0        sh_flags:   [ SHF_ALLOC ]
    sh_size:      0x22997         sh_type:    [ SHT_SUNW_dof ]
    sh_offset:    0x9f9dc0        sh_entsize: 0
    sh_link:      0               sh_info:    0
    sh_addralign: 0x8

Wird so eine Library geladen, wird über ld.so.1 /dev/dtrace/helper geöffnet und mit einem ioctl() das DOF in den Kernel geladen. Hier
unterscheiden sich AP4S100 und AP4A100. Mit dtrace habe ich die Dauer des ioctl() gemessen:

ROOT@AP4A100 > /export/home/u2044963/dtrace/java.d
tracing...
open: /dev/dtrace/helper
ioctl: request: 1685350403, 0x64746803
ioctl duration: 677ms
strcmp_time: 189 ms
strcmp count: 143652
ROOT@AP4S100 > /export/home/u2044963/dtrace/java.d
tracing...
open: /dev/dtrace/helper
ioctl: request: 1685350403, 0x64746803
ioctl duration: 35704ms
strcmp_time: 11161 ms
strcmp count: 7901263

Während des ioctl() wird auf der AP4S100 relativ häufig vom DTrace-Kernelmodul die Funktion strcmp() aufgerufen; die entsprechenden Werte
unterscheiden sich bei beiden Systemen doch relativ deutlich. (strcmp() ist nicht direkt für die Probleme verantwortlich, das wäre zu einfach.
Interessant wäre es zu wissen, warum die Funktion so häufig aufgerufen wird.)

Weitere dtrace-Scripte zum Thema liegen auf AP4S100 im Verzeichnis /export/home/u2044963/dtrace/

Da die Binaries und Libraries auf beiden Systemen identisch sind, muss der Unterschied im laufenden Kernel liegen. So richtig
bin ich dort aber nicht fündig geworden, erschwerend kommt hinzu, dass sich die dtrace-Module im Kernel nicht mit dtrace
beobachten lassen.
Ein Unterschied der beiden Kernel scheint die Anzahl der fasttrap-Probes zu sein:

AP4S100: 
> fasttrap_total ::print -t
uint32_t 0x4af0
AP4A100
> fasttrap_total ::print -t
uint32_t 0x2892

Um dieses Problem auch bei einem Neustart zu umgehen wurde folgender Eintrag in die /etc/init.d/ivascntl.sh Skripte von ivas01 und ivas02 geschrieben:

DTRACE_DOF_INIT_DISABLE=1
export DTRACE_DOF_INIT_DISABLE

Als Workaround kann die Environment-Variable DTRACE_DOF_INIT_DISABLE gesetzt werden. Dadurch wird das DOF nicht in den
Kernel geladen.
Ab Java-Version 6u22 ist die Library so kompiliert, dass die DTrace-Probes per lazy-loading nachgeladen werden. Die Probes gelangen
also nicht schon beim Start in den Kernel, sondern erst dann, wenn sie tatsächlich benötigt werden.

Bug 6974813: JVM needs to use demand loading for its DTrace probes
Release Fixed 6u22-rev(b06)

Bei der Gelegenheit könnte auch folgender Bug überprüft werden, bei C++-Programmen könnten die Probleme ebenfalls auftreten:
Bug 6815915: libCrun.so.1 needs to use demand loading for its DTrace probes

Umgesetzt auf den div. AP4S100-Zonen sowie AP4A115 ist im Moment der Workaround mit DTRACE_DOF_INIT_DISABLE