[Mono-dev] GC.Collect() CLR<>Mono difference.

[BGB]

  ----- Original Message ----- 
  From: Rodrigo Kumpera 
  To: BGB 
  Cc: mono-devel-list 
  Sent: Friday, January 09, 2009 6:44 AM
  Subject: Re: [Mono-dev] GC.Collect() CLR<>Mono difference.





  On Thu, Jan 8, 2009 at 6:05 PM, BGB <cr88192 at hotmail.com> wrote:


    ----- Original Message -----
    From: "Sunny" <sloncho at gmail.com>
    To: <mono-devel-list at lists.ximian.com>
    Sent: Friday, January 09, 2009 3:50 AM
    Subject: Re: [Mono-dev] GC.Collect() CLR<>Mono difference.


    > On Thu, Jan 8, 2009 at 11:45 AM, Sunny <sloncho at gmail.com> wrote:
    >>
    >> According to this:
    >> <http://msdn.microsoft.com/en-us/library/system.weakreference(VS.80).aspx>
    >>
    >> IsAlive becomes false after the finalizer is done. It may be so, that
    >> under mono your call to IsAlive is made before the finalizer is
    >> called. Try with GC.WaitForPendingFinalizers() before the check.
    >>
    >
    > Hmmm, I just tried it under mono, it still outputs True. Looks like a bug.
    >


    possible factor:
    references to 'obj' still exist, and are lingering on the stack, ...

    so, with a precise GC, the only reference which can exist is the weak
    reference;
    but with a conservative GC (such as Boehm), any lingering references are
    still good.

    (note: it appears to me like the project is implementing / has implemented
    an optional precise GC, but I don't know the status, ...).


    so, the GC runs, and maybe it finds a reference still on the stack
    somewhere?...
    ok then, the object is not collected, and thus no need for the weak ref to
    report a change...


    I could be wrong though...




  You are correct, this is exactly what happens on this case. The object still reachable to the conservative GC mono uses.
  Our precise GC is still in development.


just wondering:

will the precise GC also implement ref-counting?...

sorry, I have not looked into the details of 'SGEN' much...


at least when I have written precise GC's, refcounting is a very effective way at reducing the total amount of garbage, and thus making GC cycles more rare (IMO, the overhead of adjusting the counts is usually paid for by the drastic reduction in time spent doing garbage collection and other things, although another trick is that of finding elaborate ways to sidestep needing to adjust the ref-counts...).

so, anymore, usually whenever I implement precise garbage collectors, I also include reference counts. in my case, this was usually stored as a few bits in either the cell bitmap, but object headers could be another good place (anywhere where one can spare a few bits).

of course, there is always the major drawback of ref-counts:
it may often be a good deal of effort to make sure an entire codebase if ref-count safe (or, at least, those parts which may directly interact with the precise GC), but alas, this does not add too much vs the overhead of making it precise-GC safe...


now, I had considered adding a set of precise features to my existing GC (I had actually written out an idea spec for this, mostly documenting additions to the API, ...).

primarily, this would take the form of a modified set of API calls for working with values, and specially coded values for precise references (a partial reason for this being actually to obscure the references from the conservative parts of the GC, which may then see them as something analogous to fixnums or flonums).

another use is for the precise code to be "backwards compatible" with conservative references (only precise references get the precise treatment, conservative references behave just like before).

sadly, all this will involve partly fragmenting the API (adding "precise" versions of many operations).

note that it would also be able to make a conservative reference to a formerly precise object (I will call this the "defile" operation, as it will cause the object itself to change status, at least until all the conservative references dissappear).

note that, in most cases, conservative operations could still be used, but would tend to automatically defile precise objects (otherwise, the API could be left fragmented, with all defile operations needing to be done explicitly).

a related operation: "undefile", could make a potentially precise reference to a currently defiled object, thus speeding its return to an 'undefiled' state (by more quickly getting conservative references out of the system). note that this will be no-op for plain conservative objects (the undefiled reference is simply the good old pointer, as before...).


note that the reason for having both is that, admittedly, precise GC is a pain to work with, and so could be limited mostly to the core systems and any other code where it actually matters.

in many other places, such as off in ordinary C land, the continued usage of conservative object handling is likely to remain being the default (it is just SO much more convinient...).

this is actually the main reason I am using conservative GC at this point:
I have used precise GC a lot in the past, but for large-scale usage it just becomes too damn inconvinient, but I also sort of miss the advantages it offers...


actually, technically, in the compiler core it is likely to be the case that it will depend more on representation, for example, the '__variant' type may become precise, but any usage of conventional pointers will be conservative, and so attempting to convert a variant to a pointer will implicitly perform a "defile" operation, and doing the reverse may do an "undefile" operation (which may also be used as a good place to insert a check and raise an exception if one tries to pull a fast one and give a pointer to unmanaged memory back to the GC...).

this would also make it reasonably convinient to use precise GC in C, or at least when it is being compiled with my tools...

[note: my use of "variant" differs some from the CLI definition, where mine is by default open-ended, and will only become a specific type if the compiler can determine that it will only ever hold that type...].


I am not sure if anything similar to this could also be applied to Mono...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090109/ae955838/attachment-0001.html