### Author:  [@quinnj](https://discourse.julialang.org/u/quinnj)
#### Post date: [January 4, 2023, 12:33am UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/3 "2023-01-04T00:33:54Z")
I wonder if there’s a way you could do a validation check or assert on the finalizer function to ensure it was valid for eager finalization? And if not, throw an argument error? I feel like that’s the only (maybe) missing feature for me w/ eager finalization is that I want to really make sure that it’s going to be eagerly finalized (since that affects the design quite a bit in certain cases). Does anyone know if there’s a way to do that kind of assertion w/ the compiler? Inspect the effects inferred on function w/ a given argument and assert the right things for eager finalization?
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [January 4, 2023, 12:43am UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/4 "2023-01-04T00:43:20Z")
> [@quinnj](#):
>
> I wonder if there’s a way you could do a validation check or assert on the finalizer function to ensure it was valid for eager finalization?
I think this might work:
```julia
julia> effects = Base.infer_effects(x->nothing)
(+c,+e,+n,+t,+s,+m)
julia> Core.Compiler.is_nothrow(effects)
true
julia> Core.Compiler.is_notaskstate(effects)
true
```
We want `Core.Compiler.is_finalizer_inlineable` to be true, I think:
>
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [January 4, 2023, 1:01am UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/5 "2023-01-04T01:01:51Z")
This simplified example looks promising.
```julia
julia> n::Int = 0
0
julia> const safe_free = Base.@assume_effects :nothrow :notaskstate x->(global n += 1;Libc.free(x.ptr))
#3 (generic function with 1 method)
julia> mutable struct SafePointer
ptr::Ptr{Int}
end
julia> function f()
for i in 1:100
s = SafePointer(Libc.malloc(sizeof(Int)))
finalizer(safe_free, s)
end
nothing
end
f (generic function with 1 method)
julia> n
0
julia> f()
julia> n
100
```
Here is the documentation on the effects:
```julia
help?> Core.Compiler.Effects
effects::Effects
Represents computational effects of a method call.
The effects are a composition of different effect bits that represent some program property of the method being analyzed. They are represented as Bool or UInt8 bits with the following meanings:
...
• nothrow::Bool: this method is guaranteed to not throw an exception.
...
• notaskstate::Bool: this method does not access any state bound to the current task and may thus be moved to a different task without changing observable behavior. Note that this currently implies that noyield as well, since yielding modifies the state of the current task, though this may be split in the future.
```
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [January 4, 2023, 5:20pm UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/6 "2023-01-04T17:20:50Z")
I think there is a problem.
```julia
julia> Base.@assume_effects :nothrow :notaskstate inlinable_libc_free(r) = Libc.free(r[])
inlinable_libc_free (generic function with 1 method)
julia> function foo()
r = Ref(Ptr{Int}(Libc.malloc(sizeof(Int))))
finalizer(inlinable_libc_free, r)
unsafe_store!(r[], 5)
unsafe_load(r[])
end
foo (generic function with 1 method)
julia> foo()
42156479
julia> function bar()
r = Ref(Ptr{Int}(Libc.malloc(sizeof(Int))))
finalizer(inlinable_libc_free, r)
unsafe_store!(r[], 5)
unsafe_load(r[]), r
end
bar (generic function with 1 method)
julia> first(bar())
5
```
---
### Author:  [@pxl-th](https://discourse.julialang.org/u/pxl-th)
#### Post date: [March 1, 2023, 12:54pm UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/7 "2023-03-01T12:54:45Z")
I’m curious if there are any plans to relax restrictions on eager finalization?
As currently it seems too restrictive (basically even dict lookups are not allowed):
```julia
julia> Core.Compiler.infer_effects(get, (Dict{Int, Int}, Int, Int))
(!c,+e,!n,!t,+s,?m,+i)
```
For GPU arrays it’d be great to have it working as GC is not aware of other memory spaces and in a lot of scenarious we have to call it manually.
E.g. render loops in [Nerf.jl](https://github.com/JuliaNeuralGraphics/Nerf.jl/blob/93f8de0b7027834a7665561dbd6e0e3391573f4d/src/renderer/renderer.jl#L170), where each `GC.gc(false)` call takes `~1ms`, where that loop may run for 100+ iterations for a single frame render.
It may also solve the need for: [Free CuArrays in the reverse pass by mcabbott · Pull Request #1340 · FluxML/Zygote.jl · GitHub](https://github.com/FluxML/Zygote.jl/pull/1340)
From what I saw in practive, I think Nvidia driver is more robust and CUDA.jl with its alloc/retry mechanism works fine without calling GC (at least not as often).
But for AMDGPU it does not work reliably and can easily crash the runtime.
For example during scratch allocation at kernel dispatch which happens at the ROCr level and is not covered by alloc/retry mechanism.
Also, I though it inlines finalizer and runs it on the same task, but then there is `:notaskstate` requirement…
Does it mean that finalizer is not inlined and may still run on the separate task?
For example:
```julia
y = ROCArray{Float32}(...)
for i in ...
x = AMDGPU.rand(...)
y .+= x
# <- insert finalizer for `x` here and run it on this task and allow throwing an exception, for example...
# Inline: finalize(x) ≡ AMDGPU.unsafe_free!(x)
end
y
```
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [March 31, 2023, 1:38am UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/8 "2023-03-31T01:38:22Z")
> [@mkitti](#):
>
> I think there is a problem.
>
> ```julia
> julia> Base.@assume_effects :nothrow :notaskstate inlinable_libc_free(r) = Libc.free(r[])
> inlinable_libc_free (generic function with 1 method)
>
> julia> function foo()
> r = Ref(Ptr{Int}(Libc.malloc(sizeof(Int))))
> finalizer(inlinable_libc_free, r)
> unsafe_store!(r[], 5)
> unsafe_load(r[])
> end
> foo (generic function with 1 method)
>
> ```
I think the problem here is that `unsafe_load(r[])` gets linearized to
```julia
_1 = r[]
# <------- No more references to r, so the finalizer gets inserted here!
unsafe_load(_1)
# <------- You actually want the finalizer to be inserted here
```
---
### Author:  [@AMJ](https://discourse.julialang.org/u/AMJ)
#### Post date: [June 23, 2023, 6:38pm UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/9 "2023-06-23T18:38:48Z")
I am kinda oblivious about matters discussed here and have been more confused by reading the ValeLang’s blog recently, can anything discussed from [here](https://verdagon.dev/blog/vale-memory-safe-cpp) used for helping GC or avoid/replace it?
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [June 23, 2023, 6:46pm UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/10 "2023-06-23T18:46:52Z")
I think you might want to start a new topic on this.
Essentially though the first way to avoid garbage collection is not create garbage to begin with. In any language, allocations will need to be deallocated. The question about garbage collection is only about when they will be deallocated. If you avoid allocations to begin by relying on statically allocated structures, then there are fewer issues.
Beyond that, the question is really about whether one can prove that deallocation can happen sooner rather than later and perhaps in a more predictable fashion.
---
### Author:  [@AMJ](https://discourse.julialang.org/u/AMJ)
#### Post date: [June 23, 2023, 6:57pm UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/11 "2023-06-23T18:57:33Z")
The blog post used `unique_prt` a lot throughout the post, I thought maybe it would have been better to post on a semi related post 😃
Most of the technicians for avoiding GC on Julia are actually pretty well defined already and people can find a good amount of info on it here. I was just curious what could be possible theoretically.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [June 23, 2023, 7:02pm UTC](https://discourse.julialang.org/t/eager-finalization-and-smart-pointers/92462/12 "2023-06-23T19:02:52Z")
> [@mkitti](#):
>
> The question about garbage collection is only about when they will be deallocated.
It’s also about spending runtime searching for things to deallocate, no? Without gc, you don’t need to spend time on that.