about summary refs log tree commit diff stats
path: root/073scheduler.cc
Commit message (Collapse)AuthorAgeFilesLines
* 4179 - experiment: rip out memory reclamationKartik K. Agaram2018-01-031-69/+0
| | | | | | | | | | | | | | | | | | | | | I have a plan for a way to avoid use-after-free errors without all the overheads of maintaining refcounts. Has the nice side-effect of requiring manual memory management. The Mu way is to leak memory by default and build tools to help decide when and where to expend effort plugging memory leaks. Arguably programs should be distributed with summaries of their resource use characteristics. Eliminating refcount maintenance reduces time to run tests by 30% for `mu edit`: this commit parent mu test: 3.9s 4.5s mu test edit: 2:38 3:48 Open questions: - making reclamation easier; some sort of support for destructors - reclaiming local scopes (which are allocated on the heap) - should we support automatically reclaiming allocations inside them?
* 4104Kartik K. Agaram2017-11-031-1/+1
| | | | | Stop hardcoding Max_depth everywhere; we had a default value for a reason but then we forgot all about it.
* 4099Kartik K. Agaram2017-11-011-1/+1
| | | | | | | | | | | | | | Generalize commit 4089 to arbitrary closures, and not just the current 'space' or call frame. Now we should be treating spaces just like any other data structure, and reclaiming all addresses inside them when we need to. The cost: all spaces must now specify what recipe generated them (so they know how to interpret the array of locations) using the /names property. We can probably make this ergonomic with a little 'type inference'. But at least things are safe now.
* 3993Kartik K. Agaram2017-09-131-19/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fully isolate routines from their arguments. I still need exceptions for containers that are *designed* to be shared between routines. The primary such case is channels; we need some way to share them between routines, and if we deep-copy them that defeats their entire purpose. A milder case is the use of fake file-systems in tests, though that's a hint that there'll be more of these as the OS gets more fleshed out. The pattern seems to be that we need to not deep-copy containers that contain lock fields, and so their operations internally do their own locking. We may have to stop hard-coding the list of exceptions and allow people to define new ones. Perhaps don't deep-copy any container with metadata of 'shared', and then ensure that get-location is only ever called on shared containers. This still isn't absolutely ironclad. People can now store something into a channel and then pass it into a routine to share arbitrary data. But perhaps the goal isn't to be ironclad, just to avoid easy mistakes. I'd still want an automated check for this, though. Some way to highlight it as an unsafe pattern. This completes step 1 in the plan of commit 3992 for making continuations safe.
* 3992Kartik K. Agaram2017-09-101-2/+1
|
* 3991 - start work on making continuations safeKartik K. Agaram2017-09-101-0/+706
Plan: 1. Fix a hole where addresses are shared between routines when passed in as arguments to `start-running`. 2. Switch to a new approach to refcount management: instead of updating refcounts when writing products of instructions by default, increment refcounts inside instructions by default and decrement refcounts in caller. More details in future when I actually implement this. 3. Now we shouldn't need a distinction between `new-default-space` and `local-scope`, and all functions can simply decrement refcounts of their default-space, consistently handling any refcounts in the space. At this point if all goes well, continuations should be safe! This commit is just preparation for step 1.