I haven't looked at the code in depth, or even tried to run it for that matter.
The docs indicate that MMgc has the capability to call C++ object destructors for object finalization: http://developer.mozilla.org/en/docs/MMgc#GCFinalizedObject which may explain why they chose to roll their own GC instead of using Boehm, since Mozilla is written in C++. Because MMgc is not (yet) threadsafe http://developer.mozilla.org/en/docs/MMgc#Threading I would assume that collection/finalization would have to take place in the same thread during some sort of explicit yield or gc call. But then again, my guesses are not that accurate. :-) --- [EMAIL PROTECTED] wrote: > They may have gone a custom route to avoid certain business relative > issues... Who knows what goes on in their slack times / meetings! From > what you can make of MMgc, does it look worthy? Or is it young and > flightless? > > Lee > > Quoting Joe Wilson <[EMAIL PROTECTED]>: > > > --- Joe Wilson <[EMAIL PROTECTED]> wrote: > >> --- Matt Campbell <[EMAIL PROTECTED]> wrote: > >> > I have taken a cursory look at the Tamarin source tree, and I observe > >> > that Tamarin's GC is in a separate module called MMgc (the MM probably > >> > stands for Macromedia). MMgc is written in C++ and has a C++ API, but > >> > it may still be a useful alternative to Boehm GC. It begs the question > >> > of why Macromedia/Adobe didn't use Boehm GC, given how long that package > >> > has been around. > >> > >> I'm guessing that MMgc is a precise collector. > > > > ...and I guessed wrong - MMgc is a conservative mark/sweep collector: > > > > http://developer.mozilla.org/en/docs/MMgc#Conservative_Collection > > > > go figure. ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 -- Neko : One VM to run them all (http://nekovm.org)
