Thanks Manuel, I didn't notice the fastest allocations as I was 'profiling' by pressing ctrl+c in gdb.
Sent: Wednesday, August 24, 2016 at 6:02 AM
From: [email protected]
To: "bob eob" <[email protected]>
Cc: [email protected]
Subject: Re: [bigloo] GC performance / alternatives
From: [email protected]
To: "bob eob" <[email protected]>
Cc: [email protected]
Subject: Re: [bigloo] GC performance / alternatives
> Hi everyone,
>
> When I allocate a new object my stack trace inside the Boehm GC gets about 10 functions deep. I assume boehm can't really be made much faster, but I heard the JVM can do this by just bumping a pointer, or something. What gives?
>
> Is the SAW GC I see mentioned in bigloo 4.3 an alternative to Boehm? Apparently Ypsilon scheme has a 'realtime' collector, I wonder how difficult it would be to try that (or something else) wth bigloo.
>
> Thanks,
Hi Bob,
Compiling to C and generating regular C code imposes strong constraints
on the GC. The most significant one, in terms of performance, is that
the collector cannot move objects. This makes the allocation function
more complex than with a copying collector. However, the situation is
not as bad as you describe. For instance, allocating a pair is done by
the function make_pair located in runtime/Clib/inline_alloc.c, its cost
is something like 15~20 assembly instructions (I don't remember
precisely).
We are indeed working on a new collector but we don't know yet if there
will be a speed improvement that will come with that new GC. We are working
on it.
--
Manuel
>
> When I allocate a new object my stack trace inside the Boehm GC gets about 10 functions deep. I assume boehm can't really be made much faster, but I heard the JVM can do this by just bumping a pointer, or something. What gives?
>
> Is the SAW GC I see mentioned in bigloo 4.3 an alternative to Boehm? Apparently Ypsilon scheme has a 'realtime' collector, I wonder how difficult it would be to try that (or something else) wth bigloo.
>
> Thanks,
Hi Bob,
Compiling to C and generating regular C code imposes strong constraints
on the GC. The most significant one, in terms of performance, is that
the collector cannot move objects. This makes the allocation function
more complex than with a copying collector. However, the situation is
not as bad as you describe. For instance, allocating a pair is done by
the function make_pair located in runtime/Clib/inline_alloc.c, its cost
is something like 15~20 assembly instructions (I don't remember
precisely).
We are indeed working on a new collector but we don't know yet if there
will be a speed improvement that will come with that new GC. We are working
on it.
--
Manuel
