Memory leak when removing Graphic from cache on Hashlink

haxe --version
4.3.3

haxelib list
Warning: Repository requires reformatting. To reformat, run haxelib fixrepo.
flixel: [5.8.0]
format: [3.7.0]
hxcpp: [4.3.2]
hxp: [1.3.0]
lime: 8.1.3 [git] 8.1.3 shows the problem also - I have just tried later versions in search fixes
openfl: [9.3.4]

• Affected targets:
  Hashlink - does not repro on cpp. On cpp you see the regular sawtooth GC behaviour.

Code snippet reproducing the issue:

package;

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.FlxState;
import flixel.graphics.FlxGraphic;
import flixel.text.FlxText;
import flixel.util.FlxColor;
import flixel.util.FlxDestroyUtil;
import openfl.display.BitmapData;

class PlayState extends FlxState
{
	// var msg:FlxText;
	var _allocate:Int;
	var _numDump:Int = 0;

	override public function create()
	{
		super.create();
		FlxG.autoPause = false;
	}

	function _createText():Void
	{
		if (members.length > 0)
		{
			var msg = cast(remove(getFirstAlive()), FlxSprite);
			// msg.kill();
			// FlxG.bitmap.remove(msg.graphic); // leaks
			msg.graphic.decrementUseCount(); // leaks
			// FlxDestroyUtil.destroy(msg.graphic); // crashes  - destroy gets called in all leak cases
			// FlxDestroyUtil.dispose(msg.graphic.bitmap); // OK ok on its own - doesn't touch cache
			// FlxDestroyUtil.destroy(msg.graphic.imageFrame); // crashes
			// msg.destroy(); // leaks
			// msg.graphic = null; // leaks
			// msg = null; // OK - doesn't touch cache
			// Let variable go out of scope and it's ok too. OK - doesn't touch cache
		}
		// var m = new FlxText(250, 250, 200, "Hello");
		var m = new FlxSprite(50, 50);
		// Uncomment the graphic size you want to see impact on the leak.
		m.makeGraphic(100, 100, FlxColor.RED);
		// m.makeGraphic(200, 200, FlxColor.RED);
		// m.makeGraphic(400, 400, FlxColor.RED);
		add(m);
		if (members.length > 1)
		{
			trace('members growing');
		}
                // Verify the cache is not growing
		var cacheCount = 0;
		for (k in @:privateAccess FlxG.bitmap._cache.keys())
		{
			cacheCount++;
		}
		trace('FlxG.bimap._cache size = ${cacheCount}');
	}

	override public function update(elapsed:Float)
	{
		super.update(elapsed);

		if (FlxG.keys.justReleased.A && _allocate == 0)
		{
			// Allocating and freeing here does not leak.
			// The graphic needs to go through rendering to leak it seems.
			// for (i in 1...1000)
			// {
			// 	_createText();
			// }
			_allocate = 1000;
		}

		if (_allocate > 0)
		{
			_createText();
			_allocate--;
		}

		#if hl
		if (FlxG.keys.justReleased.D)
		{
			hl.Gc.major();
			hl.Gc.dumpMemory('hlmemory${_numDump++}.dump');
		}
		#end
	}
}

Observed behavior:
When you hit A it goes through allocating a sprite, making a 100x100 graphic, adding it to the state, rendering it and removing it from the state, decrementing the use count on the graphic so it gets removed from the cache and throwing the sprite away. It does this 1000 times each time you hit A.

On HL on Win 10 the private bytes grows by about 72 MB. If you allow this alloc/dealloc to run indefinitely eventually the program crashes, in my case after allocating about 4.5GB.

Expected behavior:
I would expect the memory to be removed either in the manner of GC leading to a sawtooth memory graph or by immediate deletion by the DLL if the memory is not on the GC heap, which I suspect.

Run the supplied PlayState reproduction on HashLink, using the A key to allocate and remove 1,000 rendered sprites and D to capture GC memory dumps; compare with cpp behavior. Start by tracing FlxG.bitmap._cache, FlxGraphic.decrementUseCount(), and the removal or destruction paths shown in the snippet. Done means repeated allocation no longer causes unbounded private-memory growth after graphics leave the cache.