Memory is not released when the BitmapData reference goes out of scope or is nulled out.

[47rooks]

Describe the bug
BitmapData memory is not released when the BitmapData reference goes out of scope or is nulled out.

To Reproduce
Steps to reproduce the behavior:

Attached is a simple openfl project with a Main and a single PNG which can be compiled and run. It pops up a blank
window. Hit L to load the PNG 40K times into an array. Monitor all this from some OS utility. On windows I used Task Manager
and Microsoft Sysinternals Process Explorer. One the debug trace indicating the load appears in the terminal window. you should
have about 240MB stable private memory. Hit F to deallocate the array storing the references to the bitmapdatas. Wait for GC
to kick in and the memory to drop. It never happens. If you hit L to run another load memory usage just grows again.

Expected behavior
I would expect that when the _bmds array is recreated that all the memory for the BitmapDatas would be released.

OpenFL Targets
I have tested this on HL and CPP. At least in some tests on CPP my original test seemed to show the right behaviour but this
test case does not. However my original testcase was allocating 2.6GB and maybe that triggered the CPP GC, whereas 240 MB is
too small - I don't know though - this is speculation.

Additional context
openfl 9.3.3
lime 8.1.2
haxe 4.3.3
HL 1.14
Windows 10
bitmap-data-leak-hl.zip

[47rooks]

Just increased the count of loads to 400K and tried it on cpp - that allocated 1.9GB. Then I hit F and the memory allocated remained at 1.9GB. I then hit L again to load th 400K images again. This pushed the memory up to 2.0GB only so this looks like it is at least reusing the memory on cpp, or at least mostly so. I tried the same experiment on HL and it went to 1.6GB in the initial load, the stayed there after free. Then L again and it rose to 2.8 GB, which isn't quite double but it's getting close. I did see a small drop in memory at one point as though a dealloc did occur but it wasn't much. I ran another cycle of F/L and private bytes went to about 3.1 before dropping to 2.7 and then continued climbing topping out at 4.0GB.

Makes me wonder if this is a GC tuning issue rather than a true leak but not sure. But whatever it is it's using a lot more memory that it really should.

[Dimensionscape]

Have you tried forcing gc? Memory will not always be reclaimed immediately when the reference is lost.

[47rooks]

I did try it in earlier experiments - hl.Gc.major() made no difference.
I realize that GC is delayed to same extent but I have waited for a considerable length of time and seen no reduction in memory usage. The hxcpp is also delayed but I've seen it be much more responsive that this. That said I would expect the memory to be reused if it wasn't freed but subsequent allocation runs as noted above basically allocate lot of new memory to the process.

It's possible this is a VM GC rather than openfl/lime finalizer but I poked around the a bitmapdata or lime image finalizer and could not see one.