Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DavidHayabusa]

I have been reading about BAT 3.6. Can someone explain to me what is the Java Wall please? By the way, can someone explain to me the Ram manager in the Il-2 selector tab? What does it do exactly?

[SAS~Storebror]

Java Wall is an imaginary limit that applies to everything consuming memory in the Java Virtual Machine running IL-2 1946.
There's certain things that are heavier in terms of memory allocation and others that seem not to cause any trouble as long as using them isn't getting exaggerated.
The Java Wall is a pretty nasty thing as it doesn't kick in for everyone at the same time and under the same circumstances.
The biggest impact apparently was from the number of installed aircraft.

As a rule of thumbs, we've had like 600 airplanes available in UP3/DBW and that seemed to be the sweet spot to reliably stay just underneath the magic "Java Wall" limit for about a decade.
With BAT 3.6 we've changed quite a few parts of IL-2's core code to overcome this limitation (it's just 43.010 files being installed...).
BAT 3.6 has like 2000 aircraft in it and doesn't suffer from the Java Wall issue anymore.

As much as the Selector is concerned, it ships with a pretty comprehensive manual which I'd recommend to read.


Mike

[SAS~Poltava]

I think Storebror is being a bit too modest here. I'm an old hand when it comes to modded IL-2 but no techie, but the effects of the JAVA wall has been very clear for everyone to see, firstly in putting an absolute limit to the number of aircraft, vehicles, objects etc that can be put in the game, and secondly the slow degrading of the performance, in practice limiting the number of aircraft etc that you can use in a single mission.

Getting through the Java Wall is the modding worlds equivalent to splitting the atom: it changes reality for ever If there was a Nobel Prize in modding it should be awarded for this feat. The performance of BAT 3.6 is just unbelievable. This is really, really, really BIG.

[vonofterdingen]

I agree with Poltava. This is a major breakthrough, especially for campaigns/missions with many aircraft. Sometimes a few aircraft are enough, but how do you do an immersive Battle of Britain with 8 aircraft per side...

[Venator77]

Theoretically, how many aircraft can be flown in a single mission without causing issues?

[Vampire_pilot]

The Java Wall is a pretty nasty thing as it doesn't kick in for everyone at the same time and under the same circumstances.
The biggest impact apparently was from the number of installed aircraft.

meaning: it depends. On how well the java of the aircraft actually is written. Very much so even as Mike found out.
The java classes can be heavy on memory allocation or not. If you smash a hundred mods in with bad java, you will clog the pipe again. But maybe you can add a thousand aircraft, if their java is clean.

[VF19_Congo]

So, it's probably not just aircraft right? Does this apply to all objects, moving and static, hidden map objects etc. ?

I used to hit an object limit in some of my epic FMB missions years ago, and I would get a notification in FMB
when it happened. I think it applied to any object at all being added, but cannot remember.

What about the maps themselves, is are they subject to the quality of the java code or not? I notice loading
times can be quite different for the maps, or it seems so at least, particularly if they are heavily populated
in the FMB.

What about skins, should I limit my skin folder or doesn't it matter?

[Squashman]

So, it's probably not just aircraft right? Does this apply to all objects, moving and static, hidden map objects etc. ?

I used to hit an object limit in some of my epic FMB missions years ago, and I would get a notification in FMB
when it happened. I think it applied to any object at all being added, but cannot remember.

What about the maps themselves, is are they subject to the quality of the java code or not? I notice loading
times can be quite different for the maps, or it seems so at least, particularly if they are heavily populated
in the FMB.

What about skins, should I limit my skin folder or doesn't it matter?

I think it's more to do with what is visible in the field of view, and my own experience is that "chiefs", particularly ships, are the next greatest user of memory after aircraft. Obviously one's rig has to be up to the task, but assuming all things being equal, nothing seems to affect performance like the number of chiefs in a mission, and how many are in the field of view.
For example I regularly fly missions involving representations of US Task Force 38 or 58 from the Pacific Theatre, with not far off accurate numbers of the vessels involved, so that I am often flying in skies above forty or fifty ships and if a good proportion of them are in my field of view then FPS drops dramatically, often from the usual steady 60fps to 20fps or so, and that is with Intel i9 and Nvidia 2080Ti.

Otherwise the improvements to BAT are nothing short of amazing when it comes to aircraft. In skies with, for example, 40 plus aircraft in a recent mission I was getting 57/58 fps even at x16 time acceleration.
If only the same could be done for ships as has been done for aircraft.

How about it Mike Storebror 

[SAS~Storebror]

So, it's probably not just aircraft right? Does this apply to all objects, moving and static, hidden map objects etc. ?

Correct, yes, yes and yes, yes.

I used to hit an object limit in some of my epic FMB missions years ago, and I would get a notification in FMB when it happened. I think it applied to any object at all being added, but cannot remember.

That's unrelated.
You have just had too many objects in your FMB mission for the game to handle correctly.
This is solely an FMB issue.
It has nothing in common with the Java Wall.

What about the maps themselves, is are they subject to the quality of the java code or not?

Maps have no Java code and as such, are not subject to the Java Wall issue.
Objects placed on a map have Java Code and could contribute to the Java Wall issue, but if they do, it doesn't matter whether or not any map uses them, let alone whether you load such map.

I notice loading times can be quite different for the maps, or it seems so at least, particularly if they are heavily populated in the FMB.

That's just normal.
It's not related to the Java Wall and it's not even an FMB issue, just normal behaviour.
The bigger the map and/or the more objects on it, the longer it takes for the game to load it.

What about skins, should I limit my skin folder or doesn't it matter?

Doesn't matter at all.

I think it's more to do with what is visible in the field of view

No sorry, that's unrelated to the Java Wall.

The Java Wall is something that happens in the Java Virtual Machine at the time when the game starts up already.
It is solely related to certain factors (you could call it "bad habits") in Java Code and it could happen in any Java Class.
As matters stand, Aircraft contribute the most to the Java Wall issue because their Java Code - the way it has been done for the past decade - was "worst" from a JVM's perspective.
If the Java Wall kicks in, it does so brutally.
It will immediately, dramatically reduce the remaining object memory in the JVM.
When you are right on the edge of it, there might just be enough space left to run simple missions, but medium ones will exceed the remaining space and FPS will drop dramatically.
When you're hitting the Java Wall harder, there will be no space left for your dynamic objects at all, which means the game will constantly run the garbage collector in order to swap out at least enough to keep your objects pop into memory and show them (just to see them getting kicked out by the garbage collector right thereafter). The FPS will be in single digits then.

What we did with our Java Wall fix was to change the Java Code of a few thousand Java Classes in order to get rid of what bugs the JVM the most.
That gives us a save distance from the JVM's limits, enough to hold a few thousand more additional aircraft without hitting that dreaded Java Wall.


Mike

[VF19_Congo]

Wow, Thanks Storebror.

One more question if you don't mind, and if it's still on topic:

At some point, on big missions and maps with lots of different aircraft available at bases,
I will spawn or change to outside view and I lose the aircraft textures, I just see a black
model, and then I often get a freeze up, rather than CTD.
The Magellanes map (Huge!) is notorious for this, though it's one of my favourites, I tend to build
elaborate airfields there as that map's bases are rather sparse affairs.

Any idea what's going on with that?

[SAS~Storebror]

Maybe your GPU can't hold all required textures at the same time.
Maybe it's something completely different.
I'd recommend to start a new thread for this, together with a log from the time of that issue.


Mike

[Squashman]

What we did with our Java Wall fix was to change the Java Code of a few thousand Java Classes in order to get rid of what bugs the JVM the most.
That gives us a save distance from the JVM's limits, enough to hold a few thousand more additional aircraft without hitting that dreaded Java Wall.


Mike

Many thanks Mike.
What with this and the likes of Slebenli's Graphic Extender, these are very exciting days for IL2