freenode/#clasp - IRC Chatlog
Search
4:50:44
drmeister
Lang Hames (Apple software engineer and developer of the ORC JIT) just added what should be the last thing that we need to switch to ORCv2 on linux.
4:51:49
drmeister
I'm in process of testing it. If it works - then the path should be clear to image save/load.
4:52:54
drmeister
Also, we should be able to switch back to the small code model and switching away from that when we switched to faso files had a large impact on stack unwinding speed.
4:53:43
drmeister
We've bypassed stack unwinding with C++ exceptions in many important cases. But the ones that we couldn't get away from should improve now.
14:21:24
drmeister
I got clasp building against llvm12 pulled last night with Lang’s new changes for jitlink and linux.
14:21:54
drmeister
Testing it failed on Linux so I sent him the module and object file that broke it.
14:22:27
drmeister
Currently in the future branch aclasp and bclasp build and run. Cclasp is broken.
14:24:08
drmeister
I’ll implement the new code gcing and then I’ll fix backtraces and then I’ll tackle cclasp
14:43:00
drmeister
Bike - backtraces are broken. The name of the functions in the backtraces are wrong. I’ll dump and example.
14:43:43
drmeister
It means the function that takes a return address and returns a function name is broken - right?
14:50:46
Bike
this is in your branch, right? maybe the template stuff you put in involves actual pointers
14:52:52
drmeister
Going forward we should have just two ways to search symbols. 1. executable/libraries 2. object files in memory from jitting, faso files and image save/load.
14:55:17
drmeister
operating_system_backtrace calls the operating system 'backtrace(buffer,num)' facility.
15:09:55
drmeister
We create a std::vector<BacktraceEntry> - BacktraceEntry is a low level C++ object, not exposed to Common Lisp. We fill it with everything that we can get.
15:10:34
drmeister
Then we copy the info into Frame_O objects, cons up a list of them and pass them to a callback using (core:call-with-backtrace ...)
15:11:09
drmeister
That way it's clear what is in the backtrace. Everything above the callback is in the backtrace and everything below it is not.
15:14:15
drmeister
I broke up gc_interface.cc into 8 files and astExpose.cc into two. It shaves several minutes off the C++ build.
15:28:59
drmeister
Object file maintenance is tied up in what I'm doing here - so it's not surprising that I broke somethign.
15:34:21
drmeister
Ah - it's getting the name out of the FunctionDescription_O - and those are also broken.
15:36:08
drmeister
Then we use that to look up the function description and pull the name out of that.
15:39:15
drmeister
https://github.com/clasp-developers/clasp/blob/future/src/llvmo/debugInfoExpose.cc#L510
15:39:43
drmeister
And that will take a return address and should return a bunch of info about the function from the very roundabout path through the object file.
15:45:06
drmeister
We need to make FunctionDescription_O objects literals so they can be saved and reconstituted by the literal compiler.
15:50:41
Bike
"In the case of exact garbage collection, yieldpoints are known as GC-safe points" yeah, ok.
15:56:23
drmeister
--verify-safepoint-ir , --rewrite-statepoints-for-gc , --strip-gc-relocates , --place-safepoints
15:57:08
drmeister
There's a thing in llvm where you can use address-space(1) for certain pointers and the --rewrite-statepoints-for-gc does something to them with yieldpoints that makes them gc roots.
15:57:29
drmeister
Now - we can't get that for C++ code I don't think - but it would be good to understand it.
16:00:36
drmeister
Anyway, yieldpoints are what Steve Blackburn calls them and they are integral to MMTk.
16:01:13
drmeister
In MPS there is a complicated song and dance for allocations that avoids the problem of scanning incompletely initialized objects.
16:01:38
drmeister
Boehm doesn't care - it will scan anything in the conservative mode and I still don't see how the precise mode is supposed to work.
16:08:28
drmeister
I was surprised by this in the paper: "We find that Java benchmarks execute about 100 M yieldpoints per second,"
16:08:49
drmeister
I was always afraid that the impact on performance would be high - but if Java can support this then it can't be that bad.
16:10:07
drmeister
Thinking about yieldpoints - they could enable other things like truly lock free data structures.
16:10:57
drmeister
If I can pause each thread when I can guarantee that not one of them is in a certain block of code - then I could fix up data structures so that they could always be read lock free.
16:13:27
drmeister
But I could represent it as a hash-table and an atomic linked list of fixups that at certain yieldpoints would be applied to the hash-table.