DO NOT MERGE: v1.12 branch for comparison to master #202
Conversation
This file contains hidden or 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
nickrobinson251
force-pushed
the
v1.12.0-DEV+RAI
branch
4 times, most recently
from
966538b to
9da665d
Compare
d-netto
force-pushed
the
v1.12.0-DEV+RAI
branch
from
9da665d to
48a5871
Compare
nickrobinson251
force-pushed
the
v1.12.0-DEV+RAI
branch
from
48a5871 to
5974904
Compare
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
7 times, most recently
from
1cff7d7 to
1e6e20d
Compare
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
3 times, most recently
from
38eead6 to
7d154ea
Compare
Whether or not a binding is exported affects the binding resolution of any downstream modules that `using` the module that defines the binding. As such, it needs to fully participate in the invalidation mechanism, so that code which references bindings whose resolution may have changed get properly invalidated. To do this, move the `exportp` flag from Binding into a separate bitflag set that gets or'd into the BindingPartition `->kind` field. Note that we do not move `publicp` in the same way since it does not affect binding resolution. There is currently no mechanism to un-export a binding, although the system is set up to support this in the future (and Revise may want it). That said, at such a time, we may need to revisit the above decision on `publicp`. Lastly, I will note that this adds a fair number of additional invalidations. Most of these are unnecessary, as changing an export only affects the *downstream* users not the binding itself. I am planning to tackle this as part of a larger future PR that avoids invalidation when this is not required. Fixes JuliaLang#57377 (cherry picked from commit b27a24a)
Should fix the error part of JuliaLang#57329. I also cannot reproduce the underlying assertion error on master, so that was likely fixed in one of the other PRs. Closes JuliaLang#57329 as a result, but of course there could be other issues with the same symptoms, which can get their own issues. (cherry picked from commit 88b292d)
fixes JuliaLang#55831 (cherry picked from commit 2364719)
This makes non-guard bindings stronger than guard bindings for ambiguity purposes. Note that both of these are yet stronger than deprecated bindings, so if there's a "non-guard deprecated" binding and a "guard non-deprecated" binding, the latter will win and the access will be UndefVarError. I think this is the closest to the 1.11 behavior without relying on resolvedness. Fixes JuliaLang#57404 This PR is against JuliaLang#57405 just because that PR touches the common interface, but is conceptually independent. (cherry picked from commit a371899)
…ang#49933) This has been bouncing around as a idea for a while. One of the challenges around time-to-safepoint has been Julia code that is calling libraries. Since foreign code will not include safepoints we see increased latency when one thread is running a foreign-call and another wants to trigger GC. The open design question here is: - Do we expose this as an option the user must "opt-in", e.g. by using a keyword arg to `@ccall` or a specific calling-convetion. - Or do we turn this on for all ccall, except for Julia runtime calls. There is relativly little code outside the Julia runtime that needs to be "GC unsafe", exception are programs that directly use the Julia C-API. Incidentially `jl_adopt_thread` and `@cfunction`/`@ccallable` do the right thing and transition to "GC unsafe", regardless of what state the thread currently is in. I still need to figure out how to reliably detect Julia runtime calls, but I think we can switch all other calls to "GC safe". We should also consider optimizations that mark large regions of code without Julia runtime interactions as "GC safe" in particular numeric for-loops. Closes JuliaLang#57057 --------- Co-authored-by: Gabriel Baraldi <[email protected]> (cherry picked from commit 85458a0)
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
from
7d154ea to
02e0f68
Compare
Backported PRs: - [x] JuliaLang#57346 <!-- lowering: Only try to define the method once --> - [x] JuliaLang#57341 <!-- bpart: When backdating replace the entire bpart chain --> - [x] JuliaLang#57381 <!-- staticdata: Set min validation world to require world --> - [x] JuliaLang#57357 <!-- Only implicitly `using` Base, not Core --> - [x] JuliaLang#57383 <!-- staticdata: Fix typo in recursive edge revalidation --> - [x] JuliaLang#57385 <!-- bpart: Move kind enum into its intended place --> - [x] JuliaLang#57275 <!-- Compiler: fix unsoundness of getfield_tfunc on Tuple Types --> - [x] JuliaLang#57378 <!-- print admonition for auto-import only once per module --> - [x] JuliaLang#57392 <!-- [LateLowerGCFrame] fix PlaceGCFrameReset for returns_twice --> - [x] JuliaLang#57388 <!-- Bump JuliaSyntax to v1.0.2 --> - [x] JuliaLang#57266 <!-- 🤖 [master] Bump the Statistics stdlib from d49c2bf to 77bd570 --> - [x] JuliaLang#57395 <!-- lowering: fix has_fcall computation --> - [x] JuliaLang#57204 <!-- Clarify mathematical definition of `gcd` --> - [x] JuliaLang#56794 <!-- Make `Pairs` public --> - [x] JuliaLang#57407 <!-- staticdata: corrected implementation of jl_collect_new_roots --> - [x] JuliaLang#57405 <!-- bpart: Also partition the export flag --> - [x] JuliaLang#57420 <!-- Compiler: Fix check for IRShow definedness --> - [x] JuliaLang#55875 <!-- fix `(-Inf)^-1` inconsistency --> - [x] JuliaLang#57317 <!-- internals: add _defaultctor function for defining ctors --> - [x] JuliaLang#57406 <!-- bpart: Ignore guard bindings for ambiguity purposes --> - [x] JuliaLang#49933 <!-- Allow for :foreigncall to transition to GC safe automatically -->
…uliaLang#57421) When loading a pkgimage, the new bpart validation code needs to check if the export set of any using'd packages differs from what it would have been during precompile. This could e.g. happen if somebody (or Revise) eval'd a new `export` statement into a package that was `using`'d. However, this case is somewhat rare, so let's optimize it by keeping a bit in `Module` that keeps track of whether anything like that has happened and if not skipping the revalidation. This slightly improves pkgimage load time in the ordinary case. More optimizations to follow. (cherry picked from commit 39255d4)
…Lang#57419) This addresses post-commit review JuliaLang#57230 (comment). This change was left-over from before I decided to also change the type of the `source` argument (at which point `source.module` was unavailable in the function). This module was supposed to be the same, but it turns out that both the julia tests and several packages use this code manually and use different modules for the two places. Use the same one we used before (which is probably more correct anyway) to fix JuliaLang#57417 (cherry picked from commit 0c5372f)
…iaLang#57425) This applies the existing prohibition against introducing new bindings in a closed module to binding replacement as well (for the same reason - the change won't be persisted after reload). It is pretty hard to even reach this point, since `eval` into closed modules is already prohibited and there's no surface syntax for cross-module declaration, but it is technically reachable from lowered IR. Further, in the future we may make all of these builtins, which would make it easier. Thus, be consistent now and fully disallow binding replacement in closed modules during precompile. (cherry picked from commit 56aed62)
…uliaLang#57426) An upcoming optimization will skip most binding validation if no binding replacement has taken place in (sysimage, pkgimage) modules. However, as a special case, we would like to treat `Main` as a non-sysimage module because the addition of new bindings in `Main` is common and we would like this to not ruin the optimization. To make this legal, we have to prohibit `import`ing or `using` any `Main` bindings in pkgimages. I don't think anybody actually does this, particularly, since `Main` is not considered loading during precompile (so you have to use the main binding via (Core|Base|).Main), and I can't think of any good semantic reason to want to do this, but regardless, it does add additional restrictions to `using`/`import`, so I wanted to break it out into its own PR. (cherry picked from commit 726c816)
…dules (JuliaLang#57433) This implements the optimization proposed in JuliaLang#57426 by keeping track of whether any bindings were replaced in image modules (excluding `Main` as facilitated by JuliaLang#57426). In addition, we augment serialization to keep track of whether a method body contains any GlobalRefs that point to a loaded (system or package) image. If both of these flags are true, we can skip scanning the body of the method, since we know that we neither need to add any additional backedges nor were any of the referenced bindings invalidated. The performance impact on end-to-end load time is small, but measurable. Overall `@time using ModelingToolkit` consistently improves about 5% using this PR. However, I should note that using time is still about 40% slower than 1.11. This is not necessarily an Apples-to-Apples comparison as there were substantial other changes on 1.12 (as well as current load-time-tunings targeting older versions), but I wanted to put the number context. (cherry picked from commit f6e2b98)
DelveCI
force-pushed
the
v1.12.0-DEV+RAI
branch
from
02e0f68 to
35024c5
Compare
…xx` (JuliaLang#58325) Otherwise these subroutines may raise `unhandled Vararg` errors when compiling e.g. CassetteOverlay for complex call graphs.
This is a follow-up to JuliaLang#54341. Otherwise, `validate_code!` may raise wrong errors for unmatched `nargs` information between generated code and original method.
This reverts commit 925d41c.
…ch_status enum (JuliaLang#58291) The original purpose of this field was to manage quickly detecting if a method was replaced, but that stopped being correct after JuliaLang#53415. It was a fairly heavy-weight description of that single bit of information. This bit of information allows quickly bypassing some method lookups from pkgimages, since it can quickly detect that the result is trivially correct (such as single-argument functions). Also fixes JuliaLang#58215 (cherry picked from commit 5eb5155)
…JuliaLang#58335) This extends the use of the optimization in JuliaLang#58291 to also apply to some uses of ml_matches also. (cherry picked from commit d1ec7d5)
`Base.get_extension` and `Dates.format` both appear in the manual and should therefore be `public` symbols according to [51335](JuliaLang#51335 (comment)). They appear in the manual [here](https://docs.julialang.org/en/v1/base/base/#Base.get_extension) and [here](https://docs.julialang.org/en/v1/stdlib/Dates/#Dates.format-Tuple%7BTimeType,%20AbstractString%7D). Please also consider back porting this to version 1.12 (cherry picked from commit 963eaa7)
Fixes JuliaLang#55844 (cherry picked from commit 9986d97)
…Lang#58356) Refs: JuliaLang#58070 (cherry picked from commit f07565f)
This reverts commit f15d417.
…s from packages succeed. TODO: remove this once alpha/beta is released # Conflicts: # VERSION # Conflicts: # VERSION # Conflicts: # VERSION
Prevent transparent huge pages (THP) overallocating pysical memory. Co-authored-by: Adnan Alhomssi <[email protected]>
Prepend `[signal (X) ]thread (Y) ` to each backtrace line that is displayed. Co-authored-by: Diogo Netto <[email protected]>
Also show the signal number when we have it.
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.
See also RAICode PR https://github.com/RelationalAI/raicode/pull/22602/commits