Provide an alternative jvm for improved performances

[lesquoyb]

Thanks to a small report sent by @RoiArthurB I noticed that all efficient code submitted to a java performance competition were using the GraalVM instead of the standard openjdk we provide.
So I decided to test it on gama to see if there's any gain to make from this. To do so I quickly tested two models provided in this issue one with list operations and the other using the grid to compute diffusion.
I compared latest alpha with the packaged jdk21, graalvm that uses jdk23, and openjdk 23.
The diffusion model is a bit tricky to compare as gama is optimizing it every time you rerun, so I made multiple long runs, here are the results:

run	jdk 21	jdk 23	graalvm jdk 23
1	8580.0	9080.0	8179.0
2	8034.0	8978.0	7349.0
3	7800.0	8829.0	7120.0

I know the sample size is pretty small but we can see close to 10% improvement compared to current version in runs 2 and 3 (and surprisingly jdk23 is slower in this example)

For the list examples it's a little bit different:

method tested	jdk 21	jdk 23	graalvm jdk 23
list with length	2.680 ms	2.139 ms	1.956 ms
list with count	2.935 ms	2.306 ms	1.667 ms
species with length	26.324 ms	26.400 ms	27.819 ms
species with count	24.210 ms	17.940 ms	18.649 ms

So it's close to 30% increase in the first and third cases, more than 50% in the second but a 5% penalty in the third case, and simple jdk 23 being a bit better on the same three cases two and similar performances in the third case.

Another thing to mention is that launching gama feels substantially slower with graalvm, but navigating feels the same once it's started. We could probably check compilation time too, that's probably an area that could benefit a lot from graalvm JIT.

I looked up the resources used by gama during runtime and found that it was pretty similar, here is jdk 21 chart for two runs of the diffusion model:

and here the same with GraalVM (don't mind the difference in time, I was setting up some things at the same time too, just look at spikes corresponding to simulation runs):

cpu use in both cases is close to 50% and the number of classes too is similar.
Heap size is managed a little bit differently, but the maximum values are approximately the same, the only difference seem to be an average a little bit lower for GraalVM but it would require more investigation.
Regarding threads, apart again from a different managing of their lives, GraalVM uses 81 live and 43 during the second run while jdk 21 uses 85 and 44, I have no idea if this has an impact or not, but just so you know.

So overall I think it may be interesting to investigate more what we could do with different jdk like GraalVM, and maybe package it as an alternative experimental build for performances ?