-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Interpreter does not respect generated function edges/world ages #54360
Labels
Comments
Keno
added a commit
that referenced
this issue
May 5, 2024
This fixes #54360 by moving the interpreter's cache of `@generated` results from `mi.uninferred` into `mi.cache` with a separate cache owner to partition the cache from regular inference results. There are two other uses of the `mi.uninferred` field: 1. As the place to store uninferred code for temporary top-level thunks 2. Is an uncompressed copy of m->source to avoid having to re-uncompress every time in the interpreter. In this PR, use case 1 is changed to use the same mechanism as generated functions. Use case 2 is changed to just uncompress the source in place in m->source. As a result, the `uninferred` field is unused and removed. Note that I'm planning a somewhat larger refactor of `MethodInstance` in the immediate future, so this might be a somewhat shortlived representation, but that change should hopefully by largely transparent to users of the wrappers introduced here.
Keno
added a commit
that referenced
this issue
May 5, 2024
This fixes #54360 by moving the interpreter's cache of `@generated` results from `mi.uninferred` into `mi.cache` with a separate cache owner to partition the cache from regular inference results. There are two other uses of the `mi.uninferred` field: 1. As the place to store uninferred code for temporary top-level thunks 2. Is an uncompressed copy of m->source to avoid having to re-uncompress every time in the interpreter. In this PR, use case 1 is changed to use the same mechanism as generated functions. Use case 2 is changed to just uncompress the source in place in m->source. As a result, the `uninferred` field is unused and removed. Note that I'm planning a somewhat larger refactor of `MethodInstance` in the immediate future, so this might be a somewhat shortlived representation, but that change should hopefully by largely transparent to users of the wrappers introduced here.
Keno
added a commit
that referenced
this issue
May 7, 2024
This fixes #54360 by moving the interpreter's cache of `@generated` results from `mi.uninferred` into `mi.cache` with a separate cache owner to partition the cache from regular inference results. There are two other uses of the `mi.uninferred` field: 1. As the place to store uninferred code for temporary top-level thunks 2. Is an uncompressed copy of m->source to avoid having to re-uncompress every time in the interpreter. In this PR, use case 1 is changed to use the same mechanism as generated functions. Use case 2 is changed to just uncompress the source in place in m->source. As a result, the `uninferred` field is unused and removed. Note that I'm planning a somewhat larger refactor of `MethodInstance` in the immediate future, so this might be a somewhat shortlived representation, but that change should hopefully by largely transparent to users of the wrappers introduced here.
Keno
added a commit
that referenced
this issue
May 7, 2024
…54362) This fixes #54360 by moving the interpreter's cache of `@generated` results from `mi.uninferred` into `mi.cache` with a separate cache owner to partition the cache from regular inference results. There are two other uses of the `mi.uninferred` field: 1. As the place to store uninferred code for temporary top-level thunks 2. Is an uncompressed copy of m->source to avoid having to re-uncompress every time in the interpreter. In this PR, use case 1 is changed to use the same mechanism as generated functions. Use case 2 is changed to just uncompress the source in place in m->source. As a result, the `uninferred` field is unused and removed. Note that I'm planning a somewhat larger refactor of `MethodInstance` in the immediate future, so this might be a somewhat shortlived representation, but that change should hopefully by largely transparent to users of the wrappers introduced here.
xlxs4
pushed a commit
to xlxs4/julia
that referenced
this issue
May 9, 2024
…uliaLang#54362) This fixes JuliaLang#54360 by moving the interpreter's cache of `@generated` results from `mi.uninferred` into `mi.cache` with a separate cache owner to partition the cache from regular inference results. There are two other uses of the `mi.uninferred` field: 1. As the place to store uninferred code for temporary top-level thunks 2. Is an uncompressed copy of m->source to avoid having to re-uncompress every time in the interpreter. In this PR, use case 1 is changed to use the same mechanism as generated functions. Use case 2 is changed to just uncompress the source in place in m->source. As a result, the `uninferred` field is unused and removed. Note that I'm planning a somewhat larger refactor of `MethodInstance` in the immediate future, so this might be a somewhat shortlived representation, but that change should hopefully by largely transparent to users of the wrappers introduced here.
lazarusA
pushed a commit
to lazarusA/julia
that referenced
this issue
Jul 12, 2024
…uliaLang#54362) This fixes JuliaLang#54360 by moving the interpreter's cache of `@generated` results from `mi.uninferred` into `mi.cache` with a separate cache owner to partition the cache from regular inference results. There are two other uses of the `mi.uninferred` field: 1. As the place to store uninferred code for temporary top-level thunks 2. Is an uncompressed copy of m->source to avoid having to re-uncompress every time in the interpreter. In this PR, use case 1 is changed to use the same mechanism as generated functions. Use case 2 is changed to just uncompress the source in place in m->source. As a result, the `uninferred` field is unused and removed. Note that I'm planning a somewhat larger refactor of `MethodInstance` in the immediate future, so this might be a somewhat shortlived representation, but that change should hopefully by largely transparent to users of the wrappers introduced here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: