headers
Ivan Maidanski | 27 May 2012 11:17
Picon

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

Hi Juan,

Sun, 27 May 2012 11:11:13 +0200 Juan Jose Garcia-Ripoll <juanjose.garciaripoll@...>:
> On Sun, May 27, 2012 at 7:34 AM, Ivan Maidanski <ivmai@...> wrote:
> 
> > GC_set_mark_bit is already a part of public API (since 7.3)
> > It is possible to make various GC_push_xxx to be public too, I think.
> 
> 
> I am sorry I missed this thread which matches the bug report from Paulo,
> but he is right: the GC_INNER feature has broken this Common Lisp
> implementation (and perhaps some other software) in platforms where the
> Boehm-Weiser garbage collector is installed as a shared library. Note that
> this cannot be solved in the application side, because the GC_DLL is
> decided by the package distributors, not by the applications that use them.
> 
> Just to set up some context, ECL needs those functions (GC_set_mark_bit,
> GC_push_conditional, ...) because it registers marking functions with the
> Boehm-Weiser library. If those symbols are not exported and the private
> header is not installed, then the plug-in part of the Boehm-Weiser library
> does not make any sense, because the user cannot really implement any
> customized marking code.

Could you suggest some solution for the issue for 7.2 and/or for 7.3+?
Thank you.

Regards,
Ivan

>
(Continue reading)

Permalink | Reply |
headers
Juan Jose Garcia-Ripoll | 27 May 2012 12:53

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

On Sun, May 27, 2012 at 11:17 AM, Ivan Maidanski <ivmai-JGs/UdohzUI@public.gmane.org> 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.

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

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

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

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Permalink | Reply |

Gmane