[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sbcl-devel
Subject:    Re: [Sbcl-devel] TLS disappears during GC
From:       Douglas Katzman via Sbcl-devel <sbcl-devel () lists ! sourceforge ! net>
Date:       2023-07-01 1:02:21
Message-ID: CAOrNaswJq2u80ySpPqA3D7ruen53qYKbv-_UAX5oS1C6rM+uSA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Off-topic from your original post, but: For the time being I have given up
the dream of implementing a concurrent algorithm that can handle SBCL's
weak tables. I will probably put a mutex into the weak object clearing
step, and a mutex into the deref operator. Barring mutex contention, GC
won't induce pauses to threads that don't touch weak objects at that exact
time.
All the while, I had been thinking that a model for a "new-style" SBCL
weak-keyed table is a weak-vector and an ordinary simple-vector in 1:1
correspondence holding K and V respectively.
That's not right because SBCL weak tables are strictly more useful than
Java's weak hash-tables in the following sense:
An SBCL weak-keyed table conditionally enlivens each value only if the key
is strongly reachable. Every pair resembles an ephemeron
<https://en.wikipedia.org/wiki/Ephemeron>.
But xof shrewdly pointed out that Java WeakHashMap documentation says: "The
value objects in a WeakHashMap are held by ordinary strong references. Thus
care should be taken to ensure that value objects do not strongly refer to
their own keys, either directly or indirectly, since that will prevent the
keys from being discarded"
So any research paper about what Java does tends to look at the problem
through that lens. Whereas we want not to lose functionality. So in the
two-vector design, each has to be weak, but reference to one has to
possibly enliven the cell in the other.  Your thoughts on this would be
appreciated.
Doug

[Attachment #5 (text/html)]

<div dir="ltr"><div>Off-topic from your original post, but: For the time being I have \
given up the dream of implementing a concurrent algorithm that can handle SBCL&#39;s \
weak tables. I will probably put a mutex into the weak object clearing step, and a \
mutex into the deref operator. Barring mutex contention, GC won&#39;t induce pauses \
to threads that don&#39;t touch weak objects at that exact time.</div><div>All the \
while, I had been thinking that a model for a &quot;new-style&quot; SBCL weak-keyed \
table is a weak-vector and an ordinary simple-vector in 1:1 correspondence holding K \
and V respectively.<br class="gmail-Apple-interchange-newline"></div><div>That&#39;s \
not right because SBCL weak tables are strictly more useful than Java&#39;s  weak \
hash-tables in the following sense:</div><div>An SBCL weak-keyed table conditionally \
enlivens each value only if the key is strongly reachable. Every pair resembles an  \
<a href="https://en.wikipedia.org/wiki/Ephemeron" \
target="_blank">ephemeron</a>.</div><div>But xof shrewdly pointed out that Java \
WeakHashMap documentation says: &quot;The value objects in a WeakHashMap are held by \
ordinary strong references. Thus care should be taken to ensure that value objects do \
not strongly refer to their own keys, either directly or indirectly, since that will \
prevent the keys from being discarded&quot;</div><div>So any research paper about \
what Java does tends to look at the problem through that lens. Whereas we want not to \
lose functionality. So in the two-vector design, each has to be weak, but reference \
to one has to possibly enliven the cell in the other.   Your thoughts on this would \
be appreciated.    </div><div>Doug</div></div>





_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel


[prev in list] [next in list] [prev in thread] [next in thread]