Thanks for sharing your results Moezilla.
The effect that you've examined is the famous "Java Wall" which has first been observed on DBW when people started adding additional planes to that modpack.
Currently there's nothing we can do about this as all attempts to reduce the stress caused for the Java VM by the sheer number of loaded classes always ended up with a no-functional (or at least not fully functional) game.
The worst thing about the Java Wall is that it doesn't kick in with exactly the same number or effect for everyone.
For instance when your game was fine with ~600 aircraft and showed significant performance drop at 615, then these numbers for another player might as well be 550 and 552, and for a third one they might be at ~700 and 750.
Just to give a little technical background for what's happening here, the IL-2 game engine is designed to load
all classes when the game starts, whether or not they will actively be used later on.
Since IL-2 uses it's own classloader which causes all classes to run their static initializer unconditionally, every class being passed through that classloader will occupy one "slot" in the - apparently - limited number of class slots available to our Java VM.
We're bound to use the way outdated Java 1.3 Virtual Machine, where no one ever observed this "Java Wall" when the VM was actively being developed, but that's of course since at that time no one used PCs with 4GB RAM and more, so no one was able to load that massive number of classes in parallel like we do nowadays.
The reasons why IL-2 kicks up each and every class whether or not it will be used later on are many.
Two of the reasons are the "monolithic" design of IL-2 which is just not meant to be used with delayed class initialization, and the anti-cheat mechanism "CRT=2" which strictly relies on all participating classes of the game being loaded and initialized when the runtime check kicks in (the latter btw. is the reason why CRT=2 never worked reliably on UP3, but I won't go into details about that right now).
The best way out in my opinion would be to forget about CRT=2 and restructurize the game in order to make it capable of delayed class initializations.
Ideally this would enable us to hand over endless classes to the game, which would only initialize those which are actually being used.
That way we would reliably avoid the "Java Wall" even if all CUP modules would sit together in one slot, since even when you have ~1.000 planes, 3.000 ground/sea and 10.000 static objects available to the game, even after playing 24 hours in a row you would barely touch 1/10th of them.
Only Servers would still need to be handled with a little care since after running a few weeks they might be able to hit the "Java Wall" even with delayed class loading again.
Unfortunately, as mentioned in the beginning of this post, the delayed initialization currently doesn't allow the game to run reliably.
Maybe we can fix that one day, maybe not.
If TD would share some native game code with us, we could surely fix that in a fraction of the required time it will take with all the reverse engineering we have to go through now.
But that's a TD thing and as you know, making life hard for modders is what makes them happy
As long as they don't suffer from the same issue too (and they won't, with their little tiny "stock" game they have), they will give a damn for such concerns.
Best regards - Mike
Author
Topic: WAW20 Drained Beta (Read 10344 times)
