Thread:Talk:RoboRumble/ThreadDeath problem and large amount of skipped turns

This continuation of problem investigation mentioned at Thread:Talk:RoboRumble/Client java version and Thread:Talk:RoboRumble/ThreadDeath problem.

After Skilgannon patch, I can see some useful debugging info. In particular, I added output for the number of skipped turns which triggers ThreadDeath call.

I see that as many as 100 or even more skips are detected. This is when TPS slider at max. Move it to 1000 and everything is handy dandy. Note that 1000 TPS is unrealistic with my CPU constant of 6 ms. I.e. per second I can get 1/0.006 about 170 tics. So the system have no time to go to the idle state in either case. On top of it, 160 skipped turns (times 6ms), i.e. about 1 seconds of inactivity, would be noticeable with a naked eye watching the battle. I see no freeze there. So something does not add up.

Here I need the experts help. I look at the source, and the only timing mechanism I see is that within allocated time the thread must report isSleeping. But I see no time checks anywhere, i.e. no one calls for nanoTime. So how the robocode decides that the timeout is exceeded?

Could it be that java calls to robocode waitSleeping are not done correctly.

Here is one more strange thing. I switched debug=true, than I have about 300*cpuConstant to finish a tic, and I time profiled everything. My time per tic is consistently shorter with debug=true, then with debug=false (default). I know it probabilistic but ... Also, in either case my inner methods never report times exceeding 25mS, which is 5 skipped ticks at most. So how do I end up with 100 skipped tics penalty.

Also, I cannot get to ThreadDeath when I play against HawkOnFire. This is very simple and fast bot, but how does it help my bot to avoid the skipped turn penalty?