Weblogic.kernel.Default not using all threads

Question

We are running weblogic 8.1 sp4 on HP Tru64 5.1.
We have an admin server and 3 managed servers in a cluster.
When monitoring the weblogic.kernal.Default execute threads through the weblogic console, threads 0 to 15 have zero total requests, and the user is marked '<WLS Kernal>'. Threads 16 to 24 share the entire workload with thousands of requests shared between them, and have user marked as 'n/a' (when idle).
I have done a thread dump, and threads 0 to 15 just seem to be idle.
This is the case for the admin server, server 1 and server 3. But server 2 actually shows all threads 0 to 24 as sharing the workload, and the user is 'n/a' for all threads.
Is there a reason for this?
Below is a snippet of the thread dump showing a thread that is has user '<WLS Kernel>':
**** ExecuteThread: '3' for queue: 'weblogic.kernel.Default' thread 0x207d8e80 Stack trace:
pc 0x03ff805c2cc8 sp 0x200026ecc00 __hstTransferRegisters (line -1)
pc 0x03ff805b2384 sp 0x200026ecc00 __osTransferContext (line -1)
pc 0x03ff805a3d20 sp 0x200026ecd90 __dspDispatch (line -1)
pc 0x03ff805a309c sp 0x200026ecde0 __cvWaitPrim (line -1)
pc 0x03ff805a0518 sp 0x200026ece80 __pthread_cond_wait (line -1)
pc 0x03ffbff31558 sp 0x200026ecea0 monitor_wait (line 625)
pc 0x03ffbff5ea48 sp 0x200026ecf10 JVM_MonitorWait (line 1037)
pc 0x00003001304c sp 0x200026ecf20 -1: java/lang/Object.wait(J)V
pc 0x0000302047dc sp 0x200026ecfd0 2: java/lang/Object.wait()V
pc 0x000030204784 sp 0x200026ecfe0 8: weblogic/kernel/ExecuteThread.waitForRequest()V
pc 0x0000302044ec sp 0x200026ed000 43: weblogic/kernel/ExecuteThread.run()V
pc 0x03ffbff91b28 sp 0x200026ed030 unpack_and_call (line 100)
pc 0x03ffbff89ca4 sp 0x200026ed040 make_native_call (line 331)
pc 0x03ffbff27bb0 sp 0x200026ed0f0 interpret (line 368)
pc 0x03ffbff36bf0 sp 0x200026ed9d0 jni_call (line 583)
pc 0x03ffbff378d8 sp 0x200026eda60 jni_CallVoidMethodA (line 70)
pc 0x03ffbff37980 sp 0x200026eda90 jni_CallVoidMethod (line 88)
pc 0x03ffbff2ecf4 sp 0x200026edb10 java_thread_start (line 592)
pc 0x03ffbff2e720 sp 0x200026edb30 thread_body (line 460)
pc 0x03ff805cf278 sp 0x200026edc00 __thdBase (line -1)

Answer 1

Grand central dispatch - infancy, not really doing its job, and I don't think apps have to be specifically written for HT, but they do have to not do things that they use to - prevent threads from going to sleep! or be parked.
high usage is not necessarily high efficiency. often the opposite.
Windows 7 seems to be optimized for multi-core thanks to a lot of reworking. Intel wants and knows it isn't possible to hand code, that the hardware has to be smarter, too. But the OS has a job, and right now I don't think it does it properly. Or handle memory.
Gulftown's 12MB cache will help, and over all should be 20% more efficient doing its work.
With dual processors, and it doesn't look like there are two quick path bridges, data shuffling has led to memory thrashing. Use to be page thrashing with not enough memory. Then core thrashing but having the cores, but not integrated (2008 is often touted as being greatest design so far, but it was FOUR dual-cores, 2009 was the first with a processor that really was new design and (native) 4-core.
One core should be owned by the OS so it is always available for its own work and housekeeping.
The iTunes audio bug last year showed how damaging and not to implement code and how a thread could usurp processing and add a high cpu temperature while basically doing nothing, sort of a denial of service attack on the processor - those 80*C temps people had.
All those new technology features under development and not like OpenCL, GCD and even OpenGL are tested, mature but rather 1.0 foundation for the future. A year ahead of readiness.