Where do constant Arrays currently live? I hope the answer is on the stack, since their size doesn’t change.
> On Aug 3, 2017, at 8:44 PM, Taylor Swift via swift-evolution > <swift-evolution@swift.org> wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > <swift-evolution@swift.org> wrote: >>>> >>>> The root cause, of course, is that the VLAs require new stack allocations >>>> each time, and the stack is only deallocated as one lump when the frame >>>> ends. >>> >>> That is true of alloca(), but not of VLAs. VLAs are freed when they go out >>> of scope. >>> >> >> Learned something today. >> >> Anyway, if the goal is stack allocation, I would prefer that we explored >> other ways to achieve it before jumping to a new array-type. I’m not really >> a fan of a future where [3; Double] is one type and (Double, Double, Double) >> is something else, and Array<Double> is yet another thing. > > They are completely different things. > > [3; Double] is three contiguous Doubles which may or may not live on the > stack. > > (Double, Double, Double) is three Doubles bound to a single variable name, > which the compiler can rearrange for optimal performance and may or may not > live on the stack. > > Array<Double> is an vector of Doubles that can dynamically grow and always > lives in the heap. > >> >> From what I’ve read so far, the problem with stack-allocating some Array >> that you can pass to another function and which otherwise does not escape, >> is that the function may make an escaping reference (e.g. assigning it to an >> ivar or global, or capturing it in a closure). >> >> How about if the compiler treated every Array it receives in a function as >> being potentially stack-allocated. The first time you capture it, it will >> check and copy to the heap if necessary. All subsequent escapes (including >> passing to other functions) use the Array known to be allocated on the heap, >> avoiding further checking or copying within the function. >> >> The same goes for Dictionary, and really any arbitrary value-type with COW >> storage. The memory that those types allocate is part of the value, so it >> would be cool if we could treat it like that. >> > > This is not true. FSAs have nothing to do with automatic storage, their > static size only makes them eligible to live on the stack, as tuples are now. > The defining quality of FSAs is that they are static and contiguous. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
