Quali sono i vantaggi di StableNames rispetto a reallyUnsafePtrEquality # e viceversa?

Question

dati StableName un

nomi stabili hanno la seguente proprietà: Se sn1 :: StableName e SN2 :: StableName e sn1 == SN2 poi sn1 e SN2 sono stati creati da chiamate verso makeStableName sullo stesso oggetto.

L'inverso non è necessariamente vero: se due nomi stabili non sono uguali, gli oggetti che chiamano possono essere uguali.

reallyUnsafePtrEquality# :: a -> a -> Int #

reallyUnsafePtrEquality # restituisce se due oggetti sul mucchio GHC sono lo stesso oggetto. È davvero pericoloso perché il garbage collector sposta le cose intorno, chiusure, ecc. Per quanto ne so, può restituire falsi negativi (dice che due oggetti non sono gli stessi, ma lo sono), ma non i falsi positivi (dicendo che Sono uguali quando non lo sono).

Entrambi sembrano fare la stessa cosa di base: possono dirti se due oggetti sono sicuramente gli stessi, ma non se lo sono sicuramente.

I vantaggi che posso vedere per StableNames sono:

• Possono essere hash.
• Sono meno non portabili.
• Il loro comportamento è ben definito e supportato.
• Non hanno davvero sicuro come parte del loro nome.

I vantaggi che posso vedere per reallyUnsafePtrEquality #:

• può essere chiamato direttamente sugli oggetti in questione, invece di dover creare StablesNames separati.
• Non è necessario passare attraverso una funzione IO per creare nomi stabili.
• Non è necessario mantenere StableNames in giro, quindi l'utilizzo della memoria è inferiore.
• L'RTS non deve fare alcuna magia per far funzionare gli StableNames, quindi le prestazioni sono presumibilmente migliori.
• Ha davvero un sicuro nel nome e un # alla fine. Hardcore!

Le mie domande sono:

• Mi sono perso qualcosa?

• C'è qualche caso d'uso in cui il fatto che StableNames siano separati dagli oggetti che nominano è un vantaggio?

• È uno più preciso (meno probabile che restituisca i falsi negativi) rispetto all'altro?

• Se non hai bisogno dell'hashing, non ti preoccupare della portabilità e non ti preoccupare di usare qualcosa chiamato veramente Unsafe, c'è qualche motivo per preferire StableNames su reallyUnsafePtrEquality #?

Answer 1

Tenendo la StableName di un oggetto non impedisce che venga garbage collection, che tiene l'oggetto stesso muoversi (da usare con reallyUnsafePtrEquality# seguito) fa. Certo, puoi usare System.Mem.Weak, ma a quel punto, perché non usare solo un StableName? (In realtà, sono stati aggiunti i puntatori deboli con StableName s.)

Essere in grado di hash loro è la motivazione principale per StableName s, come la documentazione dice:

Non possiamo costruire una tabella hash utilizzando l'indirizzo dell'oggetto come chiave, perché gli oggetti vengono spostati dal garbage collector, il che significa che un re-hash sarebbe necessario dopo ogni garbage collection.

In generale, se StableName s lavorerà per i vostri scopi, mi piacerebbe li uso, anche se è necessario utilizzare unsafePerformIO; se hai davvero bisogno di reallyUnsafePtrEquality#, lo saprai. L'unico esempio mi viene in mente dove avrebbe funzionato reallyUnsafePtrEquality# e StableName s non sta accelerando un costoso Eq esempio:

x == y = 
    x `seq` y `seq` 
    case reallyUnsafePtrEquality# x y of 
     1# -> True 
     _ -> slowEq x y 

C'è probabilmente altri esempi io non ho pensato, ma non sono comuni .