libera/#sbcl - IRC Chatlog
Search
13:40:23
jackdaniel
I've noticed that sbcl finalizers take no arguments - on some implementations they accept as the argument the finalized object (so it could be i.e reintroduced into the environment) -- is there a technical reason why is that or it is just how it is for historical reasons?
13:43:20
stassats
you could touch its husk, but anything else it touches and enlivened only by it will be dead
13:43:46
stassats
so to get a real object you would need some different GC mode, where lots of things are temporarily not dead
13:44:38
jackdaniel
right, in ecl objects are passed to the finalizer before they are collected and left be until the next cycle
13:45:08
jackdaniel
(so the finalizer may decide to reintroduce the object); so in other words that would be technically unsuitable for sbcl
13:46:13
stassats
but how would it know that the only reason the object is alive is because it's referenced by a finalizer
13:48:44
jackdaniel
my understanding is that when it deems some object dead, then it passes it to the finalizer as an argument. but this is quite troublesome, because if objects referenced from that object also have finalizers, then they are postponed further away
13:54:30
stassats
sbcl uses weak pointers for finalization, and then just looks a the weak pointers that became dead
13:55:53
stassats
so for the finalizers it could do, look at the finalized objects, enliven them but mark them as being dead once, then the finalizer runs and removes them from the finalizer store
13:56:28
jackdaniel
interesting! indeed, for that current api makes more sense. thanks again for the explanation
13:57:12
stassats
but i guess what if stays alive but is backed by something that is already finalized, like foreign memory
14:02:45
jackdaniel
I don't understand the remark about backing by a foreign memory that is already finalized
14:03:24
stassats
the finalizer is ready to run on it, and it's just a free() on some foreign memory, but then it stays alive but no longer usable
14:03:27
jackdaniel
if object references that memory, then it won't be garbage collected (because it is reachable from that object) - that's what I've meant when I've mentioned "postponing further away"
14:05:42
jackdaniel
and if it is i.e something like a file handler that is closed in the finalizer, then indeed the object could get corrupted if reintroduced into the environment - but that would be the programmer fault (and wouldn't differ much from closing it normally in a function that is not a finalizer)
14:09:04
jackdaniel
what I mean is "it would be not much different from closing the stream by accident in any other function" -- if I understand correctly that seems to be orthogonal to finalizers
14:09:24
jackdaniel
just like the programmer fault would be capturing the object by the finalizer (as mentioned in sbcl manual)
14:10:59
stassats
if there's no way to free an object other than when it becomes dead, then there can't be a normal situation where it becomes accidentally dead
14:11:11
jackdaniel
yes, and if you do that when you open files then you'll end up with no descriptors in no time
14:12:25
jackdaniel
I agree, it is quite descriptive. either way I know everything I've tried to inquiry- so I'm satisfied, thanks again
14:13:40
stassats
If DONT-SAVE is true, the finalizer will be cancelled when SAVE-LISP-AND-DIE is called: this is useful for finalizers deallocating system memory, which might otherwise be called with addresses from the old image.
14:23:11
Shinmera
So, a lot of publishers are asking me about eventual publishing of Kandria on consoles, especially Switch. I know Switch has a weird microkernel architecture that SBCL would need porting to (along with other libraries I'm sure). Just out of curiosity, would anyone here be available for hiring of such a port, and with an extremely rough estimate, how much work would it entail? It runs on ARM64, so at
14:24:47
Shinmera
I imagine they'd also have a C library of some kind in their official dev kit, but that's closed source and not public, so.
14:25:21
Shinmera
There's a couple of homebrew libraries floating around as well, though I have no clue on their viability.
14:30:45
Shinmera
As far as I understand drivers and everything run as 'services' and you use an IPC protocol to communicate with them.
14:32:36
stassats
i guess the main thing sbcl would want is write protected memory and handling memory faults on it
14:38:56
Shinmera
Fwiw Unity games and such which require a C# runtime with GC run just fine on Switch. I'd be very surprised if it didn't have memory fault handling and write protection.
14:39:59
Shinmera
We're pretty far from the stage of seriously considering a Switch port, but I do want to keep things in mind for the future already.
17:05:03
karlosz
but this time was because i specified null-tn as an immediate-constant-sc in the same way arm64 does
17:05:38
karlosz
to be fair, the reason why it no longer gets selected is because move-if is basically just as cheap at that point, and just 1 byte longer, and no need for thread-tn
17:06:13
karlosz
i think that was the representation issue i ran into before using the arm64 way of doing null-sc
17:06:42
karlosz
i think there wouldn't be such an issue if you use null-sc, since you don't get those redundant moves and you have a bit more precise control over what vops select what
17:07:05
karlosz
the underlying issue is probably that compute-from-flags only takes immediate and constant scs, bu
17:07:24
karlosz
when null is made a descriptor-reg with a wired offset, the vop probably doesnt know what to do
17:07:58
karlosz
or maybe it just decides that loading null-tn into the argument and then doing move-if with that redundant argument is better
17:08:20
karlosz
i need to understand representation selection a bit better to avoid issues like this
17:08:50
karlosz
pretty sure the original mips way of doing things avoided stuff like making load-tns for null-tn
18:21:21
karlosz
ah, so the issue is that constant-tn-p doesn't understand that null-tn is a constant
18:25:31
karlosz
stassats: do you know how to get rid of the redundant move here, or is it impossible? r12 holds null-tn. https://pastebin.com/a17fmVX7
19:39:10
stassats
i have 2: MOVE-IF/DESCRIPTOR t8[R0] :NORMAL DESCRIPTOR-REG T t12[NULL] :COMPONENT DESCRIPTOR-REG LIST {(:EQ)} => t13[R0] :NORMAL DESCRIPTOR-REG T
19:46:40
karlosz
true, but it seems unrelated to the issue at hand, since the problem seems to be at the vop level, right?
19:53:19
stassats
i also didn't do the multi-flag option right, but arm64 doesn't have any, so it's under a rag at the moment