[For discussion] Memory management: Disable JIT compilation

[qparis]

This merge request adds few JVM options when package the app. They need to be discussed because they can have some impact.

• -Xint : The most impacting: It disables JVM options. It saves about 200Mb of memory on my computer. The drawbacks are the performance. Some views take longer to appear. I believe this can be optimized
• -XX:+UseG1GC : Use G1GC garbage collector. This should be the default so it should have no impact
• -XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5 -XX:-ShrinkHeapInSteps : More aggressive heap memory size management
• -Xmx950m -Xms32m -Xss196k : Make the JVM crash if Phoenicis takes more than 950Mo. This also make the GC more aggressive

[madoar]

I'm not sure about the garbage collection strategy.
At the current point in time I think it is of less importance, because a lot of the code is in my opinion not yet final, which makes it hard to tell much about the final performance.
For example I'm still working on the refactoring of our JavaFX components, which can have an impact on the performance of the UI.

I wouldn't set a custom limit for the JVM size, because the limit normally depends on the system underneath and less on the application you execute.

[plata]

You know that saying: "Don't optimize yet". Before we don't know what's going on, we should not fiddle with such options (in my opinion).

[qparis]

This is not a code optimization, this is just some packaging options. They do not affect the développer settings and they do not require any change.

Even though, after deeper analasys, our average heap consumption is very good (~100Mb), so I do not expect @madouar optimization to change anything.

What takes a lot of memory is the code cache, especially when the JIT compiles nashorn code. At this point, it puts some compiled code that won’t ever be used again in memory.

Another thing that consumes memory is the difference between the java heap size and the used size.

[plata]

See, this is exactly what I was talking about: If you now figured out that the JIT compilation for Nashorn is causing this behavior of the allocated memory, we can optimize the JVM args accordingly.
I'm aware that this sentence is normally used for code optimization but I think it applies to this situation as well.

Any ideas which Javascript code exactly is producing the unused code cache? Is there a way we could avoid this without touching the garbage collection settings?

[qparis]

See, this is exactly what I was talking about: If you now figured out that the JIT compilation for Nashorn is causing this behavior of the allocated memory, we can optimize the JVM args accordingly.

This is a suspicion. In fact it is really hard to profile memory.

At the end, when I run PoM with -Xint takes 160Mo at startup of memory with -Xlint and 250Mo without. However, it is wayyyy slower

[plata]

Personally, I would prefer fast vs big in that case. In the end, I have enough memory.

[qparis]

Personally, I would prefer fast vs big in that case. In the end, I have enough memory.

It depends what is slow. For example, if you take a python program, it is way slower than a Java program and no one bother

[plata]

"Slower" in the context of an application like Phoenicis makes only sense if it means "you can feel it".

[madoar]

I agree with @plata, we're not developing a real time game but a management application.
Here it is not so important whether the application is a quarter second fast as long as using the application feels smooth.
Which makes the performance of the startup phase and the later loading time for the content (applications, engines, etc.) so important.

[qparis]

This is the problem we have to deal with. Performance is not a real issue, memory footprint is (POLv4 shows 70-80Mo of memory at worst whereas POLv5 can go up to 600Mo)

The differences is that POLv4 is "cheating" because it uses a lot of external processes that are not taken into account

[plata]

If you think it is caused by the Javascript JIT: Can you turn off all Nashorn calls and see what happens?

[madoar]

I'm basically fine with using a specific garbage collection algorithm, which fits to our current implementation, but I'm asking myself: Do we need to tackle this issue now?
I mean we're still in alpha, I think it is ok if the application is not yet tuned for performance.
In addition, if we decide to use a specific garbage collection algorithm now, we'll need to reevaluate it before each release, because the code could have changed so that a different garbage collection performs better.

[plata]

I agree to this point.

[qparis]

We don't need to tackle this issue now, but we need to get proof the we can tackle this issue later

[plata]

I think you provided the proof, didn't you?

Apart from this: If this is really Nashorn JIT, it might behave completely different with Graal.

[qparis]

I think you provided the proof, didn't you?

Apart from this: If this is really Nashorn JIT, it might behave completely different with Graal.

I'm not convinced for the moment

[plata]

I'm confident that we will find some solution. After all, we don't do anything crazy here. So whatever it is should be possible to fix.

[madoar]

@qparis this PR has a merge conflict with the master branch. In addition I'm not sure about the current state of the performance of Phoenicis are there any changes that are introduced to Java 12 (or 13 in the future) and is there anything we can do as the developers of Phoenicis?