Skip to content
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

fix(compiler): Apply correct allocation type to numbers #1140

Merged
merged 1 commit into from
Mar 6, 2022

Conversation

ospencer
Copy link
Member

We can potentially be a little smarter here and only do this for numbers that get allocated on the heap; it'd save a few incref/decrefs.

@ospencer ospencer requested a review from a team February 27, 2022 16:19
@ospencer ospencer self-assigned this Feb 27, 2022
Copy link
Member

@marcusroberts marcusroberts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Member

@peblair peblair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ospencer Can you either add at least some basic check for whether a number will be stack-allocated (and set the allocation_type accordingly) or at least create a follow-on issue so we don't lose track of this?

@ospencer
Copy link
Member Author

ospencer commented Mar 5, 2022

I was thinking about this and realized that might be too clever... I think it'd cause the slot to be considered StackAllocated for its full life, which for let mut could mean that a heap-allocated number might not get decref'd.

So maybe we should just forget I said that 😛

@peblair
Copy link
Member

peblair commented Mar 5, 2022

Got it. This makes me think (not for this PR) that the allocation_type logic should maybe be three-valued, though:

  • stack-allocated
  • heap-allocated
  • unknown (assume heap-allocated)

@ospencer
Copy link
Member Author

ospencer commented Mar 5, 2022

What would unknown get us?

@ospencer
Copy link
Member Author

ospencer commented Mar 5, 2022

Though I can certainly see some terminology changes, like calling them Managed and Unmanaged or something like that.

@peblair
Copy link
Member

peblair commented Mar 5, 2022

Well, my interpretation of your last comment is, "we have to (conservatively) say that it's heap-allocated, since we don't know whether or not it is"; I feel like we should explicitly encode the fact that we don't know whether it is, and then the codegen can explicitly say, "if we don't know what it is, then we'll assume it's heap-allocated" (as opposed to the implicit statement of that idea in the current code)

@ospencer
Copy link
Member Author

ospencer commented Mar 5, 2022

Yeah. I think that's why I could get on board with something like Managed/Unmanaged since we care more about whether it's getting GC'd than if that value is a pointer or not (since largely we've been saying "that thing is a pointer, so GC it") which gets in the way of our hybrid-allocated types like numbers.

@peblair
Copy link
Member

peblair commented Mar 5, 2022

Sounds good to me. Can you open an issue? Also, maybe we should have a separate ~memory_management= field? Whatever you think is best.

@ospencer
Copy link
Member Author

ospencer commented Mar 5, 2022

Yeah, splitting the managed apart from the wasm type?

@peblair
Copy link
Member

peblair commented Mar 5, 2022

Yeah, exactly. Adding a separate field for the memory management and updating the codegen to use it for its incref/decref decision-making

Copy link
Member

@phated phated left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:approved:

@ospencer ospencer merged commit b9e9d59 into main Mar 6, 2022
@ospencer ospencer deleted the oscar/fix-number-allocation branch March 6, 2022 02:25
@github-actions github-actions bot mentioned this pull request May 16, 2022
@github-actions github-actions bot mentioned this pull request May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants