libera/#sicl - IRC Chatlog
Search
6:14:42
moon-child
(where 'cohering' is just copying the contents of the global copy into the local copy. This is conservative--we do it just in case there was a write which future accesses to the local copy were synchronised with respect to. If those hypothetical accesses are _not_ synchronised wrt anything, and there were unsynchronised writes, then the program is inherently racy and we just happened to observe
6:19:52
hayley
My prior idea would still require a branch on every sequencing operation, too, to see if there's any updates that need to complete before we can continue.
6:21:19
moon-child
I don't think your idea would require branches for ordinary atomic accesses, only for blanket fences
6:21:46
hayley
I'd have to wonder how frequent writes to replicated objects are, because having a counter of replicated writes that are being made would be handy.
6:22:16
moon-child
since the lock ensures that the state of a replicated object never stays incoherent, and if you synchronise with somebody via acqrel, then that's it--you synchronised with them
6:23:11
moon-child
that said I think lock free is better. Following gil tene 'What could happen (and sneak in) if this one instruction takes 10 minutes to execute?'
6:28:38
hayley
I should write down the issues somewhere, because there are a few. We need to implement fences such that replicated writes complete either entirely before or after the fence. Writes also should never occur when a nursery collection is running; when a nursery collection starts, all mutators should only write to the global version (as, at that point, no one can observe the local version). Okay, I guess I counted one too many issues.
6:29:31
hayley
The latter might be a special case of the former; we might just need to disable replication, and then fence.
6:38:37
hayley
Okay, one more issue: how do you do an atomic update on a replicated slot, say, a compare-and-swap? The locking way provides sequential consistency whether one likes it or not.
6:39:36
moon-child
'Writes also should never occur when a nursery collection is running' with semispace, you just have to make sure the write finishes before the _next_ nursery collection finishes, which should be less work
6:40:12
moon-child
'atomic update on a replicates slot' assuming there are no flaws with my scheme for relaxed writes, I think it would work just the same
6:40:17
hayley
I should mention, this sort of copying applies to assigning unboxed values too, which will be "fun". But the static analysis to show that an object cannot become replicated is probably not too hard, so it might not matter too much.
6:42:44
moon-child
'assigning unboxed values' ugh ... hmm ... maybe it's ok to just eagerly pretenure all type-specialised arrays?
6:43:27
moon-child
after all, if you're using type-specialised arrays, it must be because you care about performance, and the performance advantage probably only starts to show once the array is reasonably large?
7:20:20
hayley
The Sapphire paper states "when the collector is done copying the (volatile field or fields of the) object, volatile accesses occur on the New copy of the field." i.e. there would be a similar barrier.
7:20:47
moon-child
'CASing on the global copy' I was imagining all write ops would take a write barrier, and if they find they're on the local copy, they first update their pointers to point at the global copy (just like with a concurrent gc)
7:21:06
moon-child
for ordinary reads you wouldn't need a barrier, but for atomic reads specifically, you would need the same barrier
7:23:20
hayley
You're probably right about pretenuring specialised arrays, as we don't gain much from moving them, and writes to such arrays cannot cause other objects to escape the nursery, either.
7:24:48
moon-child
hmm. Maybe actual ABA is rare. In that case, can we penalise the writer of the second A?
7:30:46
hayley
It would appear that Hudson and Moss don't think Sapphire would behave correctly when a program has a data race on a non-volatile field; seemingly they can't make the replicas coherent when two writers race to write replicated objects.
7:31:10
moon-child
wait, no, what am I thinking? There's no ABA problem. If the initial state is A, and t1 tries to write B, and t2 tries to write A, then we can have: t1 exchanges B into global, gets A; t2 exchanges A into global, gets B; t2 tries to cas A into local, but fails, because local wasn't B
7:32:18
moon-child
(I haven't proven that there can be no ABA issues, but this is the case that I was thinking of)
7:39:03
hayley
I'd hope still that replicated writes are the uncommon case, and if there are too many writes in a short period of time, a minor GC is performed instead to promote the objects more eagerly. The idea I had was just to reduce the number of times we need to force minor GC.
7:40:26
moon-child
I thought the point of replication was to deal with cases where pretenuring would pessimise, like mapcar
7:45:19
hayley
It's great that we have to treat this as a distributed system, even though this is a shared memory system, because of a distinct lack of transactional memory. /me continues grumbling
7:46:38
hayley
So now it's everything I dislike debugging in one: replication protocols, memory models, and garbage collection.
12:03:31
yitzi
Has there been any discussion, WSCL or otherwise, on additional key arguments in TRANSLATE-PATHNAME, TRANSLATE-LOGICAL-PATHNAME and by extension additional values in the translation lists? The CLHS says that additional key arguments are permitted in TRANSLATE-PATHNAME and TRANSLATE-LOGICAL-PATHNAME. Seems like this would have been more useful with lambda list like INITIALIZE-INSTANCE. i.e with a &REST and &ALLOW-OTHER-KEYS.
12:05:02
beach
I have not seen any such discussion. And I haven't looked very hard into pathnames myself.
12:09:32
yitzi
Yeah, I am trying to remove absolute pathnames that come from source references in Clasp. Need to do so for a redistributable binary. I am suspicious I'll have to add some implementation specific keys to translate-pathname.
12:10:21
beach
Though, now that I think about it, specifying &ALLOW-OTHER-KEYS would not be the same as allowing other keys.
12:11:04
beach
Specifying &ALLOW-OTHER-KEYS would mean that any keyword argument could be given, including some that are not supported by the implementation.
12:11:42
beach
Whereas "allowing other keyword arguments" might just mean that the set is still fixed, but it may be larger than what is mentioned in the standard.
12:16:49
mfiano
I would parse that as the set is of undefined size, meaning it could be fixed or allow anything.
13:17:38
yitzi
beach: Clasp has an ASDF groveler that we use when running under SBCL to extract the source files for Cleavir, etc. I've had to rewrite it to account for systems that have :if-feature style feature expressions. Its not in Clasp main branch yet because the branch is still experimental. Maybe useful for SICL though. https://gist.github.com/yitzchak/0c7a7302c04391787d26a59336c3a1f1
13:20:29
beach
yitzi: Thanks. Anything in particular that made you think about SICL for this library?
13:22:28
yitzi
I seem to recall SICL needing to use ASDF systems from the host that might be different in SICL eventually. I could be just thinking of when I was trying to load the sequence functions though. Its been a while since I bootstrapped SICL.
13:26:45
beach
It needs to create its package based on the host Common Lisp system. And since I use host packages during bootstrapping, I had to create the same package in two different ways, one for the host Common Lisp system, and one for SICL.