We did not forbid you from using the data, nor is there anything in our license etc that would stop that. We only recommended against it and warned that it was unsupported and experimental (see my email to you dated Dec 4 2007 for reeferance). Your choice of words here seems to imply something else, but if that’s not the case then we are in agreement.

>Come on it does not take a genius to figure
>out a way to expose counters in a generic
>fashion and still allow you to add and remove
>across releases even fix ones that did not
>work. We do this ourselves today with all our
>counters and meters being dynamic and optional.

I’m glad to hear that you have find a simple and cheap way of doing this in your product. But even if the cost is low it still has to be prioritized against other features and it has not yet popped up to the top of that list for us.

Henrik

What did I say differently. “We didn’t want” == “refused”.

Come on it does not take a genius to figure out a way to expose counters in a generic fashion and still allow you to add and remove across releases even fix ones that did not work. We do this ourselves today with all our counters and meters being dynamic and optional.

I asked for this a few times for this well before you even joined the BEA JRockit team when the team were looking for a tools architect in 2003.

William

Will – this is not an entirely correct statement as you well know. We didn’t want to expose the proprietary counters since the current API was experimental and many of the counters were untested (and didn’t work!). We didn’t want 3rd parties relying on them since that would put us in a situation where we couldn’t change our API without breaking your tools. I told you as much at the time.

Jevgeni – You may want to use nanotime when timing instead of currenttimemillis. It is very cheap on Windows at least.

For really low-level profiling, you may want to look at platform dependent tools like Intel VTune or AMD’s CodeAnalyst. Many of them have Java support.

And if you happen to be an Oracle customer, you can look at JRockit Mission Control. Doesn’t have wall-clock method profiling, but a lot of other goodies and it piggybacks on the JVM hotspot detector etc so no overhead from profiling.

Cheers — Henrik, JRockit team

int PROCESSORS = ManagementFactory.getOperatingSystemMXBean().getAvailableProcessors();
ScheduledExecutorService ses = Executors.newScheduledThreadPool(PROCESSORS);
// or
ScheduledExecutorService ses = Executors.newSingleThreadScheduledExecutor();
// any number of Runnable can be added.
ses.schedule(command, 500, TimeUnit.MILLISECONDS);
ses.scheduleAtFixedRate(command, 500, 500, TimeUnit.MILLISECONDS);

You get green symbols unless you use something like VTune or AMD’s equiv. There you get Java aware profiling supported by counters implemented in the hardware.

Regards,
Kirk

1) You for some reason assume there is one client of the ThreadThingy, there can be arbitrary many.
2) There are no advantages to using a boolean over using an int performance-wise. However with the boolean you might skip the update.

Doesn’t pre work?