Large number of EmbedPreparedStatement40 objects waiting to be finalized

[Mamta Satoor <ms...@gmail.com>]

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