Dwarden confirmed as much recently. Last I read it's not advised to use any malloc but BIS's.

@nateberkopec Committed memory != virtual memory in Windows. Virtual memory has addresses, that's the entire point of virtual memory - to create the address space.

Task Manager in Windows Server 2012 and Windows 8 :
Committed Committed memory is the physical memory in use for which space has been reserved in the paging file should it need to be written to disk.

“Not true - if you have no paging file you still have committed memory - committed virtual memory is private, nonshareable virtual memory created by processes or the OS or drives that MAY need to be paged out. This always starts out in RAM and *may* get paged out if necessary. So committed memory can be backed by RAM (and if you have no paging file, it remains in RAM until the VM is deleted such as at process exit).

Even if you have a paging file, space is not reserved for this until such time as it actually DOES get paged out. What Windows *does* make sure is that it doesn’t overcommit meaning private virtual memory allocations are charged against the commit LIMIT (sum of RAM + paging files though the current commit limit shown in Task Manager or other tools is based on the CURRENT size of the paging file, meaning if paging files are configured to expand [the default when you choose System Managed] that the commit limit will go up as the paging file expands).”

Breaking the 32 bit Barrier :
on game initialization, enough memory is reserved and committed by using CreateFileMapping API. This consumes the physical memory, but no virtual addresses

...

Windows is handling this pattern very well, while the space can be backed up by the "page file" in theory, in practice it works in such a way that as long as there is enough of physical memory available, there is zero page file traffic and all information is handled in the physical memory only. The memory kept in this type of storage is not mapped to any virtual addresses at all, it is identified by the offset in the file mapping instead. Addresses are assigned only temporarily, when the content of the cache is read.

But, whatever. I'm done.

Something I read on a mission thread today, could be completely unrelated:

Crash Issue: "I and other users connecting to the mission keep getting a memory crash error!"
Temporary Workaround: For now, the only way around this is to set verifySignatures=2 on your dedicated server and perhaps also disable BattlEye.  The actual cause of the memory crashes are unknown.  It seems to occur sometimes when CUP Weapons, Units, and Vehicles are loaded.

@nateberkopec From what I heard ALiVE doesn't work with it yet, though.

Is that true???

If so, does that mean every single mod ever will need to be ported to work with 64-bit???

I mean, I guess that makes sense seeing as most mods needed ports with Skyrim SE but damn if that's not a real buzzkill. My @mods has to be dozens of GB's. To have to redownload everything again? Wow.

EDIT: Apparently ALiVE will not work with 64-bit right now according to Road Runner. Bummer. As if you guys aren't busy enough as it is. :(

Why wouldn't ALiVE work? The only things affected by the 64-bit switch are the DLLs. ALiVEClient.dll is only used for indexing maps and ALiVEPlugin.dll is only used for persistence on the server. Just keep using the 32-bit server and everything will work fine besides indexing.

For modders, too, there are some things to keep in mind. If your scenario or mod uses a call extension, the extension has be to provided both in 32-bit and 64-bit versions now. Otherwise, your game will most likely not work as expected. Unfortunately, there is no flexible way for us to work this around for you behind the scenes. 64-bit processes can only load 64-bit shared libraries (*.dll on Windows, *.so on Linux) and therefore it is expected that content creators provide them. This process should be rather straightforward, though, and we do not expect any major complication on our talented community's side.

To make the transition as transparent for you as possible, we at least made it so that no changes to scripts will be required. All you need to do is build a 64-bit version of your extension and name it <yourExtension>_x64.dll on Windows (or <yourExtension>_x64.so on Linux). In other words, you add the "_x64" suffix to the name. Similarly, mod creators relying on hacking repurposing DirectX libraries will have to dust off their skills once again and perform their magic on 64-bit version of these libraries in similar a fashion as they did on their 32-bit counterparts back in the day. Of course, it is also worth mentioning that you should not forget to whitelist your new libraries with BattlEye!

You're actually doing this backwards. From the wiki:

Making a mission with a lot of Virtual AI then artificially spawn-limiting them is inefficient and may get weird results, such as units spawning in behind players and moving into areas already cleared. Best practice is to reduce the density or number of Virtual Profiles in the Placement Modules to improve performance.

So what I like to do, is keep the Virtual AI profiles as close the default 144 as possible, and limit the actual spawns with the mil/civ objective modules themselves.

It's my understanding and experience that using the overrides for the types of forces simply adds those to the spawns, not limits.

For example, if you place a Platoon 30 with no overrides, notice:

1. Depending on the map, AO, objective amounts and grid size, more then 30 profiles will spawn.

2. Let's say without overrides, in this example 50 profiles spawn. Let's say that's 35 infantry, 10 vehicles, and 5 Armored. If you write "2" in the Armored section, the results might end up being 52 total profiles, breaking down as 35 infantry, 10 vehicles, and 7 Armored.

That's just an example and can fluctuate. You'll rarely spawn the exact numbers every time because I believe there is an element of "randomness."

Depending on the area you let units spawn, a Battalion of 800 profiles can be a lot! The more units you spawn, the more objectives the commander will have, and every objective will need to be manned by a profile.

A good rule of thumb for performance is to limit the amount of objectives. You can accomplish this by:

1. Reducing the size of the AO. And/or...

2. Reducing the profiles you let spawn by the objective modules themselves.

2A. Filtering the objectives with the filter dropdowns.

Determining what causes Arma crashes is the textbook definition of finding a needle in a haystack. :(

Fortunately for me my Arma hasn't crashed in ages, but I usually only host for one player (me). You arguably have a better rig than I do too so you probably are in a decent position to succeed.

That's not a bad idea lowering the amount of spawns the way you did, so keep us posted. Depending on my overall goal, and map size I tend to use an amount higher than Platoon 60 but I'm sure you'll find a sweet spot between performance and things to shoot. :)