On Tue, Apr 10, 2012 at 3:33 AM, Matt Rice <[email protected]> wrote:
> On Mon, Apr 9, 2012 at 8:52 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > > I don't know much of anything about singularity, and this I suppose > may be the crux of 'tree shaking'... The tree shaking idea is independent of singularity. Tree shaking can be thought of as a very aggressive form of dead code elimination. What's been said in public papers is that unreferenced classes, methods, and fields are removed. When done transitively, this can eliminate a *lot* of code. increased whole-program reuse > would seem to mitigate the need for shared libraries, > but i've never really tried to answer whether it would be enough to > tip the balance. though I surmise from your position you consider the > answer to be 'no', I just wanted to make sure that was a 'No, not even > under conditions favourable to whole-program reuse.' > I'm not aware of any good quantitative experiments on this, but my expectation is that there is still a motivation for shared libraries. Even when processes are sealed and heavily reused, the amount of common code across processes is much larger than people think. For one thing, *most * programs perform some form of error reporting (if only in the form of assert()). That brings in an appallingly large portion of the standard library. The place where reduction *may* be seen is in the replacement of libraries by sealed components. OpenSSL, in this view, would move to a highly replicated process. The problem with this expectation is that most of the candidate shared libraries for this migration do a large amount of data motion between the library and its client code. Enough so that crossing a process boundary carries a very significant penalty. So in the end, it isn't clear (to me) how far this kind of separation can successfully be taken. It's especially relevant in the present context, because the use of safe languages drastically reduces the "separation of concerns" issues that motivated address space separation. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
