Why does each BigFloat allocate a big String in addition to the MPFR big float object?

nsajko · January 10, 2023, 7:18am

I’m doing allocation profiling on some code that uses BigFloats at precision 2048, and I noticed that each time a BigFloat is allocated, half of the allocation seems to go to the MPFR object, and the other half to a String.

The relevant code in base/mpfr.jl calls this String a “gc handle”. I don’t know why this is necessary, but surely these String objects should take up much less than half space allocated for the Bigfloat?

The initial part of the BigFloat definition:

github.com

JuliaLang/julia/blob/master/base/mpfr.jl#L90-L108


      
          mutable struct BigFloat <: AbstractFloat
              prec::Clong
              sign::Cint
              exp::Clong
              d::Ptr{Limb}
              # _d::Buffer{Limb} # Julia gc handle for memory @ d
              _d::String # Julia gc handle for memory @ d (optimized)
          
          
    # Not recommended for general use:
              # used internally by, e.g. deepcopy
              global function _BigFloat(prec::Clong, sign::Cint, exp::Clong, d::String)
                  # ccall-based version, inlined below
                  #z = new(zero(Clong), zero(Cint), zero(Clong), C_NULL, d)
                  #ccall((:mpfr_custom_init,:libmpfr), Cvoid, (Ptr{Limb}, Clong), d, prec) # currently seems to be a no-op in mpfr
                  #NAN_KIND = Cint(0)
                  #ccall((:mpfr_custom_init_set,:libmpfr), Cvoid, (Ref{BigFloat}, Cint, Clong, Ptr{Limb}), z, NAN_KIND, prec, d)
                  #return z
                  return new(prec, sign, exp, pointer(d), d)
              end

The BigFloat constructor that creates the String object:

github.com

JuliaLang/julia/blob/master/base/mpfr.jl#L110-L119


      
              function BigFloat(; precision::Integer=DEFAULT_PRECISION[])
                  precision < 1 && throw(DomainError(precision, "`precision` cannot be less than 1."))
                  nb = ccall((:mpfr_custom_get_size,:libmpfr), Csize_t, (Clong,), precision)
                  nb = (nb + Core.sizeof(Limb) - 1) ÷ Core.sizeof(Limb) # align to number of Limb allocations required for this
                  #d = Vector{Limb}(undef, nb)
                  d = _string_n(nb * Core.sizeof(Limb))
                  EXP_NAN = Clong(1) - Clong(typemax(Culong) >> 1)
                  return _BigFloat(Clong(precision), one(Cint), EXP_NAN, d) # +NAN
              end
          end

nsajko · January 10, 2023, 7:32am

Now that I think about the code, I guess the intent behind it is for the String object to hold the memory of the MPFR object, so there shouldn’t be any additional allocation? So I guess this is a bug in the allocation profiler?

Here’s a screenshot of the Julia allocation profiler in the Code editor:

thofma · January 10, 2023, 8:02am

Yes, there is no additional allocation (your interpretation of the String object is correct).

Why do you think there is a Bug in the allocation profiler?

nsajko · January 10, 2023, 8:16am

Because two equal allocations are noted, both in the flamegraph and in the annotated source, instead of just one.

thofma · January 10, 2023, 8:37am

The BigFloat object is allocated and the String is allocated. Why should there be one?

nsajko · January 10, 2023, 8:58am

Before we exit the BigFloat constructor, there are already two allocations, as shown in both the flamegraph and the annotated source.

EDIT: I’m talking about this, specifically:

Within the constructor, there are two equal allocations shown, and then the total is their sum. I guess this causes the profiler to double-count the BigFloat size?

skleinbo · January 10, 2023, 9:46am

Yes, because the BigFloat object is instantiated/allocated in the call to _BigFloat.

If you look at the allocation profile, you will find there are two kinds of allocations; the string and the BigFloat (although the profiler can’t figure out the type here and calls it UnknownType). As you can see, they are of different size. Play with precision and observe the string allocation change size. It isn’t doubly allocated though.

Profile.Allocs.@profile for i in 1:10000000 BigFloat(;precision=2048) end
result = Profile.Allocs.fetch()
result = sort(result.allocs, by=x->x.size)
result[[begin,end]]

2-element Vector{Profile.Allocs.Alloc}:
 Profile.Allocs.Alloc(Profile.Allocs.UnknownType, Base.StackTraces.StackFrame[ijl_gc_pool_alloc at libjulia-internal.1.8.dylib:?, ...], 48)
 Profile.Allocs.Alloc(String, Base.StackTraces.StackFrame[ijl_alloc_string at libjulia-internal.1.8.dylib:?, ...], 256)

nsajko · January 10, 2023, 9:57am

Ah, I thought the profiler was reporting allocation size, but I guess it’s only considering the number of allocations. The Code editor Julia plugin, I mean.