Hi Dave, > Prior to 1.5.0_u7 the *Critical* function were used, but for the sake of > 6206933, their use was replaced with data copying.
Thanks a lot for all the feedback, it really helps to understand the reasons why the code is as it is. I also thought about the DirectByteBuffers and I also did not like idea of having the data twice (expecially when keeping in mind that some may compress hundreds of mbs). I still believe that a *Critical*-Solution still could be the best solution - if the only drawback is that it can block other threads and the JVM while running. Does a benchmark exist for this situation? I still have some questions: 1.) Does GetByteArrayRegion also block the JVM/GC? (I assume it has to) 2.) Do the *Critical*-functions have other negative side-impacts except blocking the GC. 3.) If many native threads try to call a *Critical*-function, although the JVM would like to call a GC - does the JVM wait until no threads hold a Critical Refrence - or will it block all threads that plan to enter a Critical-Function, do its GC, and later resume? Because if 1.) does block, 2.) no other side impacts, and 3.) is also true I will try to benchmark and simulate a bit - I can't imagine that it would block any more than GetByteArrayRegion. Thanks a lot and sorry for beeing such a bullhead, lg Clemens
