An implementation of the Java platform may optionally support
the creation of direct byte buffers from native code via JNI.
If an instance of one of these kinds of buffers refers to an
inaccessible region of memory then an attempt to access that
region will not change the buffer's content and will cause an
unspecified exception to be thrown either at the time of the
access or at some later time.
A direct byte buffer may be created by invoking the allocateDirect factory method of this class. The buffers returned by this method typically have somewhat higher allocation and deallocation costs than non-direct buffers. The contents of direct buffers may reside outside of the normal garbage-collected heap, and so their impact upon the memory footprint of an application might not be obvious. It is therefore recommended that direct buffers be allocated primarily for large, long-lived buffers that are subject to the underlying system's native I/O operations. In general it is best to allocate direct buffers only when they yield a measureable gain in program performance.
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
it's the only way to really achieve the "consume no cycles" requirement for locking.
I also could use a single shared buffer for reads, since that's done only once at startup, by a single thread - so protecting the buffer would be trivial.
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
Don't get me started about those stupid light bulbs. |