alibaba / PhotonLibOS

Probably the fastest coroutine lib in the world!

Home Page:https://PhotonLibOS.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Making Photon work with GC

lihuiba opened this issue · comments

Turned out libc functions work great with Photon, it was the Boehm GC (libgc) that was causing segfaults. Making Photon work with GC is the only thing left to be done.

Stackful coroutines have their own stacks with dynamic sizes, such behavior makes it hard for the GC to detect alive objects. Does photon have a way to register coroutine stacks and let the GC know about context switching?

As I understand, Boehm GC has a way to let know about a new stack during context switching, but I didn't find this feature in Photon...

Originally posted by @medvednikov in #148 (comment)

@medvednikov take look at this

Great, thanks! Will do.

Hey,

Just wanted to give you an update.

We managed to successfully make Photon work in V with the Boehm GC by using the recently introduced set_photon_thread_stack_allocator.

The change turned out to be very simple:
vlang/v@9604a3f

So thanks a lot for that! This surely made Photon a great option for all GC languages.

@medvednikov

Glad to know it's working.

And I didn't expect that the allocator could be implemented in V. It's really cool!

@lihuiba Thanks for all the assistance. I was surprised how easy it was to add support (using the functions you provided).

Regarding the allocator, I did try using the default allocator and also the stackful_malloc function provided, however I kept getting segfaults.

our malloc uses the GC malloc (when GC is on), so Im guessing if we were to use another allocator we may need to provide some extra information to the GC as well as the roots. I'm not sure though, that is just a guess. Or perhaps I have to correct for page size when supplying the roots due to the alignment your allocator does.

@joe-conigliaro the stackful_malloc is intended for efficient context allocation in stackless coroutine, such as the one in C++20. It assumes a FILO order of allocation and deallocation. It is NOT a generic allocator.

Thanks for the reply @lihuiba, I had a feeling it was used for something like that due to the comment

Amazing news!