At 03:11 AM 4/8/2011, you wrote:
On Thu, Apr 7, 2011 at 7:59 AM, Ben Karel <[email protected]> wrote:
- On Mon, Apr 4, 2011 at 8:42 AM, Ben Kloosterman <[email protected]> wrote:
- I will second that the whole shadow stack is a bad approach from the start , it needs a redesign. Eg apps can emit GC code snippets , while not too difficult to do its a architectural change which requires more from application and hence some politics..
- Wait, who said anything about a shadow stack?
Last time I looked, the basic GC model in LLVM was to use a shadow stack, and LLVM lacked the necessary infrastructure to build, e.g., call frame register maps.
- ...it's not a question of [the LLVM team] sticking their heads in the sand about GC, it's simply that the core clients (and sponsors) of LLVM are for non-GCed languages. So they are rationally allocating their resources towards improvements that benefit all LLVM clients, and assuming that those clients who are not satisfied with the current infrastructure will improve it as they find necessary.
Compiler infrastructures take a long time to build, and are long term investments. They involve core technical decisions that are very difficult to change (e.g. the IR design). For this reason, successful compiler infrastructures simply cannot afford to succumb to the kind of short-term thinking you espouse. In this case, the core technical decisions in question go all the way back to Chris's Masters work, so I have to say that I don't buy the sponsorship argument.
In any case, if the LLVM team believes that a sufficiently motivated party can do an incremental evolution from where they are to a GC-supporting IR, I think they are being unreastic. It isn't a simple set of changes. The level of disruption to currently ongoing work in progress is simply too high, the negative performance impact is likely to be significant, short-term sustained competitiveness mitigate against both. Chris is not the least bit naive about these concerns.
I find the LLVM infrastructure to be a disappointment from this perspective. Given how recently it was designed, and the clearly desperate need to deal with mixing managed and non-managed languages, the decision to omit core support for managed languages from the LLVM design strikes me as a bad design decision. Micrsoft has definitely gotten this right; I think Apple has not. The decision to implement LLVM in a non-managed language also strikes me as ill chosen, though that decision more sense to me situationally.
Apple has a significant commitment to Objective-C. The absence of a precise GC for Objective-C is both well-known and a significant impediment to Objective-C developers. For Apple, of all companies to produce at this time a compiler infrastructure that fails to support Objective-C as a first-class language is something that should have companies whose products are committed to Objective-C dusting off their migration plans.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
