Support deleting methods during precompilation for stdlib excision #51641
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vchuravy
force-pushed
the
vc/excise_random
branch
from
070ef3f to
446a6f7
Compare
vchuravy
force-pushed
the
vc/excise_random
branch
from
7e227cb to
1b4a194
Compare
vchuravy
force-pushed
the
vc/support_deleting_methods_during_precompile
branch
from
5e54126 to
0aa42f8
Compare
|
@nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. |
vchuravy
added a commit
that referenced
this pull request
Oct 20, 2023
…51641) The problem with the `delete_method` in `__init__` approach is that we invalidate the method-table, after we have performed all of the caching work. A package dependent on `Random`, will still see the stub method in Base and thus when we delete the stub, we may invalidate useful work. Instead we delete the methods when Random is being loaded, thus a dependent package only ever sees the method table with all the methods in Random, and non of the stubs methods. The only invalidation that thus may happen are calls to `rand` and `randn` without first doing an `import Random`.
vchuravy
added a commit
that referenced
this pull request
Dec 4, 2023
…51641) The problem with the `delete_method` in `__init__` approach is that we invalidate the method-table, after we have performed all of the caching work. A package dependent on `Random`, will still see the stub method in Base and thus when we delete the stub, we may invalidate useful work. Instead we delete the methods when Random is being loaded, thus a dependent package only ever sees the method table with all the methods in Random, and non of the stubs methods. The only invalidation that thus may happen are calls to `rand` and `randn` without first doing an `import Random`.
vchuravy
added a commit
that referenced
this pull request
Dec 4, 2023
vchuravy
added a commit
that referenced
this pull request
Jan 22, 2024
…51641) The problem with the `delete_method` in `__init__` approach is that we invalidate the method-table, after we have performed all of the caching work. A package dependent on `Random`, will still see the stub method in Base and thus when we delete the stub, we may invalidate useful work. Instead we delete the methods when Random is being loaded, thus a dependent package only ever sees the method table with all the methods in Random, and non of the stubs methods. The only invalidation that thus may happen are calls to `rand` and `randn` without first doing an `import Random`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Still fairly hacky and messy, but that's due to me not knowing this part of the code super well.
I originally was thinking I could scan all method tables and find deleted methods,
but I didn't find a way of expressing "these deletions are new".
I limited myself thusly to the part of the problem I need for #51432 and JuliaLang/LinearAlgebra.jl#1027,
in particular making my proposed delayed method trick compatible with caching,
by limiting the invalidation effect.
The problem with the
delete_methodin__init__approach is that we invalidate the method-table,after we have performed all of the caching work. A package dependent on
Random, will still seethe stub method in Base and thus when we delete the stub, we may invalidate useful work.
Instead we delete the methods when Random is being loaded, thus a dependent package only ever sees
the method table with all the methods in Random, and non of the stubs methods.
The only invalidation that thus may happen are calls to
randandrandnwithout first doing animport Random.