Andy Wingo skribis:
> On Fri 02 Dec 2011 23:17, l...@gnu.org (Ludovic Courtès) writes:
>
>>> For that reason I defaulted scm_install_gmp_memory_functions to 1.
>>
Could you make it SCM_INTERNAL instead of SCM_API?
>>>
>>> Sure, but you don't want to allow users to set it?
>>
>> I’d say no, b
On Fri 02 Dec 2011 23:17, l...@gnu.org (Ludovic Courtès) writes:
>> For that reason I defaulted scm_install_gmp_memory_functions to 1.
>
>>> Could you make it SCM_INTERNAL instead of SCM_API?
>>
>> Sure, but you don't want to allow users to set it?
>
> I’d say no, because that will fail gracelessl
Hello!
Andy Wingo skribis:
> On Fri 02 Dec 2011 18:02, l...@gnu.org (Ludovic Courtès) writes:
>
>> I guess scm_gc_register_collectable_memory could be
>> changed to just call it, ignoring its first argument?
>
> Done.
Thanks!
>>> I made scm_realloc call scm_gc_register_allocation. I also inst
Heya,
On Fri 02 Dec 2011 18:02, l...@gnu.org (Ludovic Courtès) writes:
> I guess scm_gc_register_collectable_memory could be
> changed to just call it, ignoring its first argument?
Done.
>> I made scm_realloc call scm_gc_register_allocation. I also installed
>> custom gmp allocators that call
Hello!
Andy Wingo skribis:
> On Sun 27 Nov 2011 22:25, l...@gnu.org (Ludovic Courtès) writes:
>
>> A longer term option may be to augment libgc with something akin to our
>> old scm_gc_register_collectable_memory.
>
> This is also necessary, as it turns out. I added
> scm_gc_register_allocation
On Sun 27 Nov 2011 22:25, l...@gnu.org (Ludovic Courtès) writes:
> A longer term option may be to augment libgc with something akin to our
> old scm_gc_register_collectable_memory.
This is also necessary, as it turns out. I added
scm_gc_register_allocation, which will simply run a GC every so of
Howdy!
Andy Wingo skribis:
> On Tue 29 Nov 2011 14:18, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo skribis:
>>
>>> On Tue 29 Nov 2011 12:06, l...@gnu.org (Ludovic Courtès) writes:
>>>
Could you run the stuff under gc-benchmarks/ with and without the
heuristic, as in [0]?
>>
Greets,
On Tue 29 Nov 2011 14:18, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribis:
>
>> On Tue 29 Nov 2011 12:06, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Could you run the stuff under gc-benchmarks/ with and without the
>>> heuristic, as in [0]?
>>>
>>> [0] http://thread.gmane.
Andy Wingo skribis:
> On Tue 29 Nov 2011 12:06, l...@gnu.org (Ludovic Courtès) writes:
[...]
>> I tried to reproduce the infamous iconv issue, which would have been a
>> simple way to check, but failed:
>>
>> (with-fluids ((%default-port-encoding "UTF-16BE"))
>> (let loop () (open-output-
Hey!
Andy Wingo skribis:
> On Tue 29 Nov 2011 12:06, l...@gnu.org (Ludovic Courtès) writes:
>
>> Could you run the stuff under gc-benchmarks/ with and without the
>> heuristic, as in [0]?
>>
>> [0] http://thread.gmane.org/gmane.lisp.guile.devel/7803
IIRC the “Guile” lines below correspond to wh
On Tue 29 Nov 2011 12:06, l...@gnu.org (Ludovic Courtès) writes:
> Could you run the stuff under gc-benchmarks/ with and without the
> heuristic, as in [0]?
>
> [0] http://thread.gmane.org/gmane.lisp.guile.devel/7803
Adding a FSD=2 entry:
benchmark: `gc-benchmarks/gcbench.scm'
On Tue 29 Nov 2011 12:06, l...@gnu.org (Ludovic Courtès) writes:
> RET should never be left uninitialized, and the caller should be
> prepared to deal with RET == 0.
Oops, will fix.
> (The code itself doesn’t have to #ifdef __linux__ because other OSes
> provides an implementation that mimics Li
Hi Andy!
Andy Wingo skribis:
> On Tue 29 Nov 2011 00:10, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo skribis:
>>
>>> On Sun 27 Nov 2011 22:25, l...@gnu.org (Ludovic Courtès) writes:
>>>
The problem is that this measurement doesn’t allow us to differentiate
between a growing
On Tue 29 Nov 2011 00:10, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribis:
>
>> On Sun 27 Nov 2011 22:25, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> The problem is that this measurement doesn’t allow us to differentiate
>>> between a growing heap with objects that may be freed as a
Andy Wingo skribis:
> On Sun 27 Nov 2011 22:25, l...@gnu.org (Ludovic Courtès) writes:
>
>> The problem is that this measurement doesn’t allow us to differentiate
>> between a growing heap with objects that may be freed as a result of
>> running the GC, and a growing heap just because the applica
On Sun 27 Nov 2011 22:25, l...@gnu.org (Ludovic Courtès) writes:
> The problem is that this measurement doesn’t allow us to differentiate
> between a growing heap with objects that may be freed as a result of
> running the GC, and a growing heap just because the application needs
> more malloc’d o
Hi!
Andy Wingo skribis:
> I still this this is a good idea. The key would be to GC more often
> when the heap image grows faster than GC'd memory is allocated. We can
> detect this situation by computing (ImageSize_t+1 - ImageSize_t) /
> (LiveBytes_t+1 - LiveBytes_t), where ImageSize is some m
Hi,
An old thread, but one that would be good to fix. To recap, Mark Weaver
wrote:
> Without this patch, computing (factorial 10), where factorial is
> implemented using the straightforward iterative approach below, causes
> Guile to allocate a huge amount of memory. This happens because th
Hi,
Andy Wingo skribas:
> What if we get libgc to track total heap size (whether the user has
> malloc, g_slice_alloc, or whatever), and start doing GC more frequently
> if it sees the total heap size going up?
That would be ideal, of course.
Ludo'.
Hey folks,
Thanks for the debugging and the patch, Mark!
On Wed 01 Jun 2011 01:18, Neil Jerram writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribas:
>>
>>> The main reason I haven't already pushed this patch is that there is a
>>> slight complication: when you register c
Neil Jerram writes:
> The application developer would know if they were using GMP other than
> via Guile, and in that case they'd choose to have GMP use GC
> allocation. Alternatively they might know that their application's use
> of GMP/Guile was not such as to generate lots of GMP garbage as t
l...@gnu.org (Ludovic Courtès) writes:
> Hi!
>
> Mark H Weaver skribas:
>
>> The main reason I haven't already pushed this patch is that there is a
>> slight complication: when you register custom allocation functions for
>> use by GMP, they get used for _all_ allocation, not just for digits. In
Hi!
Mark H Weaver skribas:
> This patch changes the way that bignums are allocated, so that digits
> are now allocated using the GC allocation functions instead of standard
> malloc/realloc/free.
>
> Without this patch, computing (factorial 10), where factorial is
> implemented using the str
c (1- n) (* n acc
(fac n 1))
Apologies for the sloppiness,
Mark
>From 2a8c5a5b464f2af723476585f620a108ac1cc37b Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 31 May 2011 15:26:41 -0400
Subject: [PATCH] Configure GMP to use GC allocation functions, remove bignum finali
6:41 -0400
Subject: [PATCH] Configure GMP to use GC allocation functions, remove bignum finalizers
* libguile/numbers.c (custom_gmp_malloc, custom_gmp_realloc,
custom_gmp_free): New static functions used by GMP for allocation.
These are just wrappers for scm_gc_malloc, scm_gc_
25 matches
Mail list logo
