freenode/#sicl - IRC Chatlog
Search
11:32:11
heisig
Here is the idea I mentioned this morning: https://gist.github.com/marcoheisig/ada00d4fd0920ec7b2c8223ca6022dc0
11:41:06
MichaelRaskin
heisig: what about currently-running functions with soon-to-be-violated assumptions?
11:43:05
beach
I have been saying for a long time that we are lucky in that we always have all the information of every aspect of the system available, as opposed to languages withe separate compilation. But I have not figured out a way of taking advantage of that fact. This idea seems to be a great step in that direction.
11:43:31
heisig
MichaelRaskin: They don't exist. The thread that invalidates an assumption has to block until all other threads have slowed everything that depends on the assumption.
11:45:45
MichaelRaskin
So if I have a fast function that processes a web server accept loop, anything touching its assumptions has to fail via a timeout?
11:48:37
heisig
MichaelRaskin: Ideally, it would be possible to interrupt that fast function at some point. But if not, is there a better choice than blocking the assumption invalidating thread forever?
11:50:19
MichaelRaskin
Well, having some configurable criteria for failure because of a conflict with currently-running functions
11:52:52
MichaelRaskin
BTW, I guess there could be an assumption «this global variable takes only values of some types»
11:53:21
MichaelRaskin
Given that there are some standard global variables where such an assumption would make sense
11:54:31
heisig
Sure. That is why I think having a single, powerful mechanism for introducing assumptions could be much more robust and maintainable than multiple ad-hoc solutions.
11:57:40
MichaelRaskin
Slowing long-running things on the fly has this annoying problem of things being optimised out and thus hard to provide to the slow version
12:03:59
heisig
In the extreme case, the compiler has to create a particular slowed version for each continuation of a function on the stack.
12:04:53
MichaelRaskin
Well, the problem is not that, the problem is that a properly optimised fast version might be impossible to slow
12:08:07
MichaelRaskin
Imagine that you compute a counter that is only ever read if some global is a string instead of its normal integer value.
12:13:15
heisig
You cannot turn back time. In your example, replacing the function with an appropriate error message sounds like a good thing.
12:15:03
heisig
If a function on the stack has a state that is a consequence of an assumption that is no longer valid, what is your opinion of what should happen?
12:15:36
MichaelRaskin
Well, the question is whether you want to break the function or to fail breaking the assumption
12:16:22
MichaelRaskin
Arguably, if you fail to break the assumption and return the data about the threads running non-slowable functions, one could then interrupt the threads
12:20:56
MichaelRaskin
Well, what I said about dispatching on type and parallel threads could happen simply upstack
12:21:50
MichaelRaskin
change-class is known to call update-instance-for-different-class, which is specified to sometimes signal
12:29:00
MichaelRaskin
On the other hand, many long-living functions are either loops where all the fun stuff happens inside the loop, so if you do enough CPS you might end up accidentally solving this problem
12:32:43
MichaelRaskin
I guess with first-class global environment there is also an option of saying «please slow this global environment as soon as it becomes possible»
15:26:50
jcowan
heisig: The model you describe is well-known to JavaScript implementers under the name of decompilation.
15:29:14
jcowan
Note also that the original JIT compiler for HP APL\3000 (1977) used a variant of this model: the fast version assumes type, rank, and shape invariance, whereas the slow version assumes only type and rank invariance. Because it's a JIT, repeated slow compilations (done on a line by line basis) will produce different results if one of the variables mentioned in the line is type- or rank-polymorphic
15:31:24
jcowan
(Another feature of interest of APL\3000 is that it does lazy evaluation under the covers, though everything looks eager to the user unless they examine the amount of free memory.
15:55:30
heisig
jcowan: Yes, one reason of why I came up with this idea is because of my previous discussions with Lars Bak.
15:55:50
heisig
And I have actually read the HP APL paper - it happens to be relevant to my PhD work.