Comments (3)
A basic design could look like this:
- Generate a class for each method body which represents the stack frame; stack frame instances would implement a common interface or superclass, and would form a linked list representing the call stack, with a field for each value slot (i.e. an unlimited-register machine).
- Generate a class for each object, perhaps with a degree of mapping between the virtual type hierarchy and the generated concrete type hierarchy; the generated class would include fields that mirror the virtual type's fields, and methods that correspond to the virtual type's methods with added parameters for the caller's frame and possibly the current thread.
This design would avoid the need to employ a register allocator or other potentially complex/time-consuming analysis steps, at the expense of build-time memory footprint (but note that this is still much better than the map-based approach being used right now). Since the majority of build time code is expected to execute few times (often just once), this seems like a fair tradeoff.
from qbicc.
Another option would be to eschew the stack frame class in favor of using local variables directly, but some solution for stack walking would still be necessary (for building exception stack traces if nothing else). Walking the real stack using the host's StackWalker
and mapping each frame to a virtual frame is one possible solution.
from qbicc.
Done.
from qbicc.
Related Issues (20)
- Invalid llvm ir for blockarg generated when a `cast` is applied to the result of an `auto` HOT 2
- Hidden class names & reproducibility
- Reflection: finer-grained treatment of Methods
- Assertion error processing anonymous inner class
- InvalidMemoryAccess for native struct with embedded union HOT 7
- Better handling of `undef` values in llvm codegen
- Improve exception handling in diagnostics HOT 1
- Stack smashing bug on Linux in java.net.NetworkInterface$_qbicc.addif HOT 1
- Linux-specific hang using CountDownLatches -- futex bug?
- Ambiguity with `ptr<Object>` HOT 2
- Fix up stack traces
- `org.qbicc.object.Function*` should not be locked to `FunctionType`
- Matching monitor enter/exits
- "Fix non-reducible loops" step
- Inline assembly return type doesn't work well with pointers
- Reflection on interfaces includes `Object` methods
- Interpreter support for `ByteBuffer` HOT 1
- Instanceless virtual allocator methods HOT 1
- Intrinsic methods for memory fill, clear, copy, and swap
- `Convert` and `ValueConvertLiteral` are not equivalent HOT 1
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 qbicc.