Rust wskaźniki surowe (*const T i *mut T) są typami prymitywnymi, które kodują tylko adres pamięci bez semantyki własności. W przeciwieństwie do Box lub Rc, nie zawierają żadnych metadanych dotyczących rozmiaru alokacji ani zobowiązań do zwalniania. Kiedy #[derive(Clone)] jest stosowane do struktury zawierającej wskaźnik surowy, kompilator generuje bitową kopię adresu, tworząc dwie instancje struktury, które są aliasami tej samej alokacji na stercie. Ta płytka kopia nieuchronnie prowadzi do podwójnego zwolnienia pamięci, gdy obie instancje są gospodarowane, ponieważ każdy destruktor próbuje zwolnić ten sam region pamięci.
Główny problem wynika z różnicy semantycznej między systemem typów a ręcznym zarządzaniem pamięcią. Kompilator Rust nie może odróżnić wskaźnika, który posiada pamięć sterty (wymagającego głębokiej kopii), od tego, który jedynie pożycza zewnętrzne dane. W związku z tym ręczna implementacja Clone staje się obowiązkowa, aby wykonać głęboką kopię: alokując nową pamięć, kopiując zawartość z wskaźnika źródłowego do nowego bufora i opakowując nowy adres w osobnej instancji struktury. Ta operacja wymaga z natury bloków unsafe, ponieważ dereferencja surowych wskaźników w celu uzyskania dostępu do ich danych znajduje się poza gwarancjami bezpieczeństwa kontrolera pożyczek.
Rozwiązanie polega na wykorzystaniu API GlobalAlloc, aby odwzorować pierwotną alokację. Implementacja musi przechowywać Layout użyty podczas początkowej alokacji, wywołać std::alloc::alloc, aby utworzyć nowy bufor o identycznym rozmiarze i wyrównaniu, oraz użyć ptr::copy_nonoverlapping do skopiowania bajtów. Krytycznie, kod musi obsługiwać niepowodzenie alokacji za pomocą handle_alloc_error, zapewnić, że nowy wskaźnik jest unikalny dla instancji klonowanej, i zagwarantować, że oryginał i klon nie dzielą własności nad zasobem bazowym.
use std::alloc::{alloc, handle_alloc_error, Layout}; use std::ptr::{self, NonNull}; struct RawBuffer { ptr: NonNull<u8>, layout: Layout, } impl Clone for RawBuffer { fn clone(&self) -> Self { unsafe { let new_ptr = alloc(self.layout); if new_ptr.is_null() { handle_alloc_error(self.layout); } let new_ptr = NonNull::new_unchecked(new_ptr); ptr::copy_nonoverlapping( self.ptr.as_ptr(), new_ptr.as_ptr(), self.layout.size() ); RawBuffer { ptr: new_ptr, layout: self.layout } } } }
W silniku graficznym o wysokiej wydajności integrującym się z Vulkan, zaimplementowaliśmy strukturę AlignedBuffer, aby zarządzać pamięcią widoczną dla urządzeń, wymagającą 256-bajtowego wyrównania dla buforów jednostkowych. Aplikacja wymagała klonowania tych buforów podczas uruchamiania asynchronicznych zadań obliczeniowych w tle, które wymagały identycznych początkowych danych wierzchołków, nie blokując głównego wątku renderowania. Krytycznym ograniczeniem było to, że Vec<u8> nie mogło zagwarantować specyficznego wyrównania wymaganego przez sterownik graficzny, zmuszając do bezpośredniego użycia std::alloc::alloc i surowych wskaźników.
Rozwiązanie A: Wyprowadzenie Clone. To podejście stosuje #[derive(Clone)] do struktury AlignedBuffer. Zalety: Zerowy czas rozwoju i brak bloków kodu unsafe. Wady: Wykonuje płytką kopię wskaźnika surowego, powodując, że zarówno oryginał, jak i klon wskazują na identyczną pamięć; gdy oba są opróżniane, aplikacja wysypuje się z powodu podwójnego zwolnienia lub uszkadza sterownik GPU.
Rozwiązanie B: Konwersja do Vec podczas klonowania. To alokuje Vec<u8> z danymi, klonuje je za pomocą bezpiecznych metod, a następnie konwertuje z powrotem na wskaźnik surowy z odpowiednim wyrównaniem. Zalety: Całkowicie bezpieczny kod Rust z użyciem abstrakcji z biblioteki standardowej. Wady: Wymaga dwóch alokacji i dwóch kopii na klon, narusza wymóg 256-bajtowego wyrównania Vec i wprowadza nieakceptowalną latencję w ścieżce renderowania.
Rozwiązanie C: Ręczne głębokie kopiowanie z unsafe. Implementujemy Clone poprzez wyodrębnienie przechowywanego Layout, wywołanie std::alloc::alloc, używanie ptr::copy_nonoverlapping do skopiowania bajtów i skonstruowanie nowego AlignedBuffer z zabezpieczeniami ManuallyDrop, aby zapobiec wyciekom w przypadku paniki. Zalety: Utrzymuje wymagane wyrównanie, wykonuje pojedynczą alokację na klon, oraz spełnia semantykę zero-copy dla transferu danych. Wady: Wymaga kodu unsafe, musi ręcznie obsługiwać warunki braku pamięci i ryzykuje wycieki pamięci, jeśli konstruktor wywoła panikę po alokacji, ale przed zapisaniem wskaźnika.
Wybraliśmy Rozwiązanie C, ponieważ umowa dotycząca wyrównania z kierowcą Vulkan była niepodlegająca negocjacjom, a budżet wydajnościowy nie pozwalał na dodatkowy czas konwersji Vec. Ręczna implementacja starannie użyła zabezpieczeń ManuallyDrop podczas konstrukcji, aby zapewnić sprzątanie w przypadku paniki. Rezultatem była stabilna pętla renderująca na poziomie 60 klatek na sekundę bez wykrytych wycieków pamięci w teście obciążeniowym trwającym 48 godzin, pomyślnie przechodząc walidację skumulowanych pożyczek Miri.
Dlaczego kompilator zezwala na #[derive(Clone)] na strukturach zawierających wskaźniki surowe, jeśli to stwarza zagrożenie podwójnego zwolnienia?
Kompilator Rust traktuje wskaźniki surowe jako typy Copy, co oznacza, że bitowa duplikacja jest zdefiniowana jako operacja klonowania. Ponieważ Clone jest automatycznie implementowane dla każdego typu Copy za pomocą bitowej kopii, #[derive(Clone)] po prostu wywołuje tę płytką kopię dla pola wskaźnika. Kompilator nie ma wiedzy semantycznej, że wskaźnik reprezentuje posiadaną pamięć sterty; traktuje wskaźnik jako nieprzezroczysty adres całkowity. Ta różnica między "kopiowaniem wskaźnika" a "klonowaniem alokacji" jest całkowitą odpowiedzialnością dewelopera do zakodowania ręcznie poprzez niestandardową implementację.
Co uniemożliwia nam implementację traitu Copy zamiast Clone, aby uniknąć pisania kodu unsafe?
Copy i Drop to wzajemnie wykluczające się traiti w Rust. Jeśli typ implementuje Drop w celu zwolnienia pamięci sterty, na którą wskazuje wskaźnik surowy, nie może implementować Copy. Nawet gdyby to ograniczenie zostało zniesione, semantyka Copy sugeruje, że bitowa duplikacja tworzy dwie niezależne, prawidłowe kopie wartości. W przypadku wskaźników surowych posiadających pamięć sterty, nadal prowadziłoby to do podwójnych zwolnień, ponieważ obie kopie próbowałyby zwolnić ten sam adres pamięci, gdy wychodzą z zakresu. Copy jest zarezerwowane tylko dla typów bez niestandardowej logiki destrukcji, takich jak liczby całkowite czy niezmienne odniesienia.
Jak std::ptr::NonNull<T> poprawia surowe wskaźniki podczas implementacji Clone, i czy eliminuje potrzebę blocków unsafe?
NonNull<T> zapewnia niepusty, kowariantny opakowanie do *mut T, oferując lepsze bezpieczeństwo typów i gwarantując, że wskaźnik nigdy nie jest pusty. To umożliwia optymalizacje kompilatora, takie jak wypełnianie wartości niszy i eliminuje kontrole wskaźników pustych. Jednak NonNull pozostaje abstrakcją wskaźnika surowego, która nie przekazuje żadnych informacji o własności ani automatycznym zarządzaniu pamięcią. Implementacja Clone dla struktury zawierającej NonNull<T> wciąż wymaga bloków unsafe w celu dereferencji wskaźnika i wykonania głębokiej kopii. Korzyść tkwi w przejrzystości API i poprawności wariancji, ale zasadniczy wymóg ręcznego zarządzania alokacją i zapobiegania podwójnym zwolnieniom pozostaje niezmieniony.