Re[4]: [Gc] win32 special treatment in GC_add_roots and GC_remove_roots codepaths

Ivan Maidanski ivmai at mail.ru
Sat Mar 9 23:37:44 PST 2013


 Hi Bruce and Jonathan,

Note about push_other_roots: setter/getter is already a part of public API (in 7.3)

>> We (Unity3D) have been running mono using the described change, basically
Which one? Have I missed some patch?

>> registration/deregistration of roots. Under Windows roots were only being
>> added, eventually reaching the "Too many root sets" assertion.
Here, you are talking about missing GC_remove_roots for Win32, right?

As a variant, we could implement overlap counter and allow GC_remove_roots for Win32, so that e.g., calling GC_add_root(b,e) twice requires GC_remove_roots(b,e) twice called before the root is really removed.

>> 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?

I'm not aware of it. I have never altered algorithm of adding/removing roots. The code (both for Win32 and not) has been contributed before gc4.1 - this is out of Git/CVS history (probably, Hans could grep his email archive), thus I can't refer to the real author. As I understand we could you single implemention for all platforms based on a balanced tree (instead of hashmap and list used now for Unix and Win32, respectively).

Regards,
Ivan

Fri,  8 Mar 2013, 16:39 +13:00 from Bruce Hoult <bruce at hoult.org>:
>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130310/8e57413b/attachment-0001.htm


More information about the Gc mailing list