| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | 2614 | Kartik K. Agaram | 2016-01-29 | 1 | -1/+1 |
| | | |||||
| * | 2581 - make space for the refcount in address:shared | Kartik K. Agaram | 2016-01-20 | 1 | -6/+11 |
| | | | | | | | | | | | | We don't yet actually maintain the refcount. That's next. Hardest part of this was debugging the assume-console scenarios in layer 85. That took some detailed manual diffing of traces (because the output of diff was no good). New tracing added in this commit add 8% to .traces LoC. Commented out trace() calls (used during debugging) make that 45%. | ||||
| * | 2576 - distinguish allocated addresses from others | Kartik K. Agaram | 2016-01-19 | 1 | -7/+9 |
| | | | | | | | | | | | | | | | | | This is the one major refinement on the C programming model I'm planning to introduce in mu. Instead of Rust's menagerie of pointer types and static checking, I want to introduce just one new type, and use it to perform ref-counting at runtime. So far all we're doing is updating new's interface. The actual ref-counting implementation is next. One implication: I might sometimes need duplicate implementations for a recipe with allocated vs vanilla addresses of the same type. So far it seems I can get away with just always passing in allocated addresses; the situations when you want to pass an unallocated address to a recipe should be few and far between. | ||||
| * | 2571 | Kartik K. Agaram | 2016-01-19 | 1 | -0/+83 |
| Reorganize layers in preparation for a better way to manage heap allocations without ever risking use-after-free errors. | |||||