Re: [Gcl-devel] mprotect question

[Camm Maguire]

Greetings!

Aurelien Chanudet <address@hidden> writes:

> > OK, I think this approach might lead you into trouble, and explain
> the
> > slow times and (if I remember) large image sizes you were reporting.
> 
> What's the size of saved_ansi_gcl on Debian for instance ?
> 

This is what I got for the 2.5.3 Debian ppc build:

-rwxr-xr-x root/root  10865848 2003-07-08 01:59:22
 ./usr/lib/gcl-2.5.3/unixport/saved_ansi_gcl



> > There are bacially two memory paradigms in GCL, garbage collection
> > (GBC) and malloc/free.  The arguments in favor of one or the other
> > have been tossed about for years.  In any case, it is expected of
> lisp
> > systems to have automatic GBC memory management.
> 
> > But GCL can use some third party libraries, like gmp, which in turn
> > use malloc/free.  So it simulates these calls *on top of* the GBC
> > mechanism by making a malloc list, and entering a 'mark origin' for
> > this list.  All such memory blocks will be typed as 'contiguous'
> > pages, one of the ~ 30 types GCL currently supports.  All such
> blocks
> > will also be completely marked at GBC time until explicitly freed.
> > Therefore, if your alloc_object (i.e. non-third party library lisp
> > object allocation) goes through malloc, these pages will never be
> > freed, and the garbage will never be collected. => big and slow, and
> > possible memory exhaustion.
> 
> My apologies, I think I didn't get myself clear enough. The memory
> management scheme I have is really the same as what you've just
> described
> here with these third party calls implemented on top of the GBC
> mechanism.
> I have NOT touched alloc_object. What I meant was that the storage for
> such third party calls is backed by the big vm area allocated upon
> initialization, since the storage for the GBC mechanism is backed by
> the
> same big vm area.
> 

OK, if I understand you, you've just replaced sbrk with your 'vm area'
mechanism, and that as in generic GCL, malloc is on top of GBC which
is on top of sbrk/'vm area'.  This should be OK.

> Can I infer from what you say that contiguous pages will never be
> subject
> to page protection changes ?
> 

In recent GCL, we've added support for SGC contiguous pages.  Existing
pages of this sort can be marked read-only at SGC start, and then
read-write if the running code attempts a write.  Pages alloced via
malloc are marked PERM_WRITABLE, sidestepping this mechanism.  I don't
know why as yet, but that's what was in there when I started work on
the project and I haven't changed it.  I also haven't investigated
where possible alloc_contblock calls outside of malloc/PERM_WRITABLE
can occur, but it should be straightforward.

> > SGC is an optional performance feature as you state.  The idea is
> that
> > some systems have large *static* data sets, and the system just
> wastes
> > time passing these pages through GBC.  So mark these pages read
> only,
> > GBC a much smaller frequently changing set of pages, and when the
> odd
> > write happens to the static page, mark it read write and schedule it
> > for GBC marking too.
> 
> It's all clear now, thanks.
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah