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

more field property annotations #47677

Merged
merged 1 commit into from
Dec 7, 2022
Merged

more field property annotations #47677

merged 1 commit into from
Dec 7, 2022

Conversation

vtjnash
Copy link
Sponsor Member

@vtjnash vtjnash commented Nov 22, 2022

Mostly looking at fixing more implicit data race with more atomics. Some of this (at the Julia level) is not strictly necessary since we already intend to start using implicit release-consume ordering for references. But since the user should not be changing these fields anyways, or risk severe breakage, this should be fine to mark explicitly.

base/reflection.jl Outdated Show resolved Hide resolved
@brenhinkeller brenhinkeller added compiler:llvm For issues that relate to LLVM needs pkgeval Tests for all registered packages should be run with this change labels Nov 23, 2022
@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Nov 28, 2022

@nanosoldier runtests()

@nanosoldier
Copy link
Collaborator

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

Mostly looking at fixing more implicit data race with more atomics. Some
of this (at the Julia level) is not strictly necessary since we already
intend to start using implicit release-consume ordering for references.
But since the user should not be changing these fields anyways, or risk
severe breakage, this should be fine to mark explicitly.
@vtjnash vtjnash removed the needs pkgeval Tests for all registered packages should be run with this change label Dec 7, 2022
@vtjnash vtjnash merged commit c8662b5 into master Dec 7, 2022
@vtjnash vtjnash deleted the jn/more-field-atomics branch December 7, 2022 22:15
@aviatesk
Copy link
Sponsor Member

aviatesk commented Dec 8, 2022

Should we do a follow up like:

diff --git a/base/compiler/typeinfer.jl b/base/compiler/typeinfer.jl
index 81d0f06608..e55c79b69a 100644
--- a/base/compiler/typeinfer.jl
+++ b/base/compiler/typeinfer.jl
@@ -1096,7 +1096,7 @@ function typeinf_ext_toplevel(interp::AbstractInterpreter, linfo::MethodInstance
         # method lambda - infer this specialization via the method cache
         src = typeinf_ext(interp, linfo)
     else
-        src = linfo.uninferred::CodeInfo
+        src = @atomic :monotonic linfo.uninferred::CodeInfo
         if !src.inferred
             # toplevel lambda - infer directly
             ccall(:jl_typeinf_timing_begin, Cvoid, ())
diff --git a/base/show.jl b/base/show.jl
index 9e6b959f24..3dbf345c8f 100644
--- a/base/show.jl
+++ b/base/show.jl
@@ -1246,7 +1246,8 @@ function show_mi(io::IO, l::Core.MethodInstance, from_stackframe::Bool=false)
         # added by other means.  But if it isn't, then we should try
         # to print a little more identifying information.
         if !from_stackframe
-            linetable = l.uninferred.linetable
+            codeinf = (@atomic :monotonic l.uninferred)::CodeInfo
+            linetable = codeinf.linetable
             line = isempty(linetable) ? "unknown" : (lt = linetable[1]::Union{LineNumberNode,Core.LineInfoNode}; string(lt.file, ':', lt.line))
             print(io, " from ", def, " starting at ", line)
         end
@@ -1270,7 +1271,8 @@ function show(io::IO, mi_info::Core.Compiler.Timings.InferenceFrameInfo)
             show_tuple_as_call(io, def.name, mi.specTypes; argnames, qualified=true)
         end
     else
-        linetable = mi.uninferred.linetable
+        codeinf = (@atomic :monotonic mi.uninferred)::CodeInfo
+        linetable = codeinf.linetable
         line = isempty(linetable) ? "" : (lt = linetable[1]; string(lt.file, ':', lt.line))
         print(io, "Toplevel InferenceFrameInfo thunk from ", def, " starting at ", line)
     end
diff --git a/base/stacktraces.jl b/base/stacktraces.jl
index d74d47e1eb..0ab9a22584 100644
--- a/base/stacktraces.jl
+++ b/base/stacktraces.jl
@@ -124,7 +124,7 @@ function lookup(ip::Union{Base.InterpreterIP,Core.Compiler.InterpreterIP})
         # interpreted top-level expression with no CodeInfo
         return [StackFrame(top_level_scope_sym, empty_sym, 0, nothing, false, false, 0)]
     end
-    codeinfo = (code isa MethodInstance ? code.uninferred : code)::CodeInfo
+    codeinfo = (code isa MethodInstance ? (@atomic :monotonic code.uninferred) : code)::CodeInfo
     # prepare approximate code info
     if code isa MethodInstance && (meth = code.def; meth isa Method)
         func = meth.name
diff --git a/stdlib/Serialization/src/Serialization.jl b/stdlib/Serialization/src/Serialization.jl
index e36b5c67e2..252695d635 100644
--- a/stdlib/Serialization/src/Serialization.jl
+++ b/stdlib/Serialization/src/Serialization.jl
@@ -446,7 +446,7 @@ function serialize(s::AbstractSerializer, linfo::Core.MethodInstance)
     serialize_cycle(s, linfo) && return
     writetag(s.io, METHODINSTANCE_TAG)
     if isdefined(linfo, :uninferred)
-        serialize(s, linfo.uninferred)
+        serialize(s, @atomic :monotonic linfo.uninferred)
     else
         writetag(s.io, UNDEFREF_TAG)
     end

, or are these explicit @atomic loads unnecessary?

aviatesk added a commit to aviatesk/JET.jl that referenced this pull request Dec 8, 2022
aviatesk added a commit to aviatesk/JET.jl that referenced this pull request Dec 8, 2022
@vtjnash
Copy link
Sponsor Member Author

vtjnash commented Dec 8, 2022

That is the default behavior, so it is unnecessary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:llvm For issues that relate to LLVM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants