[PATCH] On Hurd, don't use not implemented madvise()

[PATCH] On Hurd, don't use not implemented madvise()

[manolis837]

From: Manolis Ragkousis <manolis837@gmail.com>

On Hurd, because madvise() is not implemented we disable it.

* libguile/vm.c (return_unused_stack_to_os): Don't use madvise() on Hurd.
---
 libguile/vm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libguile/vm.c b/libguile/vm.c
index 18f219249..7089f23c7 100644
--- a/libguile/vm.c
+++ b/libguile/vm.c
@@ -896,6 +896,8 @@ return_unused_stack_to_os (struct scm_vm *vp)
 
   /* Return these pages to the OS.  The next time they are paged in,
      they will be zeroed.  */
+#if !defined __gnu_hurd__
+  /* madvise() is not implemented on GNU Hurd. */
   if (lo < hi)
     {
       int ret = 0;
@@ -907,7 +909,7 @@ return_unused_stack_to_os (struct scm_vm *vp)
       if (ret)
         perror ("madvise failed");
     }
-
+#endif
   vp->sp_min_since_gc = vp->sp;
 #endif
 }
-- 
2.13.0

Re: [PATCH] On Hurd, don't use not implemented madvise()

[Mark H Weaver]

Hi Manolis,

manolis837@gmail.com writes:

> From: Manolis Ragkousis <manolis837@gmail.com>
>
> On Hurd, because madvise() is not implemented we disable it.
>
> * libguile/vm.c (return_unused_stack_to_os): Don't use madvise() on Hurd.
> ---
>  libguile/vm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libguile/vm.c b/libguile/vm.c
> index 18f219249..7089f23c7 100644
> --- a/libguile/vm.c
> +++ b/libguile/vm.c
> @@ -896,6 +896,8 @@ return_unused_stack_to_os (struct scm_vm *vp)
>  
>    /* Return these pages to the OS.  The next time they are paged in,
>       they will be zeroed.  */
> +#if !defined __gnu_hurd__
> +  /* madvise() is not implemented on GNU Hurd. */
>    if (lo < hi)
>      {
>        int ret = 0;
> @@ -907,7 +909,7 @@ return_unused_stack_to_os (struct scm_vm *vp)
>        if (ret)
>          perror ("madvise failed");
>      }
> -
> +#endif
>    vp->sp_min_since_gc = vp->sp;
>  #endif
>  }

Is there a test we could perform at run-time to discover whether
madvise() is implemented?  If so, that would be greatly preferable.

I assume that madvise() will be implemented in the Hurd at some point.
When that happens, we'll want to implement a run-time test in Guile,
because this is important functionality for Guile users that we will
want to use as soon as it becomes available, but in practice there will
continue to be some users who run an old version of the Hurd.

Since we can already foresee wanting to implement the run-time test in
the future, we might as well do it now, which would have an added
benefit: it would mean that when the Hurd gains madvise() support,
existing versions of Guile will immediately be able to use it.

What do you think?

    Regards,
      Mark

Re: [PATCH] On Hurd, don't use not implemented madvise()

[Manolis Ragkousis]

Hello Mark :)

On 05/30/2017 10:41 PM, Mark H Weaver wrote:
> Is there a test we could perform at run-time to discover whether
> madvise() is implemented?  If so, that would be greatly preferable.
> 
Well madvise() on Hurd is a glibc no-op that fails with errno = ENOSYS.
Maybe I could allow madvise to run once and if it fails set a global
static variable called madvise_implemented to 0 (by default 1) and use
this to stop it from running again. WDYT?

Also from my understanding not using madvise() ends up in slower
performance but it doesn't create problems to the program, right?
Because in this case, it stills compiles guile, the problem is that it
continuously spams "madvise failed: Function not implemented". I could
make it not print it when errno = ENOSYS. WDYT?

Thank you,
Manolis

Re: [PATCH] On Hurd, don't use not implemented madvise()

[Mark H Weaver]

Manolis Ragkousis <manolis837@gmail.com> writes:

> On 05/30/2017 10:41 PM, Mark H Weaver wrote:
>> Is there a test we could perform at run-time to discover whether
>> madvise() is implemented?  If so, that would be greatly preferable.
>> 
> Well madvise() on Hurd is a glibc no-op that fails with errno = ENOSYS.
> Maybe I could allow madvise to run once and if it fails set a global
> static variable called madvise_implemented to 0 (by default 1) and use
> this to stop it from running again. WDYT?

