Re: GC performance / alternatives

"bob eob" <[email protected]>
Newsgroups gmane.lisp.scheme.bigloo
Message-ID <trinity-1e295bd9-6a9d-4c18-b0c3-aae930ac17ba-1472395092319@3capp-mailcom-bs04>
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

> Hi everyone,

>

> When I allocate a new object my stack trace inside the Boehm GC gets about 10 functions deep. I assume boehm can&#39;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 &#39;realtime&#39; 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.