STDCPP GC?

Monkey Forums/Monkey Programming/STDCPP GC?

nullterm

(Posted 2015) [#1]

Quickie, looking at doing a standalone server for multiplayer (linux hosted) and from looking at the forum, it sounds like STDCPP doesn't garbage collect, is that still true?

Ideally, I'd like to write game logic once in Monkey and have that work both on client and server for simulation and validation.

Is it possible to manually garbage collect like Blitz did prior?

GW_	(Posted 2015) [#2]

Look at the Monkey docs relating to #CPP_GC_MODE.

Pharmhaus

(Posted 2015) [#3]

Quickie, looking at doing a standalone server for multiplayer (linux hosted) and from looking at the forum, it sounds like STDCPP doesn't garbage collect, is that still true?

STDCPP uses a different garbage collector as the default (glfw) one but it has a GC as usual.

Is it possible to manually garbage collect like Blitz did prior?

Since it's not the same GC as in Blitz freeing resources might be delayed even if you null them.
In case you use resources which provide a Discard() method you can try to free resources this may as it is internally implemented and GC unrelated.

nullterm

(Posted 2015) [#4]

Thanks! Did a test...

#CPP_GC_MODE=0

Function Main:Int()
	Local count:Int = 0
	While True
		Print "alloc " + count + " " + count * 4 + "meg"
		Local p:Int[] = New Int[1000000]
		count += 1
	Wend
	Return 0
End

#CPP_GC_MODE=0 (no gc) results in a crash after 2 gigs, clearly hitting the 32bit memory limit.

#CPP_GC_MODE=1 (gc after OnX, doesn't apply to stdcpp) also crashes at 2 gigs.

#CPP_GC_MODE=2 (gc on New) runs fine. Watching in the Task Manager, it hovers between 8meg and 12meg of memory.

So #CPP_GC_MODE=2 is the way to go for stdcpp targets.

ziggy

(Posted 2015) [#5]

Yes, it's explained in documentation. CPP_GC_MODE=1 happens after every OnWhatever (so requires Mojo, and it's after evey OnUpdate, OnRender, etc.) Mode 2 is a regular generational GC for all other kind of tools

ImmutableOctet(SKNG)

(Posted 2015) [#6]

The standard C++ target (STDCPP) uses the exact same garbage collector as any other standard C++ based target (GLFW, GLFW3, and from what I remember, iOS), the only difference is the default mode. The garbage collector works fine these days on STDCPP, but back before V71, garbage collection was not an option. This has changed, and it means you can write your own long-running software without any issues. I for one use that target for language tests, debugging, and of course, dedicated servers. It's a great target, and it's used by Monkey's compiler.

That being said, the garbage collector does not work the same on all targets. Along with the different GC modes for each target, there's also different garbage collectors. For example, the standard Android targets use the system's GC (Dalvik or the new ART platform, depending). The Windows 8/8.1 targets use Microsoft's, which is basically the same as .NET. And of course, the XNA target uses C#'s standard garbage collection (In other words, .NET). There's also Flash, which is generally going to be one of Adobe's implementations. And of course, JavaScript garbage collection is very implementation-oriented. For example, Google's V8's garbage collection is actually pretty nice. That's also system/browser dependent, though. You get the idea; Monkey's underlying GC is target dependent.

The best thing to do is to understand what you're targeting, and to build your program with that as a guideline. In this case, that's STDCPP (C++ Tool), meaning the garbage collector's the standard Monkey implementation, which is quite fast on most systems. I had no major issues using it, even on embedded systems like the Raspberry Pi. If you're planning on running this server of yours on a system with little memory, then you should probably look into the garbage collection settings. You set the mode, but there's also more-advanced settings for Monkey's standard GC if you're interested. The 'CPP_GC_MAX_LOCALS' ('GC_MODE' must be set to 2 for this; I'd also recommend using mode 2 for this kind of application) and 'CPP_GC_TRIGGER' (Number of bytes to allocate in order to trigger collection) preprocessor variables are very useful for limiting memory consumption.

As far as memory models go, I wrote some posts on this thread a little while ago, but that'd be more of an interesting read, than anything else to you. That post was also about standard game-oriented development. Servers running with Monkey's standard GC have fewer problems with more drastic memory environments, and your "time-step" / maximum "garbage footprint" is usually a lot less "fixed" (You don't need to render and update an entire scene in the same way).