Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Fri, Jan 24, 2020 at 10:22 AM Hans Åberg <address@hidden> wrote:
>
>> >> Boehm GC can work in a background thread I think.  And Guile-v2
>> >> applications typically just let all their data be treated as pointers
>> >> rather than using a smob-marking algorithm like we do, and it is
>> >> conceivable that Boehm GC's individual mark function does not scale.
>> >>
>> >
>> > Do you mean our mechanism to call user-defined mark functions? I doubt
>> that
>> > there are obvious BGC scalability problems in BGC's mark functoin.
>>
>> The Boehm GC collects in separate threads, however, when the program is
>> threaded, it puts locks around every allocation, which is very time
>> consuming
>>
>
> Are you sure? Multithreaded memory management usually has per-thread
> strategies to avoid contention. Locking by itself is very cheap unless
> there is contention. The docs I can find are
>
> https://www.hboehm.info/gc/scale.html
>
> but it talks about a 500Mhz Pentium 3 as the benchmark platform, so it's
> probably out of date.

Last time I looked, Guile 2 switched the BGC into Java collection
semantics where it finishes one mark pass (including user-defined hooks)
before it commences to collecting stuff marked with it and calling its
(equivalent of) destructors.  That prevents the mark hooks continuing to
get called after the C++ destructor already ran.  That is somewhat more
synchronised than its default manner of operating.

-- 
David Kastrup