Comments (4)
The actual issue (/ design incompatible with this large-item usage) lies within the method implementations, for example in swapRemove
:
const old_item = self.get(i); //tells the compiler to save a copy on the stack
self.set(i, self.pop()); //pop returns the last entry on the stack, set overwrites index i completely with this value
return old_item; //returns the previously-saved copy
It would technically be possible:
- (1) for the compiler to recognize the result will be discarded via
_ =
, and produce a "discarded-result-location" variant of the function,
so thatold_item
is deduced to not be allocated on the stack (liveness analysis figures out it's immediately "dead"/unused) - (2) copy the last value into index i piecewise, so effectively instead use
@memcpy
followed by apop()
that also just discards and doesn't save the value on the stack
While I think that introducing such transformations in the long-term at some point would be nice, I also think it's likely for the suggestion to be rejected by maintainers for language simplicity (more directly mapping the code you write to the assembly generated).
If they are rejected it would be up to the user to implement a popOverwrite
method for (2) and a swapRemoveDiscard
method for (1) by hand.
Either way, I do think the compiler should produce a compile error once it detects too high stack usage, i.e. not produce an executable that segfaults because of this issue at run time.
This is in some ways related to the mechanisms behind #157 .
from zig.
BoundedArray
was designed for small arrays that are passed around as a single value on the stack.
What you're doing here is equivalent to declaring a type which is more than 12,800,000 bytes large.
Even if you reserve that much space on the heap, types are assumed to be small. You can't access a value so large that it wouldn't even fit on the stack.
from zig.
Ideally, manipulation of heap data stays on the heap.
Not possible without an implicit heap allocation which is obviously a no-go for Zig. The ideal solution would be to force a compilation error when the compiler is required to put very large values on the stack.
This issue is not unique to BoundedArray
or even Zig itself. If you are actually having this problem in real world code I would recommend using an array of pointers instead of values.
from zig.
The maximum stack size could only be checked at runtime. It can be set per thread, stacks can also be switched (very common for coroutines), stacks can also grow...
So the compiler could raise an error based on some arbitrary limit, just like it could refuse to compile a loop if it could spin for too many iterations. But arbitrary limits are not great. They don't mirror the reality, nor crazy things developers may legitimately do.
The actual issue you are raising here is that there are cases where a value is unused, yet its computation is not optimized out in debug mode (your code example doesn't segfault in ReleaseSafe
and ReleaseFast
modes).
I guess trying to do that kind of optimization in debug mode, that intentionally doesn't do optimizations, would slow down compilation with little benefits. The stack overflow you are getting in debug mode highlights a design error in the data structures the code is using, so it's actually useful.
from zig.
Related Issues (20)
- Zig build system incorrectly parses some depfiles generated by Rust on Windows
- implement std.Progress for single-threaded mode
- std.Progress: add byte unit flag and resource scope; support throughput calculation
- implement std.Progress IPC for WASI
- implement std.Progress IPC for Windows
- add support for targeting glibc 2.39
- Progress display is cut off horizontally HOT 2
- `zig fmt` outputs invalid syntax when formatting an error set with doc comments onto one line
- Latest master tarball is unable to build a stage4 zig HOT 3
- upperBound and lowerBound has inconsistent callback types HOT 1
- "offsetof" from C header does not handle union within struct HOT 2
- x86_64 backend miscomp
- When compiling for android, and linking libc, you will always hit a @compileError HOT 1
- Progress cuts off prints to the terminal HOT 5
- x86_64 backend `genSetReg called with a value larger than dst_reg`
- Crash when using ArrayList init with ArenaAllocator HOT 1
- error: NoSpaceLeft with MacOS target on x86 host HOT 2
- Thread.Pool cannot be spawned with !void function HOT 1
- New progress goes in the way of interactive CLI apps HOT 1
- setting global cache directory to relative path causes build failure of dependencies HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zig.