-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC 0004: HEAP escape analysis #4
base: main
Are you sure you want to change the base?
Conversation
Add an optimization pass to the compiler to detect places where a class instantiation could happen on the stack rather than the GC HEAP.
Co-authored-by: Johannes Müller <straightshoota@gmail.com>
|
||
# Drawbacks | ||
|
||
Some objects would now be allocated on the stack, which are GC roots that must be scanned conservatively and can't scan precisely. This may have negatively impact GC performance when we implement semi-conservative marking (conservative marking of GC roots _yet_ precise marking of HEAP allocated objects). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be possible to reuse a lot of the escape analysis architecture to implement a shadow stack for each fiber which contains only roots. This could be both precise and a far smaller stack than the actual program stack for the GC to scan. Especially given the stack usage will grow when escape analysis is turned on.
I don't know how that tradeoff compares to the LLVM built in stackmap generator, but it's an idea.
Add an optimization pass to the compiler to detect places where a class instantiation could happen on the stack rather than the GC HEAP.
Preview: https://github.com/crystal-lang/rfcs/blob/rfc-heap-escape-analysis/text/0004-heap-escape-analysis.md