problem ?bug? with getThreadCpuTime on Linux 2.6 with NPTL

I don't know, if this is a bug or my misuse of this function.

Strange is, that this code works fine in Windows (I use XP) and does not in Linux (I tried both 2.6.10 and 2.6.14 on Debian with NPTL). It seems, the time measured in Linux is only against one JVM and in Windows within one JVM.

package main;

import java.lang.management.*;

publicclass Main

{

publicstaticvoid main(String[] args)

{

runMonitorThread();

runHeavyThread(Thread.NORM_PRIORITY);

runHeavyThread(Thread.NORM_PRIORITY);

runHeavyThread(Thread.NORM_PRIORITY);

}

publicstaticvoid runHeavyThread(int priority)

{

Thread thread =new HeavyThread();

thread.setPriority(priority);

thread.start();

}

publicstaticvoid runMonitorThread()

{

Thread thread =new MonitorThread();

thread.start();

}

}

class HeavyThreadextends Thread

{

publicvoid run()

{

int cycles = 10000000;

while(true)

{

for(int i = 0; i < cycles; ++i)

{

if(i % (cycles/10) == 0) Thread.yield();

}

System.out.println("ThreadId: "+getId());

}

}

}

class MonitorThreadextends Thread

{

privatefinal ThreadMXBean threadMXBean;

public MonitorThread()

{

threadMXBean = ManagementFactory.getThreadMXBean();

String supported ="JVM: isThreadCpuTimeSupported";

if(threadMXBean.isThreadCpuTimeSupported())

{

supported = supported.concat(" - true.");

threadMXBean.setThreadCpuTimeEnabled(true);

}

else supported = supported.concat(" - FALSE!");

System.out.println(supported);

supported ="JVM: isThreadContentionMonitoringEnabled";

if(threadMXBean.isThreadContentionMonitoringSupported())

{

supported = supported.concat(" - true.");

threadMXBean.setThreadContentionMonitoringEnabled(true);

}

else supported = supported.concat(" - FALSE!");

System.out.println(supported);

}

publicvoid run()

{

int threadId;

long time, meanTime, lastTime = 0, lastNanos = 0, nanos, meanNanos;

// only for testing

threadId = 8;

try

{

while(true)

{

sleep(1000);

time= threadMXBean.getThreadCpuTime(threadId);

meanTime= time - lastTime;

nanos= System.nanoTime();

meanNanos= nanos -lastNanos;

lastTime= time;

lastNanos= nanos;

System.out.println("Thread ID("+threadId+"): "+meanTime);

System.out.println("Nanotime:"+meanNanos);

System.out.println("Ratio:"+( meanTime / (float)meanNanos ));

}

}

catch(Exception exp)

{

exp.printStackTrace();

}

}

}

[5461 byte] By [greea] at [2007-10-2 6:43:28]
# 1

This is bug:

6328462 Linux getCurrentThreadCpuTime() does not match with getThreadCpuTime(currentThread)

It will be fixed in:

- JDK 6.0 (Mustang) build b63

- JDK 1.5.0_07 build b01

The problem is that the HotSpot VM takes the stat info from the file'/proc/$tid/stat'

which is incorrect on Linux kernels 2.6+ with NPTL because this file aggregates

per-process (.vs. per-thread) usage on these kernels.

The file '/proc/self/task/$tid/stat' still has the per-thread usage and must be used instead.

There is also a performance bug:

6200022: JVMTI GetCurrentThreadCpuTime slow on Linux

This bug is about using new Linux posix compliant process clocks (2.6.10) :

http://sources.redhat.com/ml/libc-alpha/2004-10/msg00117.html

It is too late to fix this in Mustang but can be possible in one of the update releases.

Thank you for posting the question!

Serguei

ss45998a at 2007-7-16 13:51:54 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2
Thank you very much and sorry for bothering. I found that 6328462 bug, but I didn't recognize, it is my problem... (the related bug is not in database any more and in 6328462 is not mentioned anything about NPTL or linux >= 2.6.10) and I didn't find that second one (6200022) not at
greea at 2007-7-16 13:51:54 > top of Java-index,Java HotSpot Virtual Machine,Specifications...