[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] mprotect question
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] mprotect question |
Date: |
05 Sep 2003 09:44:24 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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