[Gc] win32 special treatment in GC_add_roots and GC_remove_roots codepaths

Bruce Hoult bruce at hoult.org
Thu Mar 7 19:39:46 PST 2013


Note that GC_push_other_roots is in gc_priv.h but's documented as
being intended for user-extension and I think the likes of Mono would
be perfectly entitled to use it.

extern void (*GC_push_other_roots)(void);
  			/* Push system or application specific roots	*/
  			/* onto the mark stack.  In some environments	*/
  			/* (e.g. threads environments) this is		*/
  			/* predfined to be non-zero.  A client supplied */
  			/* replacement should also call the original	*/
  			/* function.					*/


On Fri, Mar 8, 2013 at 12:02 PM, Bruce Hoult <bruce at hoult.org> wrote:
> Just a thought, but it may be that the GCs built in roots management
> is not what you want if you are frequently changing what is considered
> to be "roots".
>
> There is a function pointer hook, GC_push_other_roots, which you can
> point to your own function that walks your own data structures and
> calls GC_push_all on appropriate things. (hopefully not too much to
> overflow the mark stack)
>
> This hook has a default implementation that calls GC_push_all_stacks()
> (when using pthreads or win32 threads), which is necessary, so if you
> replace it then your function should call the old function first.
>
> On Fri, Mar 8, 2013 at 11:14 AM, Jonathan Chambers <joncham at gmail.com> wrote:
>> Hello Ivan,
>>
>> We (Unity3D) have been running mono using the described change, basically
>> following the same code path for all platforms (including Windows). We
>> needed this as our usage of libgc in mono involves frequent
>> registration/deregistration of roots. Under Windows roots were only being
>> added, eventually reaching the "Too many root sets" assertion.
>>
>> I'm just reviewing changes we have made locally, and I am still confused as
>> to what conditions occur on Windows that require special consideration of
>> overlapping roots. Is this just an issue when one is registering the data
>> segments of libraries? Note that we do not do that, and only manually
>> register a handful of roots for internal mono runtime data structures.
>>
>> Thanks,
>> Jonathan
>>
>>
>> On Mon, Sep 19, 2011 at 2:57 AM, Ivan Maidanski <ivmai at mail.ru> wrote:
>>>
>>> Hi Lucas,
>>>
>>> 13 09 2011, 18:25 Lucas Meijer <lucas at lucasmeijer.com>:
>>> > Hi Ivan,  thanks for your reply.
>>> >
>>> > I could take a stab at this, however I don't fully understand the
>>> > problem yet:
>>> >
>>> > GC_remove_roots_inner seems not to do the correct thing when the root
>>> > has been expanded due to the addition of another rootset.
>>> >
>>> > It looks to me that scenario is "not implemented yet" on any platform.
>>> > not just win32.
>>>
>>> We don't need this scenario for non-win32 as we don't "Spend the time to
>>> ensure that there are no overlapping or adjacent intervals." there.
>>>
>>> > Is there any special reason why win32 cannot follow the codepath of line
>>> > 219->225 of mark_rts.c,
>>>
>>> It does not prevent from emerging overlapping areas, and, in case of
>>> win32, it seems it caused significant time waste (I'm not 100% sure of it).
>>>
>>> Regards.
>>>
>>> > and the ifdef of line 299 of mark_rts.c being removed, like all other
>>> > platforms do,
>>> > so at least win32 would get support for unregistering of roots that have
>>> > not been expanded.
>>> >
>>> > (all line numbers from mark_rts.c from master on github)
>>> >
>>> > Bye, Lucas
>>> >
>>> > > Hi Lucas,
>>> > >
>>> > > In short words: it is possible to implement but no one spent his time
>>> > > on it yet.
>>> > > If you feel you could do it - great - send me a patch (against
>>> > > "master" branch).
>>> > >
>>> > > Regards.
>>> > >
>>> > > 13 09 2011, 00:20 Lucas Meijer<lucas at lucasmeijer.com>:
>>> > >> Hi,
>>> > >>
>>> > >> in GC_add_roots_inner there are is a win32 codepath and a nonwin32
>>> > >> codepath
>>> > >> for detecting if there is an overlap/adjacent rootset already
>>> > >> present. if so it
>>> > >> extends the existing rootset to fully include the newly added
>>> > >> rootset.
>>> > >>
>>> > >> GC-remove_roots is not implemented on win32.
>>> > >>
>>> > >> I'm hoping someone can explain why the nonwin32 codepath is required.
>>> > >> On a quick
>>> > >> experiment, making win32 use the nonwin32 codepath, things "seem" to
>>> > >> work fine,
>>> > >> and allow me to unregister roots.
>>> > >>
>>> > >> A message on this mailinglist, Ivan writes:
>>> > >>
>>> > >> "In theory, it's possible to implement GC_remove_roots() for Win32.
>>> > >> But, it is complicated due to overlapping/adjacent regions
>>> > >> processing."
>>> > >>
>>> > >> This statement puzzles me, as the non Win32 codepath also does
>>> > >> overlapped-roots-collapsing, so it would seem to be it would suffer
>>> > >> from the
>>> > >> same problem of unregistering being unsuccessful in the case where
>>> > >> the rootset
>>> > >> has been expanded.
>>> > >>
>>> > >> What is so special about win32?
>>> > >>
>>> > >> Thanks,
>>> > >>
>>> > >>    Lucas
>>> > >>
>>> > >> _______________________________________________
>>> > >> Gc mailing list
>>> > >> Gc at linux.hpl.hp.com
>>> > >> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>> >
>>>
>>> _______________________________________________
>>> Gc mailing list
>>> Gc at linux.hpl.hp.com
>>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> Gc mailing list
>> Gc at linux.hpl.hp.com
>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/


More information about the Gc mailing list