Re[6]: [Gc] There should be a library major bump of gc library due to now having several GC_xyz "hidden" functions

Ivan Maidanski ivmai at mail.ru
Sun May 27 04:43:26 PDT 2012


Hi Juan,

Sun, 27 May 2012 12:53:16 +0200 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>:
> 
> On Sun, May 27, 2012 at 11:17 AM, Ivan Maidanski <ivmai at mail.ru> wrote:
> 
> Could you suggest some solution for the issue for 7.2 and/or for 7.3+?
> 
> Definitely it is not something that _I_ can solve, for it is up to the library to decide what API it wishes to export -- this will have consequences for future releases.

It's ok to change API to tailor clients demand.

> I can only provide a list of functionality that ECL relies on

Good.

> - In general, functions which are GC_EXTERN in gc_priv.h justify that this header is *always* installed.

There's no functions marked with GC_EXTERN as the latter is applicable to variables only (and means "extern" to other BDWGC modules not to outside).

> - GC_push_other_roots is used by ECL because it knows a set of dynamically changing roots. Note, however, that in order to push those roots GC_push_conditional() is needed, but this is not exported.
> 
> - typd_mlc.c is part of the garbage collector but it is not initialized. It even doesn't have a declaration for GC_init_explicit_typing() which is needed by ECL to implement a 2nd method of precise marking.
> 
> - In gc_mark.h there should also live GC_push_conditional() and GC_set_mark_bit() because sometimes one does not need to mark _all_ of an object. For instance, when ECL marks an array, it does not rely on the BWDGC to do so, because it may know that part of the array is empty or full of meaningless data. In this case we do something like
> 
>  GC_push_conditional((void *)env->stack, (void *)env->stack_top, 1);
>  GC_set_mark_bit((void *)env->stack);
> This is critical for performance and to avoid accidental data retention.
> 
> Probably this should be enough, but I fear that none of these changes will propagate to the problematic distributions unless the library suffers a formal release.

What's normal? gc-7.2b is such or not?

>From our side, we can prepare gc-7.2c with the required fixes unhiding symbols you mentioned (could somebody prepare a patch?) and also move them to public API in gc-7.3alpha.

Regards,
Ivan

> Juanjo
> 
> -- 
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain) 
> http://juanjose.garciaripoll.googlepages.com
>        
>   



More information about the Gc mailing list