I don't see the need for the global static variable, because it should
be quite cheap to call madvise and get ENOSYS, and this shouldn't happen
very often.  So I think we can just ignore the ENOSYS result on Hurd.

> Also from my understanding not using madvise() ends up in slower
> performance but it doesn't create problems to the program, right?

Some programs for Guile 2.2 may take advantage of the dynamically
expandable stacks, because it allows programs to written in a more
natural way.  Such programs may in some cases temporarily allocate a lot
of stack space.  If this memory can never be reclaimed on Hurd, that may
cause problems for some programs.

> Because in this case, it stills compiles guile, the problem is that it
> continuously spams "madvise failed: Function not implemented". I could
> make it not print it when errno = ENOSYS. WDYT?

Right, on the Hurd we should silently ignore ENOSYS, but report other
errors.  On non-Hurd systems, I think we should continue reporting the
ENOSYS error as well.

What do you think?  Would you like to propose another patch?

      Regards,
        Mark

Re: [PATCH] On Hurd, don't use not implemented madvise()

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jun 01, 2017 at 07:29:03PM -0400, Mark H Weaver wrote:
> Manolis Ragkousis <manolis837@gmail.com> writes:

[...]

> > Also from my understanding not using madvise() ends up in slower
> > performance but it doesn't create problems to the program, right?
> 
> Some programs for Guile 2.2 may take advantage of the dynamically
> expandable stacks, because it allows programs to written in a more
> natural way.  Such programs may in some cases temporarily allocate a lot
> of stack space.  If this memory can never be reclaimed on Hurd, that may
> cause problems for some programs.

This would at least suggest having a way to query whether madvise is
available, through some introspection (giving the program a chance
to adapt its behavior)?

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkxJFYACgkQBcgs9XrR2kbyNgCeJPtTvHeBJhIgiDHcIfip7aWt
e9kAn3fMsRpzS99+e0szQ7cuGo+X8Q/K
=9/ui
-----END PGP SIGNATURE-----

Re: [PATCH] On Hurd, don't use not implemented madvise()

[Mark H Weaver]

<tomas@tuxteam.de> writes:

> On Thu, Jun 01, 2017 at 07:29:03PM -0400, Mark H Weaver wrote:
>> Manolis Ragkousis <manolis837@gmail.com> writes:
>
> [...]
>
>> > Also from my understanding not using madvise() ends up in slower
>> > performance but it doesn't create problems to the program, right?
>> 
>> Some programs for Guile 2.2 may take advantage of the dynamically
>> expandable stacks, because it allows programs to written in a more
>> natural way.  Such programs may in some cases temporarily allocate a lot
>> of stack space.  If this memory can never be reclaimed on Hurd, that may
>> cause problems for some programs.
>
> This would at least suggest having a way to query whether madvise is
> available, through some introspection (giving the program a chance
> to adapt its behavior)?

First of all, you should read this for background:

  https://wingolog.org/archives/2014/03/17/stack-overflow

If you've done that, then you should understand that this new feature in
guile-2.2 fundamentally changes the way we can express loops in Scheme
that build recursive data structures where scalability is important.

