Reduce AI JS runtime size

[Deiz]

Due to each AI creating and storing duplicate data about entities, etc., the default AI js runtime is often too small when running more than one or two AIs (qBot-xp in particular), especially on large maps.

To avoid needless out-of-memory crashes, the AI's runtime size has been increased from 16 MB (default) to 32 MB, which should be adequate for everything up to 3v3 matches.

This is a short-term change intended to keep alpha 11 (and SVN) playable until the shared data implementation is committed and used by qBot and qBot-xp (JuBot isn't really a concern; it's unmaintained and ought to be removed in Alpha 12, anyhow).

[wraitii]

I'm not too sure about qBot using them... Given that it's fairly extensive changes, and already in qBot-xp I know some bugs still remain, I don't think it's safe.

I'm coding the shared stuff along with the technology changes in a common-api-v3, used by qBot-xp while qBot still uses common-api-V2. The plan was to replace qBot with qBot-xp, but since this is still very beta, I think for Alpha 12 we might have to keep both with qBot xp as a default perhaps if I can work on it enough (school restarts tomorrow).

[Deiz]

That'd work, too. It's just that qBot-xp is much tougher than vanilla qBot, so it might be rough to have new players get routinely crushed (which happened with qBot a fair bit too, but now it'd be worse).

If quantumstate is agreeable and qBot-xp gains variable difficulty before alpha 12, I see no reason why it couldn't become the main AI.

[wraitii]

Okay, some more information. The main concern is actually not so much the AIs, they add little overhead beyond the occasional pathfinding (which sadly can't really be helped), particularly under the new shared component I'm working on (see thread).

Memory issue is problematic: AIs get all the non-actor templates (including techs, now), which is a good 4/5/6MB. Add to that all the wrappers and the entity collections, and I'm thinking it easily reaches 8 MB at the start of a game. OOM errors seems bound to happen with the 16 MB default runtime, though 32MB should be more than enough for all cases with optimizations.

The other issue is that it breaks qBot and basically anything before it, so I'll have to implement difficulty settings, at least some basic stuffs.

[wraitii]

Okay, back with some solid information this time.

Running test with my shared version of qBot-xp, the memory used at the beginning of the game is about 5MB. Template information is about 2.7MB (that's the amount of memory used by the AI script when there are no AIs on the map, and it only loads the templates). However, AI memory use slowly goes up with each call to "GetRepresentation", which is kind of needed. The JS architecture is so that this remains unused in the heap, until it is GC (explaining the huge amount of GC in the AI heap).

Now the GC keeps it at about 7Mb for a while in my testing with one AI. However, "maybeGC()" only actually GCs when the AI reaches about 4/5 of the maximum heap size. Ie about 12.5MB if the size is 16MB, about 23MB if it's 32MB.

This would normally not be an issue, but starting a pathfinder requires 2MB of ram (I tested, it's a little more than 2MB per pathfinder.) If two AIs want to path at the same time, which certainly can happen, then it's about 4.5Mb, and then boom, OOM errors if I have only 16 MB total and only 12MB available.

So basically, I'll try in the late game, but I still think 16MB won't make it. Sure AIs could call for a GC before starting a pathfinder, which would help, and AIManager could force the G to run if it reaches over 10MB, so there is a bit more free space. But if 7 AIs try to path at the same time, we're getting over the limit whatever happens. And of course, since the AIManager's memory is initialized before knowing how many players there are, this can't be adapted.

BTW: the OOM errors one can get on maps such as Deep Forest are actually caused by creating too many "events" from entity creation during map creation. If that were disabled, it might helps a lot. Furthermore, maps can call for a GC using RMS.maybeGC() .

[historic_bruno]

Why do the AIs need a JS pathfinder? Wouldn't it be more memory efficient and faster if implemented in C++? BTW this is part of the point of designing the AI API, determining what really needs to be JS and what can be part of the engine. I think I know what you're getting at, which is currently with the old API, AIs don't have enough info about the map to do things like determine best attack route or make decisions based on terrain analysis. But that's partly a flaw in the pathfinder design and partly a flaw in the API.

[historic_bruno]

Also is the above data coming from DumpHeap?

[wraitii]

Coming from DumpHeap, yes. The JS pathfinder was created because the C++ pathfinder isn't really usable right now. I believe Philip's improvements would make it that, though. And I didn't believe it was worth putting it in the API if it was only for temporary uses... Anyway, I'm not going to have time to recreate it in the API/C++ side for the time remaining.

[wraitii]

Okay, per http://www.wildfiregames.com/forum/index.php?showtopic=16721&st=0#entry254700/this I've reduced the heap to 24Mb, I don't believe 16Mb is safe in the long run for now.

I also believe this version is now "possibly committable".

[wraitii]

Last version I'll post for a while. I've asked Quantumstate if he could try to review it sometimes, I recommend it to be tested too, though all errors I've been aware of have been fixed (I may be unaware of some/many). See my different posts for more information. If somebody else wants to give a review a try, and has troubles getting into the code/doesn't understand something, PM me and I'll try to answer as soon as possible.

Committing would fix: #1710, #1577; and would reference #441 and #1520 (mostly fixing this one). (I may have missed a few tickets here and there though).

[leper]

r13225 reduced the AI JS runtime size to 24 MB. Reducing it to 16 MB (default) again depends on the new pathfinder (#1756) exposing some passability information, so that the AIs don't have to do this on their own.

EDIT: r13247 increaded the size to 32 MB again.

[wraitii]

Some update from my part: The AIs currently require 32MB to be any sort of playable (I've had OOM errors on medium maps with 3 Aegis on 24Mb). This is partly caused by the fact that they keep many maps of many things. In particular, the pathfinder requires a few 16-bit map which tend to make it OOM quite easily. I'm hoping the day we get a proper pathfinder, the AI pathfinder will be able to be mostly removed. Otherwise, it might be possible to switch some of these things to the C++ code to avoid hogging up too much ram.

I still do not believe having multiple AIs at 16MB runtime will be possible someday. The fact it needs to load the templates and things like that means it defaults at 5MB. Then it's fairly easy to push it up, and maps are really useful for more advanced AIs (but it's not only maps).

There are however many possibilities to improve this (I won't have time to do this in these holidays, I think). Some maps could be switched to 8-bit (might do a few of those), there are probably many things that are somewhat leaky/that the GC doesn't collect because a reference still exists when that reference could be long gone. Using the JS debugger could now help with working on that to some extent.

Finally, I think this should be backlogged for the time being.

(I forgot: this is linked to how we GC too. The GC should be called on frames where the simulation is not run.)

[Stan]

Mimo is it still relevant ?

[historic_bruno]

I'm pretty sure the AI no longer has a separate runtime, so while memory usage is a general concern, this ticket is invalid now.