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.. The strength of MMTK is its simple for the apps but it just doesnt cut it when compared to competitive products ( Mono had a similar issue using Boehm compared to the CLR whose GC blows it away)
Ben From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan S. Shapiro Sent: Monday, April 04, 2011 2:05 PM To: Discussions about the BitC language Subject: Re: [bitc-dev] Request for advice on choice of a GSoC project Jérémie: Here are my thoughts. Two important considerations in the GSoC evaluation are "impact" and "realism". Impact means "how many people will benefit, and how important is the effort?" Realism means "is the work proposed realistic?" In my opinion, work on Jikes RVM is low impact, because the Jikes RVM is not widely used. I'm actually a fan of Jikes, but it hasn't exactly taken over the world. Work on MMTk is even less useful than work on Jikes RVM, unless it benefits LLVM. Work on Mono or LLVM will have very broad impact, and GC is an area that both are actively working on. So I would suggest that you focus your attention on Mono or LLVM. The challenge for Mono is more manageable: they understand the problem, and they need to work on a precise GC implementation. The challenge for LLVM is larger: their approach to dealing with GC is complete crap, and a viable GC plan involves significant rework to the LLVM infrastructure - or at least, this was true the last time that I looked. Also, the LLVM team does not seem to take GC seriously, so there is lower likelihood of acceptance. My suggestion: any improvement to mono will have very broad benefit to the community, so that is a very good place to put your effort. Another good place would be the Dalvik VM's GC. I know that GC in Dalvik is something on Daniel Borenstein's "to do" list... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
