On Tue, Apr 10, 2012 at 4:51 PM, David Jeske <[email protected]> wrote:
> We should produce mainstream royalty-free x86 runtimes for JVM and CIL > that have no world-stop. Looks like Azul may have a commercial JVM with no > world-stop. We need tech like this to be 'standard'. > I like this idea, but having worked a bit with such a collector I feel confident saying that it's not a panacea. The hard truth is that we will continue to need a diversity of collection technologies. For small heaps, in particular, you are better off doing stop-the-world than you are doing concurrent collection; the overhead is lower. Once it is admitted that stopping-the-world is unacceptable, then "reducing > pauses" is not interesting --- because it still does not stop the pause. > Except that the proposition is silly. On a 128Kb heap, stop the world is perfectly fine, and the overheads of concurrent collection become unwarranted. I raise this because systems having a larger number of smaller processes are of great interest from a security and robustness perspective. *However* * * Data sharing across heaps is very important in systems based on safe languages, and *that* introduces some important constraints on GC... Yes and no. The value types in CIL remain second class, the absence of a >> fixed-length array type is crippling to some very important cases, and the >> atomicity rules in the presence of concurrency defeat a whole bunch of >> inlining options. >> > > I'm interested to know more about this. Is there something written on it? > For starters, a CIL struct (the user defined value type) does not admit inheritance. For seconders, I *think* there are some constraints associated with their use in generics. > Interesting. I don't see how to solve real-world problems with > allocation-free subprograms. Such as extending an HTML DOM in response to > user-input, or moving 3d polygons through an octree (which requires polygon > subdivision and tree splitting). > Look. You ultimately have three choices: 1. Don't allocate 2. Pre-plan your required resource 3. Use explicit regions to relegate allocations to safe points in your program But there just isn't any silver bullet here. Every explicit memory manager that is non-coalescing can suffer fragmentation. Every explicit memory manager that is coalescing has asymptotic cases. That said, the pre-planning approach bears real thought. The main concern with explicit memory management is safety. When you are explicitly allocating and deallocation from a pre-reserved pool containing objects of like type, there is a dangling pointer issue but no safety issue. For the most part, that's actually what ends up happening under the covers in the explicit memory management scenario. So really, I think there are just a *lot* of things that can be done to help once we acknowledge that no allocator is a panacea and that real programs sometimes have to express things at the "blood and the mud" level - it's not all just abstract, which is how some people in the PL community would still prefer to view it. That attitude in the PL community is changing, by the way. It's not that they abandoned concrete issues because they were unimportant. Rather, they did so because they wanted to establish formal underpinnings for programming languages and there were only so many things they could deal with successfully at a time. 30 years later we know how to do things like fancy type systems for languages that don't speak of concrete issues. Now that this is true, *some *members of the PL community are coming back and working actively with systems people again. Greg Morrissett's group and Stephanie Weirich's group are two that come immediately to mind. > After we have a zero-pause runtime, we can spend time and research on > alternative techniques such as regions and advancements to value-types to > relieve pressure on the GC system. > That's backwards. The region and other advances are available to us today. The pausless collectors are still not understood well enough to be mainstream yet. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
