search

utopia-rise / godot-kotlin-jvm

Godot Kotlin JVM Module
MIT License
637 stars 46 forks source link

GraalVM native-image instead of JVM #4

Closed neworld closed 3 years ago

neworld commented 4 years ago

Did you consider to use GraalVM native-image. I had not tried GraalVM and don't know if it feasible, but looks promising thing for such library:

chippmann commented 4 years ago

Hey @neworld We actually are planning to use it for iOS as there no JIT is allowed. Other than that we will probably stick to regular jvm as the runtime performance is still better because of JIT. We rather have a slower startup time but an overall better runtime perf than a generally lower runtime perf. Another thing to consider is the following: during development we would need a regular jvm anyways because we need to be able to quickly reload a produced jar so the Godot editor can pick up changes in the written classes. This would also be possible with a dynamic library of course, but it would be way slower. Especially with the native image feature. I'd rather limit the differences between the development runnable and the exported runnable to circumvent weird differences in behaviour that might occure otherwise (on iOS we sadly have no other choice). But we will almost certainly revisit this topic again at a later date (probably when introducing iOS support)

neworld commented 4 years ago

Other than that we will probably stick to regular jvm as the runtime performance is still better because of JIT

Yes, JIT is doing an amazing job for performance, but it does not always good solution for real-time applications as it needs time for warmup. But on another hand, I read many complaints about native-image GC, which probably uses SerialGC and you are able only to choose its policy via -H:InitialCollectionPolicy (some info here). JVM has an option of low latency GC, while native-image just have experimental low latency for enterprise only

But we will almost certainly revisit this topic again at a later date (probably when introducing iOS support)

I suppose the same applies to Android as well.

chippmann commented 4 years ago

I suppose the same applies to Android as well.

Not for us. For android module support, Godot actually already runs an embedded jvm on android. We can and will access and use that one. So yeah Android does not have that restriction even though android apps run on a dalvik vm and not a traditional jvm one can start a traditional jvm from jni and thats what godot seems to do for the modules and we can use that for us.

for enterprise only

This is also huge consideration point. We will have to look very closely on what we need and if it fully fulfills our needs with the features provided in CE. But as said we will definitely revisit it.

Yes, JIT is doing an amazing job for performance, but it does not always good solution for real-time applications as it needs time for warmup

very true. Still we expect scripts to run many times during the lifetime of a game in the most cases, so from my point of view this is a trade off worth to take if the overall perf is better in the end. And the performance during warmup was still very good in our initial testing. But i guess we can say that for sure once the binding is in a runnable state and we can run some proper benchmarks. If necessary we can still swap the underlying vm and try to use native images.

brandonlamb commented 3 years ago

Piggybacking here, hopefully it's relevant - which JVM and GC is planned? Are you planning to use something like ZGC?

chippmann commented 3 years ago

@brandonlamb Sorry for the delay. At the moment just the JVM and GC from the open jdk. We first want to have a functional and usable state before we evaluate different options. It's also easier for us to make a decision when we can actually compare them on this project with some working examples.

chippmann commented 3 years ago

I guess this can be closed now as graalvm-native image is now a thing on master (#256). If one does not agree; feel free to reopen