-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GC] GCSetMode() only a stub, Garbage Collection on Windows vs Linux #251
Comments
I extended the sample so it creates a third block of 100MB ... and now it also frees the memory of the blocks (blocks2) created after This means objects created after "GCSuspend()" seem still properly managed. This makes me wonder now - why the memory usage in my game stays "high" on Windows but can get lowered properly on Linux. |
In my game : download current code from github.com/TVTower/TVTower
Append:
Compile TVTower.bmx (and execute) |
Dunno if it would be useful to have additional GC information at hand: |
For now
GCSuspend()
does not just suspend garbage "collecting", it actually stops the GC overall (it callsGC_Disable()
from bdwgc).GCSetMode()
is not having an implementation -> it just does nothing for now (but is still in the documentation)Now the interesting thing:
When disabling the GC in my game (TVTower) the memory usage increases on Linux and also on Windows. I eg wait for the memory usage (also the one reporty by
GCMemAlloced()
) to raise from eg 150MB to 500 MB (fast forward helps creating a lot of temporary stuff).Now I enable the GC again:
On Linux it takes some seconds to lower memory usage in multiple steps again to about the "original" value. (so from 500 down to around 170 MB)
On Windows it simply keeps at the memory usage where it was before (stays at 500 and slowly increaes with each newly added managed data).
Does this mean it actually collects the objects created after GCSuspend() ? Or does it clean up differently on Linux than on Windows. What I mean is: some object might reference the "non managed" data and once this managed object got out of scope it cleaned the non-managed ones too. On windows the removal might happen in a different kind of "order" and thus making the GC not see the non-managed objects.
I tried to replicate the issue in a separate file ... but it shows consistent behaviour across Windows and Linux:
(In this sample it is not able to also delete the 100mb of "unmanaged" data)
Output:
-> only first 10 blocks'
Delete()
is called as expected-> final GCMemAlloced() states, there is still 100 MB of memory allocated
This means
GCMemAlloced()
reported to still manage (!) around 100 MB of dataIf the GC sees the 100 MB as managed why does it never free it ?
If you moved
blocks1 = New TMemBlock[0]
to happen beforeGCResume()
the GC still frees them properly ( and calls "Delete()" on them, onceGCResume()
was executed)The text was updated successfully, but these errors were encountered: