With apologies for the deletions -- there were unintended editing errors of some consequence -- my comment, now as intended is found in this thread https://github.com/JuliaLang/julia/pull/16999.
On Saturday, June 18, 2016 at 6:33:37 PM UTC-4, Scott Jones wrote: > > @rfourquet commented in #16999: > >> I don't have any example where this would be an issue, and honestly I >> didn't think to much about this problem, I just thought it looked safer (so >> I step back!). I myself have occasionally used x+0 to get a "deep copy" >> of a BigInt x. But @yuyichao <https://github.com/yuyichao> said anyway >> it was not the use case he wanted to address, but rather the finalise >> problem... >> ps: to sort an array, a shallow copy should suffice, no? > > > I investigated the memory corruption (which apparently has been around > ever since deepcopy was implemented in Julia), because @chrisraukaukas had > run into it with his DifferentialEquations.jl package. > He was doing deep copies of vectors of vectors. > > What exactly is the finalize problem that is solved by #16999? There is > none that I am aware of with my solution, and #16999 does not implement any > general solution to the problem that deepcopy has, when it uses reflection > to copy types that have memory managed outside of Julia. That is a > problem that needs to be addressed. > > @yuyichao replied to my comments on GitHub: > > I'm concerned about the performance implications of PR #16999 > <https://github.com/JuliaLang/julia/pull/16999>, which makes a copy any > BigFloats or BigInts when doing deepcopy. > > So the suggestion is that if an operation following the defined schematics >> is too expensive, we should just ignore what the function should do and do >> nothing instead. > > > That is not at all what I've been saying. I am saying that if in Julia we > logically consider BigInts and BigFloats to be immutable (as we do all > types that are <: Number), then we shouldn't have to make things much > slower to cater to people who > *might be* breaking that convention by playing with the internals of a > Base julia type. > Also, in general performance has been taken into consideration when > deciding on the behavior of Julia. This isn't even a case where you get > incorrect behavior by treating BigFloats/BigInts as they already are in > many places, > as being immutable values, instead of a reference to a mutable value. > > He also commented: > > The rationale for doing so is that somebody might bypass the BigInt and > BigFloat types, and directly operate on their GMP/MPFR internals. > > No it's not. > > > It would be useful then to explain just why #16999 is really a better > solution than #16826 instead of just saying "it's not". > > About the performance implications, on my MacBook Pro, doing a deepcopy of > 1 million BigFloats: > > Master: > > 3.660420 seconds (5.00 M allocations: 159.021 MB, 6.39% gc time) > PR #16286 > > 0.159178 seconds (3.00 M allocations: 68.650 MB, 7.23% gc time) > PR #16999 > > 1.670144 seconds (5.00 M allocations: 197.168 MB, 20.20% gc time) > > > So, I ask, why would one want to make something over an order of magnitude > slower, using almost 3x the memory, just to protect against the possibility > that some code is abusing the internals of one of the Base types? > > We don't do that in other places for the string types, which have the > exact same issue. > > > > >
