freenode/#clasp - IRC Chatlog
Search
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.
16:16:08
drmeister
Pause the world when we can be sure that certain data structures are not actively being altered, fix them up and then set the world in motion again.
16:34:06
docl
drmeister: I know this is a little off topic here but just wondering your opinion, is artificial photosynthesis by spiroligomer photocatalyst decades away, or has the foundation already been laid? I note there are competing approaches in this realm already, e.g. nanowire photocatalysts https://patents.google.com/patent/US9528192B1/en
16:36:10
docl
I'm a little skeptical of the nanowire approach being cost effective for large areas. ideally you'd have something that can go over large cropland areas or maybe big ponds akin to solar salt production facilities
17:09:02
drmeister
Bike: I think with pausing the world you can control how often you do it with a lot of control./
17:09:56
drmeister
We would add an atomic linked list of hash-table 'fixups' like an a-list that gets searched alongside the hash-table.
17:10:36
drmeister
So to write to the hash-table you push a #<hash-table-write key value> onto the atomic fixup list.
17:11:41
drmeister
GETHASH would then check the hash-table and the fixup list - this would be lock free.
17:12:08
drmeister
You don't want the fixup list to get too long because it's linear time to check it.
17:12:42
drmeister
Occasionally, when you know that no thread is reading the hash-table you pause, apply the fixups to the hash-table and clear the fixup list.
17:13:31
drmeister
We can control how long we let the fixup list grow before you want to pause and fix hash-tables.
17:14:01
drmeister
The implementation of the fixup list would probably be a vector for faster reads.
17:14:49
drmeister
Oh - you know what - you can' use a vector - because that can't be updated atomically without a mutex.
17:15:33
Bike
you can update a vector atomically. you just atomically increment the fill pointer, then store whatever at the old index. right?
17:16:23
Bike
i guess there'd be another problem if another thread is simultaneously reading the vector up to the fill pointer, and gets the uninitialized entry