For example, 'map' can now be written like this:

  (define (map f l)
    (if (pair? l)
        (cons (f (car l))
              (map f (cdr l)))
        '()))

whereas we used to have to write code like this in order to support long
lists without overflowing the stack:

  (define (map f l)
    (let loop ((l l) (out '()))
      (if (pair? l)
          (loop (cdr l) (cons (f (car l)) out))
          (reverse out))))

Consider how frequently patterns like this occur.  Do you really want to
duplicate every piece of code with a loop of this form?  It would be
better to just give up on this new feature entirely.

Anyway, even if you did duplicate your code, that would not solve the
problem, because many procedures in Guile itself are now written in the
nicer way to take advantage of this.  One such example is 'map'.

I'm quite fond of the Hurd design, and I hope it continues to grow, but
it's unrealistic to expect developers to write loops like this in a
fundamentally less clear way to cater to an experimental OS that has so
few users.

Does that make sense?

       Mark

Re: [PATCH] On Hurd, don't use not implemented madvise()

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jun 02, 2017 at 10:00:18PM -0400, Mark H Weaver wrote:
> <tomas@tuxteam.de> writes:

[...]

> > This would at least suggest having a way to query whether madvise is
> > available, through some introspection (giving the program a chance
> > to adapt its behavior)?
> 
> First of all, you should read this for background:
> 
>   https://wingolog.org/archives/2014/03/17/stack-overflow

Done.

> If you've done that, then you should understand that this new feature in
> guile-2.2 fundamentally changes the way we can express loops in Scheme
> that build recursive data structures where scalability is important.

[...]

Yes, I got that: in a nutshell, getting the stack auto-extended instead
of being blown out of existence by a segfault or similar.

> Consider how frequently patterns like this occur.  Do you really want to
> duplicate every piece of code with a loop of this form?  It would be
> better to just give up on this new feature entirely.
> 
> Anyway, even if you did duplicate your code, that would not solve the
> problem, because many procedures in Guile itself are now written in the
> nicer way to take advantage of this.  One such example is 'map'.

You are right, duplicating every piece of code doesn't seem to be
a Good Thing.

I rather proposed the introspection for those who want to come up
with whatever other ideas: it might be they'll want to warn the user
right off at the beginning ("uh, oh: no madvise: expect a rough ride",
so they can then segfault without guilt :)

> I'm quite fond of the Hurd design, and I hope it continues to grow, but
> it's unrealistic to expect developers to write loops like this in a
> fundamentally less clear way to cater to an experimental OS that has so
> few users.
> 
> Does that make sense?

It does. As I said, I just proposed that, if Guile decides to use
madvise() dynamically (by "bypassing" ENOSYS -- that's IMO a good idea
anyway), it should give the user a possibility to check for that very
fact ("do we, actually, have an madvise()?"). WDYT?

Cheers
- -- tomás

> 
>        Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkyWhwACgkQBcgs9XrR2kYkSACdE8BsW58sCblJWhv0PSQV7+wO
9vYAnjezj0Fr9jg0I7SJDsJBG2pQhLhK
=wSGI
-----END PGP SIGNATURE-----

Efficiency of `map` (was: [PATCH] On Hurd, don't use not implemented madvise())

[Stefan Monnier]

>   (define (map f l)
>     (if (pair? l)
>         (cons (f (car l))
>               (map f (cdr l)))
>         '()))
>
> whereas we used to have to write code like this in order to support long
> lists without overflowing the stack:
>
>   (define (map f l)
>     (let loop ((l l) (out '()))
>       (if (pair? l)
>           (loop (cdr l) (cons (f (car l)) out))
>           (reverse out))))

Ignoring stack usage, is the first version faster or slower than the second?
[ Or is the speed difference negligible?  ]

How 'bout using a side-effecting `reverse!` (like Lisp's nreverse)?


        Stefan

Re: Efficiency of `map`

[Mark H Weaver]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>   (define (map f l)
>>     (if (pair? l)
>>         (cons (f (car l))
>>               (map f (cdr l)))
>>         '()))
>>
>> whereas we used to have to write code like this in order to support long
>> lists without overflowing the stack:
>>
>>   (define (map f l)
>>     (let loop ((l l) (out '()))
>>       (if (pair? l)
>>           (loop (cdr l) (cons (f (car l)) out))
>>           (reverse out))))
>
> Ignoring stack usage, is the first version faster or slower than the second?
> [ Or is the speed difference negligible?  ]

I don't have time to perform proper benchmarks, but some admittedly
inadequate measurements on my Thinkpad X200 suggest that the first
version is about 1.5% faster, mainly because it makes a lot less work
for the GC.  See below for details of what I did.  

> How 'bout using a side-effecting `reverse!` (like Lisp's nreverse)?

We can't do that, because in the presence of first-class continuations
where the 'f' passed to map may return more than once, using mutation to
build the result list will change the result for some programs.  Both
modern scheme standards (R6RS and R7RS) explicitly specify that "If
multiple returns occur from map, the values returned by earlier returns
are not mutated".

      Mark


mhw@jojen ~$ guile
GNU Guile 2.2.2
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (define (map1 f l) (if (pair? l) (cons (f (car l)) (map f (cdr l))) '()))
scheme@(guile-user)> (define (map2 f l) (let loop ((l l) (out '())) (if (pair? l) (loop (cdr l) (cons (f (car l)) out)) (reverse out))))
scheme@(guile-user)> (define var #f)
scheme@(guile-user)> (define test-list (iota 100000))
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map1 1+ test-list)) (loop (- i 1))))
;; 13.121194s real time, 14.072380s run time.  2.346036s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map1 1+ test-list)) (loop (- i 1))))
;; 13.006867s real time, 13.940452s run time.  2.263353s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map1 1+ test-list)) (loop (- i 1))))
;; 13.079656s real time, 13.946879s run time.  2.197271s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map2 1+ test-list)) (loop (- i 1))))
;; 13.029591s real time, 15.312230s run time.  5.601020s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map2 1+ test-list)) (loop (- i 1))))
;; 13.041985s real time, 15.306287s run time.  5.581253s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map2 1+ test-list)) (loop (- i 1))))
;; 12.003391s real time, 13.421369s run time.  3.662504s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map2 1+ test-list)) (loop (- i 1))))
;; 11.993404s real time, 13.367805s run time.  3.496328s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map2 1+ test-list)) (loop (- i 1))))
;; 11.964659s real time, 13.362942s run time.  3.544227s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map1 1+ test-list)) (loop (- i 1))))
;; 12.619559s real time, 13.153612s run time.  1.471917s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map1 1+ test-list)) (loop (- i 1))))
;; 12.600161s real time, 13.136094s run time.  1.476574s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map1 1+ test-list)) (loop (- i 1))))
;; 12.584059s real time, 13.142257s run time.  1.478289s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map1 1+ test-list)) (loop (- i 1))))
;; 12.626346s real time, 13.146946s run time.  1.466499s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map2 1+ test-list)) (loop (- i 1))))
;; 12.009064s real time, 13.361389s run time.  3.690290s spent in GC.
scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set! var (map2 1+ test-list)) (loop (- i 1))))
;; 11.970217s real time, 13.317716s run time.  3.352065s spent in GC.
scheme@(guile-user)> 

