Should GeneratedColumn and others be garbage collected?

[spauldhaliwal]

I'm running some tests in my app and trying to locate hard to find memory leaks. I notice that if I do an insert with Drift, some classes are added to the heap and never gc'd. So far, I've noticed these:

GeneratedColumn: ~180 instances
VerificationMeta: ~160 instances
DatabaseConnection: ~20 instances

I notice that whether I run 50 inserts or 500, the relative number of instances stays the same, however, they are still never released.

I also notice that when I start the app, connect to the db, but don't do any inserts, GeneratedColumn sits at around ~7 instances.

Shouldn't all of these classes get gc'd once the operations are done, or when the next gc cycle hits?

[simolus3]

Thanks for the report. Drift classes should absolutely be garbage collected when no longer used.

The GeneratedColumn and VerificationMeta instances are used to describe the schema of the database at runtime. I've just checked, and we are exclusively using VerificationMeta as constants - which aren't garbage collected. GeneratedColumns are defined as late final on tables, so they are allocated when they're first used. That explains the few instances before running any queries. But if you have around 160-180 columns across all tables, these instances are all alive (since the alive database object has a reference to every table object, which has a reference to GeneratedColumns). So I wouldn't expect these to get GCed until closing the database either.

The DatabaseConnections seem a little suspicious (or at least I can't come up with an obvious explanation). I'll run some tests myself and get back to you with my findings.

[simolus3]

I just ran the example app from this repository and inspected the instance count from the DevTools memory inspector. It only uses about 10 DatabaseConnection instances, but I think having a little more than that not necessarily unusual if the database is set up across isolates (e.g. with NativeDatabase.createInBackground). Things like LazyDatabase also increment the number, but these are live objects that really are used.

The example app contains functionality to restore databases from a backup, which is a good indicator for memory leaks since it completely re-opens the database. But trying that a few times and looking at the live instance count, I couldn't find anything suspicious.

[spauldhaliwal]

Thanks for looking into it. I found the memory leak, and in this case I wasn't disposing of the database correctly before closing the isolate. It being registered as a singleton inside getit, I had to unregister it after closing the database.

Once that was done, GeneratedColumn and DatabaseConnection were gc'd. The constants and enums remained but I guess that's just a function of them being constants,as you said.

I was wondering if the number of DatabaseConnection connections was a code smell on my end, but it looks like ~10 per isolate is normal, like you mentinoed.