freenode/#clasp - IRC Chatlog
Search
9:09:06
beach
Oh, I have a better idea for the inlining-by-local-graph-rewriting technique. It will work for assignments and for references to free variables as well. And for loops.
9:40:26
Shinmera
beach: By the way, the assistant /finally/ said that he definitely won't supervise my thesis last week, so now I'm back to square one, trying to find someone.
9:57:20
beach
Shinmera: Your considering it made me work out an algorithm, so it had some good consequences after all. At least for me.
9:57:27
Shinmera
I don't understand how 100+ students are supposed to find a bachelor's thesis here. Almost nothing is posted, and most of the profs you talk to either don't really have much of an idea, no time, or don't like your ideas, or all of the above.
9:58:31
Shinmera
Anyway, I'm in talk with other people now, so hopefully I can find something sometime soon-ish. Sigh.
12:04:15
beach
New figures for new inlining technique: fig21.pdf - fig27.pdf on the metamodular site. I don't dare type the URL because I was considered a spammer by freenode when I did that.
12:06:57
Shinmera
Yeah, they recently made a change in policy. Posting lines too frequently gets you automatically banned.
12:09:17
beach
The new technique copies the entire lexical environment of the callee into the caller. It keeps a mapping between callee instructions and caller instructions to avoid copying an instruction multiple times.
12:10:41
beach
The CALL to be inlined, copies the entire copied callee environment to the callee so that execution can be resumed in the callee at any point, thus allowing partial inlining.
12:17:12
beach
The technique obviously doesn't work for recursive functions. Exercise for the reader: In what other situations does it not work?
12:58:06
Shinmera
beach: So of the three topics you suggested to me, which would I still be able to do my thesis on?
15:11:38
Shinmera
Path Replication Using Local Graph Rewriting in Intermediate Code, Control-Flow Analysis in the Presence of Nested Functions and Threads, Partial Inlining of Local Functions Using Local Graph Rewriting
15:58:30
frgo
Oh hi. Good ;-) I get an error on the following line: https://github.com/drmeister/clasp/blob/dev/wscript#L550
15:59:20
drmeister
Sorry - I've been wrapped up in this generic function multithreading issue and not getting 'dev' buildable.
16:01:06
drmeister
I'm not certain that 'dev' will build though - I'll push to testing and give it a try.
16:03:54
drmeister
frgo: The multi-threading issue is on both the lisp side and C++ side. It's the most complicated resource that I've tried to make thread safe - I'm having trouble figuring it out.
16:06:02
frgo
You mentioned "race condition" here ... I don't want to hold you up but I'd be interested to understand a tiny bit more - only if it is explainable in a few lines..
16:08:32
drmeister
Each generic function also has an a-list that maps previous invocation signatures to effective method functions.
16:10:03
drmeister
When a call history changes (several ways that can happen) the discriminating function is set to the 'invalidated-dispatcher' function.
16:10:43
drmeister
When a generic function call happens and it jumps to the invalidated-dispatcher function a new discriminating function is compiled from the call history.
16:12:09
drmeister
No generic functions are invoked when the discriminating function is compiled - but I have to put a write-lock on the code that compiles the discriminating function so that multiple threads don't try to compile/install discriminating functions at the same time.
16:12:57
drmeister
Besides that I need to put write locks on other code that updates the generic function call history, specializer profile, method list etc.
16:13:43
drmeister
Somewhere I'm getting a deadlock when something that has the lock calls something that wants a lock.
16:15:21
frgo
For that 1 generic function's dependent objects like call history etc - so for each GF just 1 lock - or do I misinterpret sth?
16:16:30
drmeister
So not one lock for all generic functions or one lock for each generic function resources - just one lock per generic function.
16:18:26
frgo
Ok - I am thinking: That one lock per GF must be enough - no other locks required as everything else is required to be sequential updates / needs to be synchronized to that one lock.
16:18:27
drmeister
I think I just need to struggle through this - I can barely describe the problem.
16:20:16
frgo
Now you need to pass on the lock through code that is allowed to update the resource - the lock has to be a thread-local variable. If the lock passed on and tghe lock being thread-global are the same the resource is allowed to update.
16:21:58
drmeister
src/lisp/kernel/clos/closfastgf.lsp and src/core/funcallableInstance.cc and src/core/funcallableInstance.h
16:23:14
drmeister
Don't trouble yourself too much - I think I just need to think about it harder. Also, I haven't pushed out the latest code - because it doesn't build yet.
18:21:14
drmeister
I can't write lock the entire generic function when there is a dispatch-miss - that deadlocks.
18:21:52
drmeister
It deadlocks because the same generic function is invoked in the course of the dispatch miss.
18:25:07
drmeister
I'm starting to think though that the generic function read/write lock should be to guard against two threads updating anything in the generic function other than the discriminator function.
18:25:33
drmeister
The discriminator function is an atomic object, a single pointer to a block of code.
18:28:01
drmeister
If two threads each evaluate the same generic function and they both lead to a dispatch miss - then I need to protect the call-history from being updated by two threads at the same time - but not the discriminating function.
18:28:33
drmeister
If one thread updates the discriminating function and then the other overwrites it - it's no big deal. There will be another dispatch-miss and that will rebuild the discriminating function again.