[???] GC can't keep up while the game is paused

[Enjay]

It would be better if someone more clued in than me had a double-check of this, but I think that the fix from this thread: viewtopic.php?f=7&t=73426 also addresses this issue. At least, running my test file with "stat gc" enabled indicated to me that the garbage collector was keeping up.

[drfrag]

For me this problem still exist with RRWM. The ram usage goes higher and higher until you alert the monsters, and then happens again in the menu or pausing the game.
I haven't tried with the PDA but it would be the same AFAIK.

[Graf Zahl]

What does 'stat gc' say?

[drfrag]

That's not logged, it says sweep and alloc and thresh keep increasing very fast right after starting.

[Enjay]

Strange, with a paused PDA (as can be seen from the non-moving imp) in versions prior to today's build, I would get a crash (separate issue) and the GC stats would just keep rising. However, with today's build, that no longer happens.

I take it this is how the GC stats are meant to look?

But, yes, if I load RRWM ( viewtopic.php?f=43&t=63619 ) I too see the GC stats rising and rising just by starting a game and standing at the player start spot in map01 with stat gc running.

[drfrag]

They decrease when you fire a shot but if you pause the game it happens again. Are you sure that you are pausing the game in the PDA?

[Enjay]

Well that imp and his fireball are not moving.

[drfrag]

Yeah it's fixed with Nash's PDA starter kit but not with RRWM.

[Player701]

I went through the other report and noticed that Graf mentions Shape2D there. RRWM does not use that particular API so the two issues are probably unrelated. What it does is create a lot of small objects every time the UI is rendered, but these objects do not contain any native references, most of them have only a few scalar fields or vectors and not much else.

I wanted to convert these small objects to structs but unexpectedly ran into this issue, so I'm not sure what I should do at this point (besides, the structs themselves seem to behave somewhat weirdly, and the code that works with them does not look very nice, at least not to me). What I can say for sure is that I've done a lot of playthroughs with RRWM and I've yet to see GZDoom crash due to memory issues. So it's probably manageable as long as the game is not kept idle for a long enough time. Still, would love to see this addressed one day, one way or another.

[Enjay]

It's really quite strange how this manifests. You don't even have to pause the game. Start a game and do nothing and the gc stas will rise and rise. Fire a shot and engage the enemies at the start of MAP01 and the gc kicks in.

However, once you've cleared that initial fight, the stats start rising again - no need to pause. Go into the side room with the platforms and armour secret and the fight brings the stats back down again.

And it's not just that the enemies are awake. One of the zombies on the platform in the final big room was awake but all I had to do was get out of his line of sight and the stats started climbing. Standing squarely in his view (even with god mode on, to ensure that it wasn't something I was doing, or my HUD changing or something) and just letting the zombie see and attack me allowed the gc to kick in and being the stats down again.

[drfrag]

Yeah there's a problem if you pause the game and leave, it's addressed in LZDoom with the change i mentioned earlier. But that's not optimal and i guess Graf is getting very close to a solution.

[Graf Zahl]

This mod seems to allocate new objects this frequently that the GC is unable to keep up.In the time it needs to perform a collection cycle the UI allocates more new stuff than it can clean up. It gets stuck in the propagate stage due to the heavy stress it's being put under.

It's solely the HUD. When enabling the Alt HUD allocations are well behaved.

Gonna have to check closer what makes it go off the rails this badly.

[Enjay]

Yeah there's a problem if you pause the game and leave, it's addressed in LZDoom with the change i mentioned earlier. But that's not optimal and i guess Graf is getting very close to a solution.

Oh, yes, pausing causes the stats to climb, for sure. Sorry, I didn't mean to imply otherwise. I was just saying that you don't have to pause for that to happen, merely getting out of the way of active enemies with RRWM loaded will do it.

Start map01, watch the stats rise, fire a shot and the enemies engaging - i.e actually firing (at least that seems to be the trigger (no pun intended)) will make the stats fall. All you have to do is sidestep to where the chainsaw is without killing any bad guys and the stats will rise again.

[drfrag]

I know but i was mainly responding to Player701, when people leave usually they pause the game and if you keep the computer unattended with that shit going on that could be a major problem.

[Graf Zahl]

Oh my, this mod is creating roughly 4000(!!!) layout objects per frame! It occasionally skips a frame but that only seem to be frame drops where the HUD is not being rendered for a tick.
It seems to create a huge OOP-based layout hierarchy and instead of caching it recreates it EACH! SINGLE! TIME! it gets rendered.

I'm sure if this was Java it would start to choke under the constant GC stress as well. It's simply not how a garbage collected language can be used. They occasionally need some time to take down all the trash, but here it continues with this insanity while the GC helplessly tries to catch up, never managing.

TBH, code like this is what gives OOP a bad name.
This code is so extremely scattered into micro-methods that I have no clue where even to look for a start of this all.
I'm sorry, but in this case my only response is "Fix the mod!"
There has to be some means to detect whether the most recent layout is still valid or not so that it won't have to be recreated over and over and over again in its entirety.