Oracle or Sun should just have bought Azul back in the day. I have no idea why they did not. Both there JIT and GC were way better then what they sold to there costumers and maybe hardware would be further along by now as well.
Its awesome that we now see opensource project shooting for a pausless gc.
Gil & Azul have always been very focused on their particular market segment, but it's not a solution that suits every workload or can be deployed generally (C4 requires OS enhancements to operate).
I have not suggested that they put C4 or the orginal passless as a standard. While they did focuse on a perticular market segment the performance and paustime numbers they showed could easly have been usful for tons and tons of other markets.
While C4 does currently require OS enhancements, they could make it without it, it would just be slower. However the problem that Azul has tried to overcome with the OS could have been much more powerful attacked with the full force of oracle/sun behind it. They once put some linux patches but it was never there focus and it never went upstream.
At a big company this technogoly could have had a bigger impact, they could have talked to microsoft, apple and the linux team. I know that Azul also tried to strike up a conversation with Intel but in there words "it was like moving a mountain".
And im not suggesting Sun/Oracle should have done this for the greater good of all humans. They would would have created a gigantig benefit for java products over the competition C# and C++ in the server space.
I rember talks by Cliff Click that mentioned that they were really suprised that Sun did not have more intresst in them, considering some simple things that Sun could have to get huge increses in some of the high end server systems they were selling (am searching for the refernce ...).
I agree with everything you said. Here is an interesting lwn article from when the azule people originally tried to push their change/enhancements upstream.
Its a pitty that this type of GC hasn't found widespread use because it gives us the best of both worlds, in terms of automatics memory management and performance.
Well I think it was not there fault and not the linux peoples fault. I have read everything I could find on this.
The linux people are write to not just exept code from outsider into there most importent subsystems like the scheduler. Azul did more of a code dumb then really try to get patches upstream. If they had taken the time to split up there code into diffrent patches and then take the time to explain why they needed it, why lots of other people also needed it, they might have gotten lot of it threw, or at least get the conversation rolling on what the linux guys could do to make managed runtimes faster.
Its of course also true that managed runtimes are not what linux kernal hackers focus on.
So it boils down to Azul guys not having enougth time to do it right and the linux people were not exited enougth to roll withit themself.
Maybe there was a lot more talk going on in the background, but I at least could not find much more on this.
I've been following Philip Reames' blog, it's good to see LLVM get some serious precise GC love.
Reading the job advert, I would have to wonder if they want to avoid an all in, 100% bet on the Hotspot JVM, not to mention strict JVMs in general. I wouldn't be surprised if they have the best concentration of knowledge on Hotspot in the world, including Oracle, might be getting a bit tired of it, and certainly would know the limitations of its code base by now.
I think that they might just want to profit from all the love going into LLVM. Currenlty hotspot has costum optimization and if you have a product based on it you have to maintain this and improve it. If you manage to creat a fast powerful LLVM based JVM you can profit from the other work going into that space and maybe distance yourself from the orcale standard.
However, currently not that many JIT are LLVM based so it seams that it needs some love to get this to working well. Both for GC and compilation speed. Thats at least my guess.
I know, they could have rolled Azul tech into the UltraSparc and made truly amazing hardware platform for the JVM that was a _couple_ orders of magnitude ahead of the competition.
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.
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.
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.
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.
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.
It would be nice to have something like this for Google's GC in Android. Does anyone know how close this is to what Google has implemented--especially in later versions of Android.
Its awesome that we now see opensource project shooting for a pausless gc.