Add mechanism to disable creating new worlds #56639
Conversation
vtjnash
force-pushed
the
jn/disable-new-worlds
branch
from
4fb87a4 to
500fe58
Compare
vtjnash
force-pushed
the
jn/disable-new-worlds
branch
from
500fe58 to
aaaba65
Compare
|
This also means that you can't load any more code either, is that right? Folks may not think of |
base/experimental.jl
Outdated
| """ | ||
| Base.Experimental.disable_new_worlds() | ||
|
|
||
| Mark that no new worlds (methods additions, deletions, etc) are permitted to be |
There was a problem hiding this comment.
It's probably worth mentioning that this transition is permanent (if I understand correctly)
You currently can (though Keno might remove that soon), since defining code isn't a world operation, only adding methods, so the methods won't "take effect" but the loading itself will be successful. |
|
That's neat --- I suppose you could load and use a package that just defines some constants or something. But in practice of course that is not really a requirement in these cases AFAIK. |
| JL_DLLEXPORT void jl_disable_new_worlds(void) | ||
| { | ||
| if (jl_generating_output()) | ||
| jl_error("Disabling Method changes is not possible when generating output."); |
There was a problem hiding this comment.
But that's the only time I want to do it? 😂 How do you use this to generate "sealed" system images?
|
I think it's more confusing than it is neat. As a user, I would think it's a bug for Julia to claim to have loaded a package but not have applied its methods to the dispatch table |
|
Yeah no argument there; I don't think there is a real use case. (To clarify: I'm only referring to loading a package that defines methods, but ignoring those methods, as having no use case, not this PR generally.) |
|
Just to add a bit of context -- we use this feature already to quickly load "cache packages", packages that only contain precompile statements that our users generated by running queries using our product (and that we compile behind the scenes). Since we can't precompile all user queries into our product ahead of time, these cache packages are a sort of a dynamically generated extension of the system image. |
I've been asked for this specific feature several times by several different people, so it isn't without its uses. Indeed, we even already have a number of essential packages in the ecosystem whose only purpose in existing is to be able to define types without providing any new method definitions, so we've been moving towards making that possible to do for any package, though this is not relevant to this PR. |
vtjnash
force-pushed
the
jn/disable-new-worlds
branch
from
aaaba65 to
7f39d37
Compare
As a performance optimization, when you are certain only to run all
remaining code in a fixed world (e.g. not even eval a new closure or
comprehension), such as when all code is defined in a system image and
not being used interactively, you can put a call to:
Base.Experimental.disable_new_worlds()
Which will enable performance optimizations around avoiding tracking
backedges and invalidations.
vtjnash
force-pushed
the
jn/disable-new-worlds
branch
from
7f39d37 to
ef0882e
Compare
As a performance optimization, when you are certain only to run all remaining code in a fixed world (e.g. not even eval a new closure or comprehension), such as when all code is defined in a system image and not being used interactively, you can put a call to:
Which will enable performance optimizations around avoiding tracking backedges and invalidations.