fix invalidations in logging

[ranocha]

This should hopefully fix 905 invalidations coming from Static.jl.

Here is the code:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.8.0 (2022-08-17)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

(@v1.8) pkg> activate --temp
  Activating new project at `/tmp/jl_PDrBpd`

(jl_PDrBpd) pkg> add Static
    Updating registry at `~/.julia/registries/General.toml`
   Resolving package versions...
    Updating `/tmp/jl_PDrBpd/Project.toml`
  [aedffcd0] + Static v0.7.6
    Updating `/tmp/jl_PDrBpd/Manifest.toml`
  [615f187c] + IfElse v0.1.1
  [aedffcd0] + Static v0.7.6

julia> using SnoopCompileCore

julia> invalidations = @snoopr using Static

julia> using SnoopCompile

julia> length(uinvalidated(invalidations))
1723

julia> trees = invalidation_trees(invalidations)
7-element Vector{SnoopCompile.MethodInvalidations}:
...
 inserting !(::False) in Static at ~/.julia/packages/Static/sVI3g/src/Static.jl:427 invalidated:
...
                 163: signature Tuple{typeof(!), Any} triggered MethodInstance for Base.CoreLogging.var"#handle_message#2"(::Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}}, ::typeof(Base.CoreLogging.handle_message), ::Base.CoreLogging.SimpleLogger, ::Base.CoreLogging.LogLevel, ::Any, ::Any, ::Any, ::Any, ::Any, ::Any) (905 children)

help?> isopen
search: isopen partialsortperm partialsortperm! isconcretetype

  isopen(object) -> Bool

  Determine whether an object - such as a stream or timer – is not yet closed. Once an object is closed, it
  will never produce a new event. However, since a closed stream may still have data to read in its buffer, use
  eof to check for the ability to read data. Use the FileWatching package to be notified when a stream might be
  writable or readable.

  Examples
  ≡≡≡≡≡≡≡≡≡≡

  julia> io = open("my_file.txt", "w+");
  
  julia> isopen(io)
  true
  
  julia> close(io)
  
  julia> isopen(io)
  false

Since isopen is documented to return a Bool, this type annotation should help prevent some invalidations.

[Tokazama]

Is it problematic for SimpleLogger to be parametric? Usually subtypes of IO aren't highly complicated so it shouldn't generate a bunch of new code.

[ranocha]

Is it problematic for SimpleLogger to be parametric? Usually subtypes of IO aren't highly complicated so it shouldn't generate a bunch of new code.

I honestly don't know. I just saw the report of SnoopCompile.jl shown in my first post. I thought that Base.CoreLogging.var"#handle_message#2"(::Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}}, ::typeof(Base.CoreLogging.handle_message), ::Base.CoreLogging.SimpleLogger,... is the keyword sorter/handler for the method I changed. Since this method uses @nospecialize, it cannot determine all types perfectly, in particular not the one of stream. This can be problematic when downstream packages overload ! for any type, even without type piracy.

[ranocha]

An alternative for this particular case could be to remove the overload of ! in Static.jl, see SciML/Static.jl#78. But this change here should still prevent invalidations when other packages overload !.

[Tokazama]

An alternative for this particular case could be to remove the overload of ! in Static.jl, see SciML/Static.jl#78. But this change here should still prevent invalidations when other packages overload !.

As you pointed out it is a quick fix to a bigger problem because other packages are still overloading it. I'm definitely not going to put a strong fight against not overloading it in static if that's the way the winds blow, but I think Static.jl gets caught first for some of these just because it's widely depended on.

[ChrisRackauckas]

LoopVectorization.jl is the harder case because it needs to have the ! overload for user code. Users need the ! on Bool SIMD vectors in order for @turbo to work on their code. Static.jl can be kept dev-side, so static_! with no user-facing overload, tell people to const ! = static_! etc. and the issue will be gone, but LoopVectorization.jl invalidates just as much (the same functions) but cannot rely on such code changes because its user model has to assume a "basic user". These kinds of changes are thus required for that.

[ranocha]

These kinds of changes are thus required for that.

Yeah, I submitted quite a lot of them today (see https://discourse.julialang.org/t/potential-performance-regressions-in-julia-1-8-for-special-un-precompiled-type-dispatches-and-how-to-fix-them/86359/6)