Large and long lived objects, heap vs. NIO?

Question

Hi,
Our application keeps large number of objects in cache (based on Oracle Coherence) and objects are related to subscriber information which means they are supposed to stay in cache for very long time.
The heap size we are looking at is about 3+ GB and probably the majority of the heap will be used to hold the cached objects. Is there anyway to let JRockit GC know about the 'cache' concept so it won't spend too much effort on these 'cached' objects?
Any JRockit tuning tips for this kind of application?
Is NIO a better approach means use the NIO to hold the cache objects rather than heap?
But every NIOed object also consumes some heap (create Java object) at least in the Sun HotSpot implementation, not sure what is the trade-off. What is JRockit standing point on NIO given its superior GC to Sun HotSpot, because JRockit's 'guaranteed pausetime' and be able to large heap size at the same time?
NIO seems to allow go beyond the traditional problem long pause concern when heap size is large.
Our application is supposed to handle at least several hundred GB in distributed configuration (cluster based on Oracle Coherence).
Is this thing JRockit may or may not have advantage/disadvantage?
We heard about 'distributed GC' in distributed environement meaning the dependency on other JVM may cause one local GC to depend on the remote GC on the remote node if GC happens at the same time on different nodes. Any thought from JRockit perspective?
Regards,
Jasper

Answer 1

Thanks a lot, Stefan
I appreciate the extra miles you went beyond just the JRockit...
One clarification in my original question, actually I mean a large number of objects rather than large-sized object. The objects range from 50 bytes to a few kb and the total number of objects are lilley in several millions.
We have been testing Heap vs. NIO based on Sun JVM.
But we are not able to see clear advantages one over the other at this point.
-Using NIO does use less heap but the overall process memory between HEAP and NIO is not much different in our case.
-Our original thinking to use NIO is because we want to cache more than 2+GB of objects per JVM so we can make good use of standard server configurations (8/16 cores 32/64G RAM) without huge number of JVMs. We're targeting 100+ million subscribers in the telecom space. The 2 GB is basically the limit that normal GC (HotSpot) probably can handle without causing long pause, otherwise it will break our SLA (latency requirement is in the ranage of milliseconds).
-From reading the HotSpot JVM, it turns out using NIO is not totally HEAP-free meaning, additional book-keeping for the NIO resident objects are created in the form of Java objects which consumes heap too. So GC is not totally immuned. Also there are some more overheads in handling the NIO objects (create/delete) via the JNI calls.
-Even though we are not using NIO directly, we use Coherence and Coherence provides the HEAP and NIO options for the cached objects, but ultimately it's up to JVM. Therefore I try to bring this up with JRockit. I think the NIO size limit is probably due to one direct memory allocation can be up to 'int' can cover, but if one allocation call is not big enough, multiple allocation calls should do (probably more complex/effort...). But 'int' is up to 4GB and is already good enough in our case for a JVM caching objects in NIO.
-Our ultimate decision is based on TCO, low CPU/memory with high throughput and low latency meet the SLAs.
We will come back to share our test results based on JRockit RealTime later and may ask for more of your insights then.
Best Regards,
Jasper