7 ms·

Anyone interested in newer GC strategies would be well off looking at two, one commercial, one that's hopefully going to make it into OpenJDK. The commercial o

Anyone interested in newer GC strategies would be well off looking at two, one commercial, one that's hopefully going to make it into OpenJDK. The commercial one is already available, the other is still pretty POC/not ready yet. Both look to provide 'pretty pauseless' collection. http://www.azulsystems.com/zing/pgc http://www.azulsystems.com/zing/pgc http://openjdk.java.net/jeps/189 http://openjdk.java.net/jeps/189

virmundi 12y ago
Might it be worth looking at the solution from a different angle? I know the GC improvements are good across the board, but what about moving from monolithic applications that require more than 2- 4 GB of memory to a series of micro services? Each service provides a sub set of functionality to the large system. They are able to run with good execution because they don't generate enough long lived objects to cause problems. When paired with a SPA on the client side, you can probably get a scalable, efficiently collected system. You can even use large boxes to house multiple services.
- nickik 12y ago
  Seams to me that is a huge waste of space and power to have tons of diffrent micro services each with there own JVM or maybe even each with there own virtulised OS. This overhead is then even increased because instead of direct calls you have to serialise information between diffrent micro services. From a architectural point of view, this micro service things is probebly great (or actors) but I would still want to have, if possible, one OS and one JVM per hardware maschine that im running on. A modern server has easly 128GB ram and 16 cores (im not up to date whats standard). So if you imagen lots of microservices that only use 1GB ram each you are talking about 100 virtualised OSs and 100 virtualised JVMs plus tons of serialisation overhead. Its far more effective to have 1 JVM that runs 1000 thread and uses the full 128 GB memroy. Not only is it far more effective its also far easier to run and monitor.
  - sitkack 12y ago
    Erlang has micro-heaps, each process has its own heap so GC pause times are minuscule. Having too much address space is a liability, so limiting the reach of piece of code has GC advantages. I think as memory limits increase we will move to something like tagged heaps, a melding of GC, memory regions and static allocation. One can already get this by running multiple emscripten compiled programs in a JS engine, esp if one pushes tasks into web workers. You don't necessarily have to serialize data between services if one uses something like capnproto or flat buffers. Why have one heap?
    - nickik 12y ago
      That kind of architecture might be ok for problems but I not sure how general it is. Also, why force a diffrent programming model when it is possible to have a GC that does a good job. There is erlang on java and it performs quite well, so you can combine the two things. I dont want technogoly to force my architecture, if I make a choice to go with actors I want it to be, because its the right choice and not because I have to.
      - sitkack 12y ago
        Having a global flat address space has its tradeoffs. We use a GC because we don't want to have to specify the lifetime of memory ourselves. Rust also has no false sharing between threads, much like Erlang, a thread always owns the memory it operates on. Technology always forces architecture.
        dbaupp 12y ago
        Rust does allow shared memory, either via unsafe code, or using a safe wrapper provided by the standard library (or an external library). http://doc.rust-lang.org/nightly/std/sync/struct.Arc.html http://doc.rust-lang.org/nightly/std/sync/struct.Arc.html
aardvark179 12y ago
There was good talk on Shenandoah at Strange Loop http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCgQtwIwAQ&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DQcwyKLlmXeY&ei=K7N1VPfECpLWau2LgfAK&usg=AFQjCNFIuEyAMJ4EHUU8f6tBJzhLGp1kyQ&bvm=bv.80642063,d.d2s http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&...
- nickik 12y ago
  Sadly this video is incomplet but the most importent stuff is there.

virmundi 12y ago

Might it be worth looking at the solution from a different angle? I know the GC improvements are good across the board, but what about moving from monolithic applications that require more than 2- 4 GB of memory to a series of micro services? Each service provides a sub set of functionality to the large system. They are able to run with good execution because they don't generate enough long lived objects to cause problems. When paired with a SPA on the client side, you can probably get a scalable, efficiently collected system. You can even use large boxes to house multiple services.

nickik 12y ago
Seams to me that is a huge waste of space and power to have tons of diffrent micro services each with there own JVM or maybe even each with there own virtulised OS. This overhead is then even increased because instead of direct calls you have to serialise information between diffrent micro services. From a architectural point of view, this micro service things is probebly great (or actors) but I would still want to have, if possible, one OS and one JVM per hardware maschine that im running on. A modern server has easly 128GB ram and 16 cores (im not up to date whats standard). So if you imagen lots of microservices that only use 1GB ram each you are talking about 100 virtualised OSs and 100 virtualised JVMs plus tons of serialisation overhead. Its far more effective to have 1 JVM that runs 1000 thread and uses the full 128 GB memroy. Not only is it far more effective its also far easier to run and monitor.
- sitkack 12y ago
  Erlang has micro-heaps, each process has its own heap so GC pause times are minuscule. Having too much address space is a liability, so limiting the reach of piece of code has GC advantages. I think as memory limits increase we will move to something like tagged heaps, a melding of GC, memory regions and static allocation. One can already get this by running multiple emscripten compiled programs in a JS engine, esp if one pushes tasks into web workers. You don't necessarily have to serialize data between services if one uses something like capnproto or flat buffers. Why have one heap?
  - nickik 12y ago
    That kind of architecture might be ok for problems but I not sure how general it is. Also, why force a diffrent programming model when it is possible to have a GC that does a good job. There is erlang on java and it performs quite well, so you can combine the two things. I dont want technogoly to force my architecture, if I make a choice to go with actors I want it to be, because its the right choice and not because I have to.
    - sitkack 12y ago
      Having a global flat address space has its tradeoffs. We use a GC because we don't want to have to specify the lifetime of memory ourselves. Rust also has no false sharing between threads, much like Erlang, a thread always owns the memory it operates on. Technology always forces architecture.
      - dbaupp 12y ago
        Rust does allow shared memory, either via unsafe code, or using a safe wrapper provided by the standard library (or an external library). http://doc.rust-lang.org/nightly/std/sync/struct.Arc.html http://doc.rust-lang.org/nightly/std/sync/struct.Arc.html

aardvark179 12y ago

There was good talk on Shenandoah at Strange Loop http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCgQtwIwAQ&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DQcwyKLlmXeY&ei=K7N1VPfECpLWau2LgfAK&usg=AFQjCNFIuEyAMJ4EHUU8f6tBJzhLGp1kyQ&bvm=bv.80642063,d.d2s http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&...

nickik 12y ago
Sadly this video is incomplet but the most importent stuff is there.