Hello, A customer is reporting high memory usage with Derby 10.8 on a Linux machine. Their initial investigation indicates that the classloaders are not getting released because EmbedPreparedStatement40 objects are waiting to be finalized.
They see over 80,000 org/apache/derby/impl/services/reflect/ReflectLoaderJava2 classloaders. These classloaders are awaiting to be finalized. All these classloaders are retained by org.apache.derby.impl.jdbc.EmbedStatement40 @ 0x2aab10800dd0 Finalizable Based on what users have found, they have following question "We found that org.apache.derby.impl.jdbc.EmbedPreparedStatement40 is finalizable which is not a recommended Java programming practice [A] and is delaying the cleanup of classloaders and therefore native memory. Is it possible to change this? The answer is probably "No," but I'm asking just for due diligence if this is a known issue with any workarounds or if future Derby code changes this." If I understand this part of Derby code correctly, I think we do need to have finalize in EmbedPreparedStatement40. There is a related old jira DERBY-3004(Get rid of the finalizer in EmbedResultSet). This jira points out that we had tried to move all of the finalize to EmbedStatement and remove it from EmbedPreparedStatement but it was realized that doing so will only take care of single-use activations(used by EmbedStatement) and not the multi-use activations(used by EmbedPreparedStatement) and because of this, finalize code was left in EmbedPreparedStatement. I think even if we could move finalize code somehow to EmbedStatement, we would probably see EmbedStatement objects waiting to be garbage collected. Also, another jira of interest is DERBY-1201(Perform cleanup actions which require synchronization outside the finalizer). This jira is for client driver but the description of this jira points out that embedded driver's finalize method does not make any synchronized calls which is the right way of coding finalize. Any synchronized calls in finalize method can block the finalizer thread and JVM in turn. Client driver was making synchronized calls in it's finalize method. But may be my interpretation is incorrect. I would like to know if Derby community thinks there is anything we can do to remove the finalize from EmbedPreparedStatement40 and/or EmbedPreparedStatement so it is more readily garbage collected. thanks, Mamta