Here are the 4 best times for each procedure:

map1:
;; 12.619559s real time, 13.153612s run time.  1.471917s spent in GC.
;; 12.600161s real time, 13.136094s run time.  1.476574s spent in GC.
;; 12.584059s real time, 13.142257s run time.  1.478289s spent in GC.
;; 12.626346s real time, 13.146946s run time.  1.466499s spent in GC.

averages of 4 best times:
;; 12.607531s real time, 13.144727s run time.  1.473320s spent in GC.


map2:
;; 12.009064s real time, 13.361389s run time.  3.690290s spent in GC.
;; 11.993404s real time, 13.367805s run time.  3.496328s spent in GC.
;; 11.964659s real time, 13.362942s run time.  3.544227s spent in GC.
;; 11.970217s real time, 13.317716s run time.  3.352065s spent in GC.

averages of 4 best times:
;; 11.984336s real time, 13.352463s run time.  3.520728s spent in GC.

Re: Efficiency of `map`

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 5909 bytes --]

Hi Mark!
Do you have any advice to optimize it without disable GC temperaly? Or the
only way is to change a better GC?

2017年6月10日 12:28，"Mark H Weaver" <mhw@netris.org>写道：

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >>   (define (map f l)
> >>     (if (pair? l)
> >>         (cons (f (car l))
> >>               (map f (cdr l)))
> >>         '()))
> >>
> >> whereas we used to have to write code like this in order to support long
> >> lists without overflowing the stack:
> >>
> >>   (define (map f l)
> >>     (let loop ((l l) (out '()))
> >>       (if (pair? l)
> >>           (loop (cdr l) (cons (f (car l)) out))
> >>           (reverse out))))
> >
> > Ignoring stack usage, is the first version faster or slower than the
> second?
> > [ Or is the speed difference negligible?  ]
>
> I don't have time to perform proper benchmarks, but some admittedly
> inadequate measurements on my Thinkpad X200 suggest that the first
> version is about 1.5% faster, mainly because it makes a lot less work
> for the GC.  See below for details of what I did.
>
> > How 'bout using a side-effecting `reverse!` (like Lisp's nreverse)?
>
> We can't do that, because in the presence of first-class continuations
> where the 'f' passed to map may return more than once, using mutation to
> build the result list will change the result for some programs.  Both
> modern scheme standards (R6RS and R7RS) explicitly specify that "If
> multiple returns occur from map, the values returned by earlier returns
> are not mutated".
>
>       Mark
>
>
> mhw@jojen ~$ guile
> GNU Guile 2.2.2
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (define (map1 f l) (if (pair? l) (cons (f (car l))
> (map f (cdr l))) '()))
> scheme@(guile-user)> (define (map2 f l) (let loop ((l l) (out '())) (if
> (pair? l) (loop (cdr l) (cons (f (car l)) out)) (reverse out))))
> scheme@(guile-user)> (define var #f)
> scheme@(guile-user)> (define test-list (iota 100000))
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1))))
> ;; 13.121194s real time, 14.072380s run time.  2.346036s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1))))
> ;; 13.006867s real time, 13.940452s run time.  2.263353s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1))))
> ;; 13.079656s real time, 13.946879s run time.  2.197271s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1))))
> ;; 13.029591s real time, 15.312230s run time.  5.601020s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1))))
> ;; 13.041985s real time, 15.306287s run time.  5.581253s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1))))
> ;; 12.003391s real time, 13.421369s run time.  3.662504s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1))))
> ;; 11.993404s real time, 13.367805s run time.  3.496328s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1))))
> ;; 11.964659s real time, 13.362942s run time.  3.544227s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1))))
> ;; 12.619559s real time, 13.153612s run time.  1.471917s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1))))
> ;; 12.600161s real time, 13.136094s run time.  1.476574s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1))))
> ;; 12.584059s real time, 13.142257s run time.  1.478289s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map1 1+ test-list)) (loop (- i 1))))
> ;; 12.626346s real time, 13.146946s run time.  1.466499s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1))))
> ;; 12.009064s real time, 13.361389s run time.  3.690290s spent in GC.
> scheme@(guile-user)> ,time (let loop ((i 1000)) (when (positive? i) (set!
> var (map2 1+ test-list)) (loop (- i 1))))
> ;; 11.970217s real time, 13.317716s run time.  3.352065s spent in GC.
> scheme@(guile-user)>
>
> Here are the 4 best times for each procedure:
>
> map1:
> ;; 12.619559s real time, 13.153612s run time.  1.471917s spent in GC.
> ;; 12.600161s real time, 13.136094s run time.  1.476574s spent in GC.
> ;; 12.584059s real time, 13.142257s run time.  1.478289s spent in GC.
> ;; 12.626346s real time, 13.146946s run time.  1.466499s spent in GC.
>
> averages of 4 best times:
> ;; 12.607531s real time, 13.144727s run time.  1.473320s spent in GC.
>
>
> map2:
> ;; 12.009064s real time, 13.361389s run time.  3.690290s spent in GC.
> ;; 11.993404s real time, 13.367805s run time.  3.496328s spent in GC.
> ;; 11.964659s real time, 13.362942s run time.  3.544227s spent in GC.
> ;; 11.970217s real time, 13.317716s run time.  3.352065s spent in GC.
>
> averages of 4 best times:
> ;; 11.984336s real time, 13.352463s run time.  3.520728s spent in GC.
>
>

