Concurrent, compacting GC for GO

[Max]

I seen that paid JVM 

http://www.azulsystems.com/products/zing/whatisit 

I wonder if Concurrent, compacting GC for GO is possible?

[Aram Hăvărneanu]

> I wonder if Concurrent, compacting GC for GO is possible?

Not with cgo and/or unsafe. In a restricted environment like App
Engine, perhaps, though I doubt it will ever happen because having to
maintain two CG implementations is not a thing to strive for,

--
Aram Hăvărneanu

[Ian Lance Taylor]

An unsafe.Pointer could be automatically pinned, in the sense that the
GC would not be permitted to move it. And a pointer passed to a cgo
routine could be pinned while the cgo routine was active. There would
have to be a runtime function to pin pointers passed to cgo in ways
that the GC could not see.

Of course it would still be a lot of work, as it would require
complete type annotations of stack frames, something we do not have
right now. But I think it would be possible in principle.

Ian

[Henrik Johansson]

+1

Is there any work going on or is it on a wish list only?

/ Henrik

[Ian Lance Taylor]

On Thu, Aug 2, 2012 at 9:24 AM, Henrik Johansson <dahan...@gmail.com> wrote:
> +1
>
> Is there any work going on or is it on a wish list only?

I'm not aware of anybody working on this.

Ian

[Kosztka Imre Dávid]

+1

2012/8/2 Ian Lance Taylor <ia...@google.com>:

--
Name : Kosztka Imre Dávid
E-mail: kosz...@gmail.com
Phone number: +36309213462
Mailing address: H-3700, Hungary Kazincbarcika Szeder utca 2.

[Dmitry Vyukov]

Implementation complexity aside, note that concurrent compacting GC is not a win-win. Is slows down code execution due to read/write barriers. The GC is also slower due to the barriers, object movement and pointer patching.

[Henrik Johansson]

Isn't the concurrent compaction basically to scale the heap to crazy sizes?
Stop the world takes too long I imagine in my limited knowledge of the
internals.

There are surely complexities and drawbacks to all approaches but why
not provide a compiler switch (or runtime whatever works) to
control which GC you want?

/ Henrik

[Dmitry Vyukov]

On Aug 3, 2012 1:26 PM, "Henrik Johansson" <dahan...@gmail.com> wrote:
>
> Isn't the concurrent compaction basically to scale the heap to crazy sizes?
> Stop the world takes too long I imagine in my limited knowledge of the
> internals.
>
> There are surely complexities and drawbacks to all approaches but why
> not provide a compiler switch (or runtime whatever works) to
> control which GC you want?

I think that's because there is only one GC impl in Go right now...

[Henrik Johansson]

Ye ofc :) I was just pondering the future.