4 ms·

> Java's GCs are incredible and you have a menu of algorithmic options can these options be used in separate parts of a single app ? e.g. the app I'm developin

> Java's GCs are incredible and you have a menu of algorithmic options can these options be used in separate parts of a single app ? e.g. the app I'm developing in C++ has parts that do realtime audio, others that do GPU rendering, others that do classic Qt Widgets GUI, others that do offline computations on datasets - and they all have different performance characteristics and need different memory management schemes to get the best out of each, all while being in a single process; there's reference counting, tree-based allocation, pooled, linear, a GC-ish thing which ensure that memory is freed in specific non-realtime threads... Can that be done with Java or is one tied to a single GC implementation for a given execution of a process?

imtringued 4y ago
If Java had isolated heaps then C++ would become redundant in every aspect except memory efficiency.
- marwis 4y ago
  What are the advantages of isolates vs running multiple JVM processes other than avoiding slightly higher memory usage and some small context switch overhead on IPC - which should be negligent as presumably communication between isolated components would be coarse grained?
  - jcelerier 4y ago
    I can give you an example: in the Bitwig digital audio workstation, you can choose whether external third-party plug-ins (small audio processors) are in the host process or in external processes communicating through shared memory. I just tried with a very simple plug-in (3 band EQ) to see how much I can stack in either case: - In the "in-process" case I can stack ~1400 plug-ins on a single channel before I hear a crack in the sound. - In the "shared memory" case I can go up to ~200 at most. And I'm confident that they really did the very best things possible for the implementation to be performant. So for me the "things isolated in their own process" means literally getting seven times less out of my system than in the host process (and that's frankly unuseable, definitely not "negligent").
- origin_path 4y ago
  Actually it does if you use the GraalVM Native Image AOT compiler. It's a sort of pseudo-JVM that gets linked into your app and provides the following features: 1. Instant startup due to AOT compilation and a cached heap. Can start faster than C! 2. No warmup. 3. Can create native code shared libraries. 4. Offers isolates, which are segregated heaps that do GC separately but run in-process and which can communicate with each other. The tradeoffs are that unless you buy the more advanced edition, peak performance is lower due to lack of JIT profiling, you may need to write configs and do other fiddling to ensure the AOT compilation doesn't miss any code that's accessed via reflection, it takes a long time to compile, and you can't dynamically load bytecode (which some libraries do behind the scenes transparently).

imtringued 4y ago

If Java had isolated heaps then C++ would become redundant in every aspect except memory efficiency.

marwis 4y ago
What are the advantages of isolates vs running multiple JVM processes other than avoiding slightly higher memory usage and some small context switch overhead on IPC - which should be negligent as presumably communication between isolated components would be coarse grained?
- jcelerier 4y ago
  I can give you an example: in the Bitwig digital audio workstation, you can choose whether external third-party plug-ins (small audio processors) are in the host process or in external processes communicating through shared memory. I just tried with a very simple plug-in (3 band EQ) to see how much I can stack in either case: - In the "in-process" case I can stack ~1400 plug-ins on a single channel before I hear a crack in the sound. - In the "shared memory" case I can go up to ~200 at most. And I'm confident that they really did the very best things possible for the implementation to be performant. So for me the "things isolated in their own process" means literally getting seven times less out of my system than in the host process (and that's frankly unuseable, definitely not "negligent").
origin_path 4y ago
Actually it does if you use the GraalVM Native Image AOT compiler. It's a sort of pseudo-JVM that gets linked into your app and provides the following features: 1. Instant startup due to AOT compilation and a cached heap. Can start faster than C! 2. No warmup. 3. Can create native code shared libraries. 4. Offers isolates, which are segregated heaps that do GC separately but run in-process and which can communicate with each other. The tradeoffs are that unless you buy the more advanced edition, peak performance is lower due to lack of JIT profiling, you may need to write configs and do other fiddling to ensure the AOT compilation doesn't miss any code that's accessed via reflection, it takes a long time to compile, and you can't dynamically load bytecode (which some libraries do behind the scenes transparently).