[-- Attachment #2: Type: text/html, Size: 6705 bytes --]

Re: Efficiency of `map`

[Mark H Weaver]

Nala Ginrut <nalaginrut@gmail.com> writes:
> Do you have any advice to optimize it without disable GC temperaly?

Temporarily disabling the GC would merely postpone reclamation work that
needs to be done eventually, and at the risk of allocating a potentially
huge amount of garbage while the GC is disabled, in the worst case.
Sounds like a bad idea to me.

If I knew how to make our 'map' faster, I would do it.  Andy rewrote the
versions of 'map' in boot-9 and srfi-1 to take advantage of the
expanding stacks, and he seems quite skilled at writing efficient code.
I have no reason to think I could do better, and no spare time to make
the attempt.

> Or the only way is to change a better GC?

I don't know how to make Boehm GC faster without making it more
difficult to write C code that manipulates heap objects, and without
adding more restrictions on the use of existing C libraries.

      Mark

[PATCH] On Hurd, silently ignore ENOSYS for madvise().

[manolis837]

Hello Mark,

Sorry for the long delay.

This is the updated patch. It simply ignores ENOSYS caused by madvise() on Hurd.
Nothing else is affected from this change.

Thank you for your help,
Manolis

[PATCH] On Hurd, silently ignore ENOSYS for madvise().

[manolis837]

From: Manolis Ragkousis <manolis837@gmail.com>

madvise() is not implemented on Hurd.
See <https://lists.gnu.org/archive/html/guile-devel/2017-06/msg00001.html>.

* libguile/vm.c (return_unused_stack_to_os): Ignore madvise() related
  ENOSYS on Hurd.
---
 libguile/vm.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/libguile/vm.c b/libguile/vm.c
index 18f219249..0daeb5154 100644
--- a/libguile/vm.c
+++ b/libguile/vm.c
@@ -904,8 +904,14 @@ return_unused_stack_to_os (struct scm_vm *vp)
         ret = madvise ((void *) lo, hi - lo, MADV_DONTNEED);
       while (ret && errno == -EAGAIN);
 
+#if defined __gnu_hurd__
+      /* On Hurd ignore ENOSYS, madvise is not supported.*/
+      if (ret && errno != ENOSYS)
+        perror ("madvise failed");
+#else
       if (ret)
         perror ("madvise failed");
+#endif
     }
 
   vp->sp_min_since_gc = vp->sp;
-- 
2.13.0