Ahh… mea culpa. I did indeed misread that.
Sorry Uran, I think something may have gotten lost in the tone of my post; I don’t think you’re lying at all, I just didn’t think you’d quite divulged all the pertinent information. The picture is a little clearer now but I still believe that if you are calling OpenGL 70 times to render a single thing you could be doing it better.
You might for example run it in 1.4.2 and show us the output of -Xprof, which shows the amount of time spent in stubs and native code for JNI calls. If it turns out you were calling glVertex3f 70 times per object you’d be rightly accused of abusing the OpenGL binding, but on the other hand you were actually managing to make 70 client-side state changes per object then I’d stand corrected.
Cas 
I can’t see how anyone could do a serious app with only 70 calls per frame anyway! Even if so, then there’s some very significant ways the rendering can be sped up. With that few calls, it sounds like all of your geometry is in one big array, which means there’s no culling, state sorting or any other very significant ways of speeding up the rendering process.
That said, Uran, you’ve gone about this completely the wrong way. You think that multithreaded access is the problem, when it isn’t. It’s the way you’ve designed your code. Anyone that has multithreaded access to a data structure and doesn’t protect it by either running mutliple buffers (the one being filled versus the one being rendered) or some form of mutex system doesn’t know how to code multithreaded applications. It’s the classic simple producer-consumer problem. How do you expect native code to solve this problem by shifting to native code? You haven’t solved anything at all, just shifted the failure point into a different set of code and it appears fixed because right now something else is slowing the system down or the timing is marginally different such that the problem is not currently evident due to platform-specific behaviour. What happens when you shift this code to a different machine with marginally different architecture - for example a dual core or slightly faster CPU? Those multithreaded crashes are going to come right back at you with even a bigger vengence than the mild ones you’ve got now. With native code you’re simply not going to know what crashed. At least keeping it in Java will have some nicely readable stack traces etc. You’d be far, far better off properly architecting the code first and then worrying about performance later. This seems to be very much a case of the tradesman blaming his tools.
Kaffiene; The one place that this could slow down is the writing to the NIOBuffers themselves. If there’s thousands of put() calls each with a single byte/float/etc then this will have an effect on the performance relative to a bulk put(). But, agreed, there’s no way possible that the GL calls are actually the cause of the significant slowdown. There’s something else in the way he’s coded the app that is causing the issue.
Ok, while I appreciate the helpful comments, I will say that aside from Ken, nobody seems to have grasped the situation. No worries though, heh, initially I wasn’t even going to spill anything since I’m doing quite allright when it comes to optimizations.
Anywho, thanks anyways.
EDIT:
No worries.
Again, 70 calls per object. Thas one, secondly, what you perceive to be a problem of “shifting a problem to native code” is not the case. As for thread synchronization, where it is required, it is in place, it goes without saying.
And finally, subset of this project’s capabilities are targeted at low-end hardware, while dual CPU is one of the multiple arch on which this system is being developed/tested. Oh, one more thing … there are places where producer/consumer paradigm is warranted, and used. There are places where synchronized version of this paradigm is not warranted, and there are many ways to perform synchronization without using explicit sync primitives. Doug Lea’s book Concurrent Programming in Java 2nd Edition is a good read.
Also, as for blaming my tools? Heh, hardly, I brag about having the best tools in the industry.