[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Brad Davis commented on ISPN-863: --------------------------------- I would agree with Robert; I think the best solution is the Instrumentation solution. The Instrumentation solution seems much less expensive than serialization and reflection to me. Although, if you have a write behind cache enabled that is already serializing, I could see then trying to leverage the size assuming the write behind has APIs to do so. Reflection seems way too expensive. It also seems that this wouldn't really need to "kick into gear" unless the JVM heap size is running "low". Maybe consider making the eviction policy something that kicks in when the heap begins to consume a configurable portion of heap. One idea is to have the cache heap size calculated as a background non-blocking thread, where the heap does not affect "puts" to the cache unless the heap is already running low. If the heap is running low, we switch to "agressive eviction" mode, which blocks writes to the cache until the point that the heap-to-available memory threshold clears. Just thinking out loud. Does anyone know if getObjectSize actually already transverses sub-objects? http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumenta... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira