On Apr 9, 2012 6:08 PM, "Jonathan S. Shapiro" <[email protected]> wrote: > The STOPLESS collector and the Azul collector were the two I was thinking about.
I would be very happy if either were available and usable on x86. I would very much appreciate your opinion on a thought of mine... The general technique in STOPLESS of using dual-machine-code versions seems challenging. I've wondered if it would be possible to do a reasonable facimilie of the Azul hardware-assisted barriers with the help of the x86 MMU and phantom writes (or reads). My hope is to allow compiled code to carry "optional barriers" with fairly low inactive-cost and then use the MMU/TLB to make those barriers active when needed. This would allow us to convert stop-the-world into slow-the-world, which I think would be a significant advancement. I have no practical experience with MMU/TLB coding, so I'm not sure if the above theory works out in practice. Do you have an opinion on this? Does it seem at all possible/practical? >> In real systems we expect to be able to respond to user-actions 10-20ms. This is not possible to do reliably with today's GC systems. > > I think that overstates the requirement in some cases and grossly understates it in others - in audio applications, the proper target is 0.7ms to 1ms for certain inputs. > > But it is generally my experience that programs with truly hard requirements of this kind have phases in which they apply and phases in which they do not. If that is true, then the real problem is less the cost of GC than the inability to write GC-free subprograms. My experience is less forgiving. Consider any reasonably large GUI application -- a word-processor, computer game, or a 3d graphics modeling program. There is no acceptable time to stop the world because one can't predict when the user will interact next. Moving most of the data out of the view of the GC is a solution, but then we're right back to non-safety. The same lack of forgiveness is present in threaded web applications. There is normally no time that all threads are simultaneously in a pausable activity. I did hear about one GC based system that solved this problem by using an external load balancer to remove traffic from the process in advance of a GC, so the system was under no load during the world-stop. Not a very generalizable solution. > What seems to have happened is that the safe programming world, having bought off on the idea that GC was an inevitable requirement, then declared that no other form of memory handling was interesting. This, of course, was an issue that BitC was trying to address explicitly. I confess to being fully in the GC camp. I'm there not through foregone conclusion, but through decades of watching the safe/unsafe tradeoffs in manual/refcounting/gc techniques. I see no way to write 'real' apps (a game, word processor dom, web browser dom, 3d modeler, caching webserver) without heap mutability, and no way to provide typesafe heap mutability without GC. If there is a general pattern for solving these problems in a typesafe way without GC, I'd love to be shown the light. In the absense of that, I'm very happy with the direction of the CIL design (relative to JVM or those before it) because value-type-structs and parametric-type-instantiation off us practical ways to reduce tracable pointers and thus pressure on the GC. That said, we still need a way to stop stopping the world. >> This is simply impossible in a GC system which unpredictably stops the world. This in turn makes stop-the-world GC impossible to use for many systems. > > I don't like stop-the-world collectors either, but that "unpredictably" word in your sentence is critical. The only collectors I know of that are really unpredictable in this way are collectors for concurrent programs that require a universal thread rendezvous. I do not understand the significance of your observation. AFAIK, every currently shipping software collector, for every language system, requires an unpredictable world-stop. If I am mis-informed, please point me to one that does not. The MS Research on dual-code-paths with STOPLESS and CHICKEN is the only non-world-stop software collector design I'm aware of. It is not available and the dual-code-path requirement is quite difficult to satisfy. If my proposal to use MMU/TLM hardware-assist to get low-cost optional-barriers is at all viable, I'm very much interested in putting that idea into practice.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
