llvm dev - Jul 2021 - How can I use llvm statepoints in a language where some objects are allocated statically and are never collected?

I am the developer of a compiler frontend that generates llvm IR. The
language is garbage collected, but currently doesn't have any support for
stack maps yet, which severely limits the places where garbage collection
can occur.

I would like to fix this, and am familiar with the documents online
relating to gc strategies and statepoints in llvm. However, it seems much
of the support for state points is dependent on the assumption that
references are never passed to unmanaged functions, and you never have a
pointer that might be garbage collected, or might not be, and you don't
know at compile time.

Our language violates both of these constraints. There are certain built in
functions in the language that are implemented in c++ and passed direct
pointers to garbage collected values (although garbage collection will
never occur during these functions). There are also some types for which
some constants are allocated statically in the data segment, and other
non-constant values are allocated on the heap. Dereferencing the pointer
can tell me which is which. Finally, some values of pointer type actually
contain integer data, making use of the fact that all real pointers in our
language are aligned, a la ocaml.

Bearing these things in mind, what would I need to do in order to be able
to use the llvm statepoint functionality to generate stack maps? Is it even
practical to do so given the current code?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210708/c5837b7c/attachment.html>

What you are proposing sounds legal, and can probably be represented with
the stackmaps. You will probably need to write your own code to parse the
stackmaps and translate them to your GC implementation, as it sounds
different from details of the reference implementation however. (Speaking
as a JuliaLang developer, that does not use stackmaps, but considered them
for integrating with our GC. We use non-integral pointers, then locate and
trace those after optimizations to locate the GC pointers precisely)


On Thu, Jul 8, 2021 at 4:48 PM Dwight Guth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I am the developer of a compiler frontend that generates llvm IR. The
> language is garbage collected, but currently doesn't have any support
for
> stack maps yet, which severely limits the places where garbage collection
> can occur.
>
> I would like to fix this, and am familiar with the documents online
> relating to gc strategies and statepoints in llvm. However, it seems much
> of the support for state points is dependent on the assumption that
> references are never passed to unmanaged functions, and you never have a
> pointer that might be garbage collected, or might not be, and you don't
> know at compile time.
>
> Our language violates both of these constraints. There are certain built
> in functions in the language that are implemented in c++ and passed direct
> pointers to garbage collected values (although garbage collection will
> never occur during these functions). There are also some types for which
> some constants are allocated statically in the data segment, and other
> non-constant values are allocated on the heap. Dereferencing the pointer
> can tell me which is which. Finally, some values of pointer type actually
> contain integer data, making use of the fact that all real pointers in our
> language are aligned, a la ocaml.
>
> Bearing these things in mind, what would I need to do in order to be able
> to use the llvm statepoint functionality to generate stack maps? Is it even
> practical to do so given the current code?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210719/5f6f1a86/attachment.html>