Don’t small arrays live on the stack? > On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution > <[email protected]> wrote: > > As far as I can tell, currently, all arrays live on the heap. > >> Le 3 août 2017 à 19:03, Robert Bennett via swift-evolution >> <[email protected] <mailto:[email protected]>> a écrit : >> >> 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 >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> >>> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
