Does ObjectDB create one instance of each entity class on (web app) load ?

ObjectDB: 2.7.1_06

[EDIT: Glassfish4.1.1 or Payara payara-4.1.2-174]

I have been profiling a large web app with the NetBeans 8.2 Profiler.

I can see that exactly one instance of each entity is present in memory, at web app startup, before I've loaded anything, and they won't garbage collect. (I've also checked am not loading any entities using JPA callbacks.)

If I take a heap dump and inspect each instance, each one has a GC root with a  path (from the instance) like:

this > r : UTY > _b : HMP$F > [190] : HMP$F[] > a : HMP > B : TYM > aF(monitor used) : MST

Q: Does ObjectDB for some reason create an instance of each entity (and if so, under what circumstances) ?

I can also see that for Abstract bases of entities it is creating one instance with an instrumented class name. For example, if the abstract entity class is com.example.Common then there is exactly one instance in memory of class objectd.com.example.Common

This is correct. ObjectDB keeps one delegate instance per enhanced entity class (including abstract classes, for which the synthetic concrete subclass is generated) for internal use, including some optimisations.

Thanks for your prompt and clear answer. I am greatly relieved to now understand this fully.

I was scratching my head wondering whether I was inadvertently creating the said instances myself, because I also usually at startup do temporarily create one instance of all entities known to the EntityManager metamodel for caching some oft-used information in an application-wide ReflectionHelper, but it does not keep these referenced, and when I disabled the ReflectionHelper fully, I was surprised to see entities retained in memory.

Luckily, although I have a lot of entity classes, as far as I can tell, the delegate instances are not using too much memory. I use a (mostly) LAZY-only fetch policy across the system. Most of my EJB methods for querying are configurable with a pre-detach loader that "visits" any data and relationships needed for particular views, rather than relying on one-size-fits-all EAGER. This pre-detach loader approach is even more flexible than entity fetch graphs, too.