This is an archive of the discontinued LLVM Phabricator instance.

[Statepoints] Support for compressed pointers in the statepoint emission pass
Needs ReviewPublic

Authored by loicottet on May 19 2023, 12:24 AM.

Details

Summary

Adds a new GCStrategy to support two types of tracked pointers in the RewriteStatepointsForGC pass. When using this strategy, pointers in addrspace(2) will be saved as depot parameters to the rewritten statepoint calls, in addition to being inserted as GC parameters. This patch has been used by the LLVM backend of GraalVM's Native Image project in production for over a year with no major issues.

Diff Detail

Event Timeline

loicottet created this revision.May 19 2023, 12:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 19 2023, 12:24 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
loicottet requested review of this revision.May 19 2023, 12:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 19 2023, 12:24 AM
dantrushin added a subscriber: apilipenko.

This seems oddly specific to the runtime you are working on. Why do you need to put compressed pointers into deopt bundes? Is it just to communicate the set of live compressed pointers to the runtime? In this case, coupling with deopt operand bundles seems incidental. We might be missing a more general mechanism for keeping track of different kinds of live GC pointers separately.

The information about the address space is preserved in the existing gc-live operand bundle. Can you use the address space of the pointers in the existing operand bundle for your purposes?

This seems oddly specific to the runtime you are working on. Why do you need to put compressed pointers into deopt bundes? Is it just to communicate the set of live compressed pointers to the runtime? In this case, coupling with deopt operand bundles seems incidental. We might be missing a more general mechanism for keeping track of different kinds of live GC pointers separately.

I agree that a better mechanism to keep track of address spaces would be a better way to solve this.

The information about the address space is preserved in the existing gc-live operand bundle. Can you use the address space of the pointers in the existing operand bundle for your purposes?

The problem we are facing is that we need to retrieve this information from the stack maps, which do not preserve address space information. I don't know how doable it is to change the stack map format to accommodate this.

Right, one of the options would be to encode the information about GC pointer address spaces explicitly in the statepoint stack map.

Alternatively, you can have a downstream pass that rewrites the IR after RS4GC to accommodate the needs of your runtime. It would be a simple post-processing pass to parse gc-live operand bundle and add a deopt bundle with compressed pointers.