Yabancı Fonksiyon ve Bellek (FFM) API'si, bellek dışı belleğe güvenli erişim sağlamak için MemorySegment'i tanıtır. Her segment, yaşam döngüsünü tanımlayan bir MemorySession (veya daha yeni versiyonlarda Arena) ile ilişkilendirilmiştir. Bir arena kapandığında, ScopedMemoryAccess katmanı tüm ilişkili segmentleri "hayatta değil" olarak işaretler.
Sonraki erişim girişimleri, hemen IllegalStateException fırlatan bir ScopedMemoryAccess.Scope kontrolü tetikler. Bir yerel işlem devam ederken bir segmentin çöp toplayıcı tarafından geri alınmasını önlemek için JVM, istemsiz olarak reachabilityFence semantiğini kullanır. Derleyici, segment nesnesinin yerel çağrı tamamlanana kadar güçlü bir şekilde erişilebilir olmasını sağlamak için kritik sınırlar boyunca devamlılık bariyerleri ekler.
Bu koordinasyon, close() yoluyla açık ve belirleyici bir temizlik sağlarken, çöp toplayıcının segmenti zamanından önce sonlandırması durumunda ortaya çıkacak kullanımdan sonra serbest bırakma hatalarını önler. Bu tasarım, her erişim için manuel senkronizasyon gerektirmeden bellek güvenliğinin korunmasını sağlar. Bu mimari seçim, manuel bellek yönetimi ile Java'nın otomatik çöp toplama paradigması arasındaki boşluğu doldurur.
MemorySegment'i kullanarak bellek dışı tamponlara bağlanan bir yüksek frekanslı ticaret uygulamasını düşünelim. Sorun, arka planda bakım yapan bir iş parçacığının periyodik olarak tamponu yenileyerek eski Arena'yı kapatıp yenisini tahsis etmeye çalıştığında, birden fazla iş parçacığının fiyat güncellemelerini okumaya çalışması sonucu ortaya çıkar. Doğru zamansal güvenlik olmadan, bir okuma iş parçacığı, temel bellek işletim sistemine geri döndürülen bir segmenti erişmeye çalışabilir ve bu da JVM çökmesine veya sessiz veri bozulmasına neden olabilir.
Düşünülen bir çözüm, her okuma işleminde sayacı artırıp tamamlandıktan sonra azaltan açık referans sayımı ile AtomicInteger kullanmaktı. Artıları, basit mantık ve sızıntıların hemen tespitidir. Ancak eksileri, yüksek yük altında atomik değişken üzerinde önemli bir çekişme ve çöp toplayıcı ile entegrasyon eksikliğidir; unutulan bir azaltma hala bellek sızıntısına yol açar ve yerel kodun ham bir işaretçi tuttuğu süre zarfında arenanın kapanmasını engellemez.
Başka bir yaklaşım, her erişimi saran try-with-resources blokları kullanarak arenanın işlem sırasında açık kalmasını sağlamaktı. Artıları, belirleyici alan ve temiz bir sözdizimidir. Ancak eksileri, kısa ömürlü işlemler için arenaların aşırı kapanması ve yenilenmesidir, bu da saniyede binlerce segment tahsis ederken çok pahalıdır. Ayrıca, bu desen, Java alanını aşabilecek yerel koddan gelen asenkron geri çağırmalar için koruma sağlayamaz.
Seçilen çözüm, doğru reachabilityFence yerleşimi ve kapsamlı erişim kontrolleri ile Arena.ofShared() kullandı. Arenanın kapanmasını belirli bir bakım iş parçacığına sıkıştırarak ve tüm okuma işlemlerinin, dereference etmeden önce segmentin canlılığını doğrulamasını sağlayarak, sistem yarış koşullarını ortadan kaldırdı. ScopedMemoryAccess mekanizması, hızlı yolda sıfır maliyetli kontroller sağlarken, JVM'nin erişilebilirlik garantileri GC müdahalesini önledi. Sonuç, yerel çöküşler ya da bellek sızıntıları olmadan saniyede milyonlarca mesaj işleyen stabil bir sistem oldu.
Neden MemorySegment, segment açıkça sınırlı olmadığında bile WrongThreadException fırlatır ve Arena türü, iplik sınırlama semantiğini nasıl belirler?
Birçok aday tüm segmentlerin varsayılan olarak iplik güvenli olduğunu varsayıyor. Gerçekten de, Arena.ofConfined() yalnızca orijinal iş parçacığı tarafından erişilebilen segmentler oluşturur ve bu, ScopedMemoryAccess'de iş parçacığı kimliği kontrolleriyle uygulanır. Arena.ofShared(), iş parçacıkları arası erişime izin verir ama dış senkronizasyon gerektirir. Hata, bir sınırlı segmentin adresinin bir lambda veya geri çağırma aracılığıyla başka bir iş parçacığına aktarılması durumunda ortaya çıkar.
Çöp toplama kullanılmadığı sürece yerel çağrılar sırasında bellek dışı kaynakların geçerli kalmasını sağlarken reachabilityFence mekanizması, PhantomReference'den nasıl ayrılır?
Adaylar genellikle bu iki mekanizmayı karıştırır. PhantomReference, bir nesne erişilmez hale geldikten sonra temizleme yapılmasına izin verir, bu da aktif bir işlem sırasında kullanılmaktan sonra serbest bırakmayı önlemek için çok geçtir. reachabilityFence, nesnenin engel çalışmadan önce güçlü bir şekilde erişilebilir kalmasını sağlayan derleyici tarafından eklenmiş bir bariyer görevi görür. FFM'de JVM, MemorySegment erişimcilerinin etrafında bu engelleri otomatik olarak yerleştirir; bu, kullanıcı kodunda manuel yerleştirme gerektirmeden segmentin yerel bellek erişimi süresince canlı kalmasını sağlar.
Bir MemorySegment'i doğrudan kapatmak ile ebeveyn Arena'yı kapatmak arasındaki fark nedir ve neden bir arenayı kapatmak tüm türetilmiş segmentleri aynı anda geçersiz kılar?
Yaygın bir yanlış anlama, segmentlerin bağımsız kaynaklar olduğudur. Aslında, slice() veya reinterpret() ile türetilen segmentler, ana arenayla aynı ScopedMemoryAccess.Scope'u paylaşır. Arena.close() çağrıldığında, tüm alanı geçersiz hale getirir; bu da tüm türetilmiş segmentlere sıçrar. Bireysel bir segmenti kapatmak yalnızca o belirli görünümü geçersiz kılar, ancak temel bellek arena kapatılana kadar tahsis edilmeye devam eder.