From reading the various posts in this forum it's clear that puts and gets on some direct buffer types are converted to direct memory access instructions (at least on the server VM), and so don't suffer any JNI overhead. Apparently IntBuffer is accelerated, but ByteBuffer isn't - is that correct? And what about other types - in particular, is FloatBuffer accelerated?

All of the direct buffer classes are optimized. However ByteBuffer has both the heap-based and direct buffer subclasses loaded all the time because the core libraries use heap-based ByteBuffers. This caused calls to ByteBuffer.get() and put() to become virtual calls rather than simple machine instructions. Before Mustang HotSpot wasn't optimizing these virtual calls well, though Mustang should do better. You can generally work around this problem by downcasting your direct ByteBuffers to MappedByteBuffer outside your inner loops and operating only on MappedByteBuffer in your loops.

I'm using FloatBuffers (from ByteBuffer.asFloatBuffer), so I can't downcast to MappedByteBuffer. I'll give Mustang a go and see how fast it is. Does this mean that non-direct FloatBuffers are faster in the meantime?

No, direct FloatBuffers should be very fast. The VertexArrayRange JOGL demo shows that you can get faster-than-C speed out of HotSpot when using direct FloatBuffers due to HotSpot's ability to generate SSE instructions at run time; most x86 executables still target the x87 FPU or have separate SSE and x87 code. Mixing direct and non-direct buffers in your application is discouraged.

Most profilers impose some amount of overhead, though if the profiler is reasonably modern it shouldn't perturb the code generated by HotSpot. The -Xprof flat profiler built in to HotSpot used to be a good low-impact profiler, but in 1.5 its implementation was changed and now it's unusably slow. I think the NetBeans profiler is currently very good. When running under the debugger, all of the code is optimized normally by HotSpot except that in which a breakpoint has been set.

In general. This will become less of an issue going forward, as the server compiler can now perform efficient bimorphic call inlining and as we are heading toward a tiered system, but can currently impact performance-critical code.

On the contrary, there are plenty of commercially available CPU and memory profilers which work just fine. I've personally used JProfiler with good results, and in the past have also successfully used OptimizeIt and a couple of others. It's only HotSpot's built-in (and unspecified) profiler which has this drastic slowdown, though I agree this is a problem which needs to be fixed. For a free memory leak profiler I'd recommend the NetBeans profiler which I think works pretty well.

On the contrary, there are plenty of commercially available CPU and memory profilers which work just fine. I've personally used JProfiler with good results, and in the past have also successfully used OptimizeIt and a couple of others. It's only HotSpot's built-in (and unspecified) profiler which has this drastic slowdown, though I agree this is a problem which needs to be fixed. For a free memory leak profiler I'd recommend the NetBeans profiler which I think works pretty well.

Not criticising you personally, but just to answer some of your points there, which I think are unfairly glossing over some serious issues:

1. Java ethos, platform and tools: you can get it for free. Saying "you have to pay for one of the tools you need to do java development" sits uncomfortably with that. Profiling is a fundamental platform feature: it needs to be available for free.

2. Netbeans profiling of a remote server isn't easy, whereas with -Xprof it was identical to profiling a local app. Getting a *customer* to profile with -Xprof was exceptionally easy; getting them to do it with netbeans? Ouch.

3. Replacing a core tool with an implementation that is only available in Sun's own IDE scares a lot of people. Right or wrong, most people don't use that IDE; can they expect more of the core tools to migrate to this foreign IDE in the future? Will netbeans gradually become the "only" java IDE?

To the best of my knowledge, the Netbeans profiler doesn't use -Xprof, it uses dynamic bytecode instrumentation to insert probe points in subsets of the application. There is a free profiler which ships with the JDK, hprof, which works reasonably well (and better in the current version of Mustang than in previous releases).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org