[bitc-dev] Retrospective Thoughts on BitC
davidj at gmail.com
Tue Apr 10 03:11:51 PDT 2012
On Apr 9, 2012 6:08 PM, "Jonathan S. Shapiro" <shap at eros-os.org> wrote:
> The STOPLESS collector and the Azul collector were the two I was thinking
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
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
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev