GC dillerini WebAssembly’ye verimli biçimde taşımanın yeni bir yolu

 (v8.dev)
4 puan yazan GN⁺ 2023-11-04 | 1 yorum | WhatsApp'ta paylaş
  • Java, Kotlin, Dart, Python, C# gibi GC dillerini WebAssembly’ye taşırken WasmGC, mevcut VM’i yeniden derlemek yerine Wasm’ın kendi GC yapıları, dizileri ve tip sisteminden yararlanır
  • Geleneksel WasmMVP portlama, mevcut VM’i ve optimizasyonları yeniden kullanmayı kolaylaştırır; ancak doğrusal bellek içinde GC veya malloc/free’yi birlikte taşımanın maliyeti ile yığın referansları, döngüsel referanslar ve parçalanma kısıtlarına sahiptir
  • WasmGC’de VM nesneleri ve belleği doğrudan yönettiği için ikili dosya boyutu küçülebilir; fannkuch benchmark’ında 2.3K ile C/Rust’ın 6.1~9.6K değerlerinden daha küçüktü
  • WasmGC daha yüksek seviyeli bir ara temsil olduğundan Binaryen wasm-opt ve V8 çalışma zamanı optimizasyonları önemlidir; Java benchmark’larında ortalama 1.9×, Google Sheets Calc Engine’de yaklaşık %30 iyileşme örnekleri vardır
  • Standartlaşma ve tarayıcı desteği ilerledi; ancak bu, mevcut VM’i olduğu gibi derleme yöntemi olmadığından dil yapılarını WasmGC ilkel öğelerine indirgeyen yeni toolchain çalışması gerektirir

GC dillerini Wasm’a taşımanın iki yolu

  • GC dillerinin WebAssembly’ye portlanması genel olarak iki kola ayrılır
    • Geleneksel portlama: Mevcut dil VM’ini, 2017’de yayımlanan WebAssembly Minimum Viable Product olan WasmMVP’ye derler
    • WasmGC portlama: Dili, GC önerisinde tanımlanan Wasm’ın GC yapılarına derler
  • Geleneksel portlama, bir dili yeni bir CPU mimarisine taşırken olduğu gibi VM’in ayrıştırıcısını, kütüphane desteğini, GC’sini ve optimize edicisini paylaşan, yalnızca yeni bir backend ekleyen modele yakındır
  • WasmGC portlama, dili yeni bir mimariye değil yeni bir VM’e taşıma yöntemine daha yakındır
    • Java’yı JavaScript’e derleyen J2CL gibi, dil nesnelerini hedef VM’in nesneleri olarak temsil eder ve hedef VM’in GC’si bunları yönetir
    • WasmGC, JavaScript VM, JVM ve CLR’den daha düşük seviyeyi hedefler; ancak VM tarafından yönetilen yapılar, diziler ve tip ilişkileri sağladığı için WasmMVP’den daha yüksek seviyededir

Geleneksel WasmMVP portlamanın avantajları ve sınırları

  • Mevcut VM kodunu, dil uygulamasını ve optimizasyonları neredeyse olduğu gibi yeniden kullanabilmek, geleneksel portlamanın en büyük avantajıdır
    • Python için Pyodide ve C# için Blazor başlıca örneklerdir
    • Blazor hem AOT hem de JIT derlemeyi destekler
  • WasmMVP çıktısı doğrusal bellek, tablolar ve fonksiyonlar gibi WasmMVP’nin temel yapılarını kullanır
  • Tarayıcı, Node.js, workerd, Deno, Bun gibi zaten GC’si olan VM’ler içinde Wasm çalıştırıldığı durumlar çoktur
    • Bu ortamda GC uygulamasını Wasm ikilisine dahil etmek gereksiz boyut artışı yaratır
    • C, C++, Rust gibi doğrusal bellek kullanan diller de anlamlı ayırma yaptığında malloc/free kodunu beraberinde dahil etmek zorundadır
    • dlmalloc 6K, boyutu önceleyen emmalloc bile 1K’yı aşar
  • WasmGC’de VM belleği otomatik yönettiğinden Wasm içine GC veya malloc/free koymak gerekmez
    • Önceki WasmGC yazısındaki fannkuch benchmark’ında WasmGC 2.3K, C/Rust ise 6.1~9.6K idi

Döngüsel toplama, yığın referansları, parçalanma

  • Tarayıcıda Wasm, JavaScript ve Web API’leriyle sıkça etkileşir; ancak yalnızca WasmMVP ve reference types ile Wasm ile JS arasındaki çift yönlü bağlantılarda ayrıntılı döngüsel toplama zordur
    • JS nesnesi bağlantıları yalnızca Wasm tablosunda tutulabilir
    • JS’den Wasm’a geri dönen bağlantılar, tüm Wasm örneğine tek bir büyük nesne gibi referans verebilir
    • WasmGC, VM’in tanıdığı Wasm nesnelerini tanımladığı için Wasm ile JavaScript arasında uygun referanslar oluşturulabilir
  • GC dilleri, çağrı kapsamındaki yerel değişkenler gibi yığın üzerindeki referansları da tanımalıdır
    • Geleneksel portlamada Wasm sandboxing nedeniyle program kendi yığınını inceleyemez
    • Alternatif olarak shadow stack kullanılabilir veya GC yalnızca JavaScript event loop’un turn’leri arasında olduğu gibi yığında referans bulunmadığında çalıştırılabilir
    • Gelecekte Wasm’ın stack scanning desteği geleneksel portlamaya yardımcı olabilir
    • Mevcut durumda yığın referanslarını ek yük olmadan otomatik işleyen yöntem WasmGC’dir
  • WasmMVP doğrusal belleğindeki malloc/free, uzun süre çalışan programlarda bellek parçalanması oluşturabilir
    • Toplam kullanılmayan bellek yeterli olsa bile ardışık büyük bir blok yoksa büyük ayırma başarısız olabilir
    • Parçalanma, Wasm modülünün belleği daha sık büyütmesine neden olur ve ek yüke ve out-of-memory hatalarına yol açabilir
    • WasmGC’de VM, GC heap’ini sıkıştırmak için nesneleri taşıyabildiğinden parçalanmadan kaçınabilir

Geliştirici araçları ve dil semantiği

  • Geleneksel WasmMVP portlamada nesneler doğrusal bellekte baytlar olarak yer aldığından geliştirici araçlarının yüksek seviyeli tip bilgisini görmesi zordur
  • WasmGC’de VM GC nesnelerini yönettiği için araç entegrasyonu daha kolay hale gelir
    • Chrome DevTools’un Memory sekmesinde WasmGC programının heap snapshot’ı görülebilir
    • Bağlı liste örneğinde $Node tip adı ve sonraki nesneye referans veren $next alanı gösterilir
    • Nesne sayısı, shallow size, retained size gibi genel heap snapshot bilgileri de sunulur
    • Chrome DevTools debugger’ı da WasmGC nesneleri üzerinde çalışır
  • Geleneksel portlama mevcut VM’i yeniden derlediğinden beklenen dil semantiğini olduğu gibi elde etmek daha kolaydır
  • WasmGC portlamada dil yapılarını yeni GC tipleri olan yapılar ve dizilerle temsil etmek gerektiğinden verimlilik için semantik ödünler gerekebilir
    • WasmGC yapı alanları sabit indeks ve tipe sahip olduğundan, alanlara daha dinamik erişmek isteyen diller zorlanabilir
    • WasmGC’de şu anda interior pointer yoktur; bu tür sınırlamaların zamanla iyileşmesi beklenir
  • Hedef VM’e derleme yapılan başka örneklerde de semantik seçimler vardır

WasmGC portlama için gereken toolchain çalışması

  • WasmGC portlama, mevcut VM’i basitçe yeniden derleme yöntemi değildir
    • Ayrıştırıcı mantığı veya AOT optimizasyonu gibi çalışma zamanı GC’siyle doğrudan entegre olmayan bazı kodlar yeniden kullanılabilir
    • Genel olarak dil yapılarını WasmGC yapılarına ve dizilerine indirgeyen çok sayıda yeni kod gerekir
  • Lua VM gibi C ile yazılmış bir VM birkaç dakika içinde Wasm’a derlenebilir; ancak Lua’nın WasmGC portu, Lua yapılarını WasmGC tip sistemi kısıtları içinde nasıl temsil edeceğine karar vermeyi ve bunu uygulamayı gerektirir
  • WasmGC portlamanın büyük dezavantajı toolchain emeğidir
  • İdeal durumda WasmGC tip sistemi tüm dilleri verimli biçimde destekler ve her dil WasmGC portunu uygular
    • WasmGC tip sisteminin gelecekteki ek özellikleri ilk kısma yardımcı olabilir
    • Ortak toolchain çalışmasını paylaşmak ikinci kısmın yükünü azaltabilir

WasmGC’nin daha iyi optimize edilebilmesinin nedeni

  • WasmGC, WasmMVP’den daha yüksek seviyeli bir ara temsil olduğu için optimizasyon alanı geniştir
  • Örnek fonksiyonda iki kez GC nesnesi ayırıp alana 10 kaydettikten sonra döndüren kod, mantıksal olarak return 10’a indirgenebilir
    • WasmMVP’de ayırma malloc çağrısına dönüşür ve malloc doğrusal bellekte yan etkileri olan karmaşık bir fonksiyon olduğundan optimize edicinin ikinci ayırmanın ilk nesne alanını değiştirmediğinden emin olması zordur
    • WasmGC’de ayırma struct.new komutuyla temsil edilir ve VM işlemi olarak çıkarım yapılabildiği için referanslar ve alan değerleri izlenebilir
  • WasmGC açık fonksiyon işaretçisi ref.func, bunun üzerinden çağrı call_ref ve yapı/dizi alan tipleri de sağlar
  • WasmMVP’nin yerel hıza yakın performans verebilmesinin nedeni genellikle LLVM gibi güçlü optimizasyon derleyicilerinin Wasm üretiminden önce optimizasyonların çoğunu yapmasıdır
  • LLVM WasmGC’yi desteklemez ve birçok GC dili de LLVM kullanmadığından WasmGC için farklı bir optimizasyon modeli gerekir

Binaryen ve wasm-opt optimizasyonu

  • WasmGC, genel amaçlı optimizasyonları Wasm’a indirdikten sonra yapabildiği için farklı dil toolchain’leri ortak bir Wasm-to-Wasm optimize edicisini paylaşabilir
  • V8 ekibi, WebAssembly toolchain optimizasyon projesi Binaryen içinde WasmGC desteğine yatırım yaptı
    • Her toolchain, wasm-opt komut satırı aracıyla Binaryen’i kullanabilir
  • Binaryen hâlihazırda WasmMVP için inlining, constant propagation, dead code elimination gibi optimizasyonlara sahiptir ve bunların çoğu WasmGC’ye de uygulanır
  • WasmGC için eklenen başlıca optimizasyonlar şunlardır
  • Binaryen’in yeni GC optimizasyonları ve kullanım biçimi Binaryen docs içinde özetlenmiştir
  • J2Wasm çıktısında Java performansı ölçüldüğünde wasm-opt her benchmark’ta hızı artırdı ve ortalama 1.9× daha hızlı hale getirdi

V8’de WasmGC optimizasyonu

  • GC dilleri, C, C++, Rust gibi derleme zamanı inlining’e büyük ölçüde bağımlı dillerden farklı bir performans modeline sahiptir
    • Java, Dart gibi GC dillerinde genellikle VM çalışma zamanında inlining ve optimizasyon yapar
  • Java’da tüm çağrılar başlangıçta dolaylı çağrı olarak başlar
    • Alt sınıflar üst sınıf fonksiyonlarını override edebilir ve üst sınıf tipi referansıyla alt sınıf çağrıldığında da durum aynıdır
    • Toolchain dolaylı çağrıyı doğrudan çağrıya çevirebilirse fayda sağlar; ancak gerçek Java kodunda statik olarak doğrudan çağrı diye çıkarılması zor birçok yol vardır
  • V8, WasmGC için speculative inlining uyguladı
    • Çalışma zamanında dolaylı çağrıları gözlemler
    • Belirli bir çağrı noktası az sayıda çağrı hedefi gibi basit davranış gösterirse guard check ile birlikte inline eder
  • Google Sheets Calc Engine, elektronik tablo formüllerini hesaplayan Java kod tabanıdır ve daha önce J2CL ile JavaScript’e derleniyordu
    • V8 ekibi, Sheets ve J2CL ile iş birliği yaparak bu kodu WasmGC’ye portladı
    • Bu kodda speculative inlining, V8’in WasmGC’de uyguladığı tekil optimizasyonlar içinde en büyük etkiyi gösterdi
    • Yaklaşık %30 hız artışıyla, ölçülebilir diğer tüm optimizasyonlardan daha büyük bir iyileşme sağladı
  • V8’in diğer WasmGC optimizasyonları arasında load elimination, type-based optimizations, branch elimination, constant folding, escape analysis, common subexpression elimination vb. bulunur
  • WasmGC’nin tip bilgisi çalışma zamanı optimizasyonunda da kullanılır
    • ref.test belirli bir tip testinden geçerse aynı tipe yapılan ref.cast başarılı olmalıdır
    • Java’da instanceof sonrası downcast gibi kalıplarda cast kaldırılabilir
  • WasmMVP’de toolchain ve VM optimizasyonlarının rol ayrımı nispeten netti; ancak WasmGC’de GC dillerinin özellikleri ve WasmGC temsilinin optimize edilebilirliği nedeniyle toolchain ve VM optimizasyonları daha fazla örtüşebilir

Mevcut durum ve başlangıç noktası

  • WasmGC, W3C’de phase 4 aşamasına ulaşarak eksiksiz ve son halini almış bir standart oldu
  • Chrome 119 WasmGC desteğini içerir
  • Firefox 120’nin aynı ayın sonunda WasmGC desteğiyle yayımlanması bekleniyor
  • Flutter demo içinde WasmGC’ye derlenmiş Dart, widget’lar, layout ve animasyonlar dahil uygulama mantığını çalıştırır
  • WasmGC’yi destekleyen toolchain’ler şunlardır
  • Geliştirici araçları bölümündeki küçük örnek kaynak kodu, elle yazılmış bir “hello world” WasmGC programı örneğidir
    • $Node tip tanımı ve struct.new kullanılarak yapılan oluşturma biçimi görülebilir
  • Binaryen wiki, derleyicilerin optimizasyonu kolay WasmGC kodunu nasıl üretebileceğini ele alır

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-04
Hacker News yorumları

  • WASM, ince bel (thin waist) örneği gibi görünüyor; çöp toplayıcı da eklendiğinde yapı N×M değil, N+M oluyor. Yani N dil + M sanal makine + G çöp toplayıcı şeklinde ilerleyebilir; V8'de zaten olgun bir çöp toplayıcı var.
    WASM'den JVM'e giden bir araç olup olmadığını merak etmiştim; GitHub'da bir tane vardı. Kendim denemedim, sadece JVM de olgun ve paralel çöp toplayıcılara sahip olduğu için bakmıştım.
    WASMGC'nin bu kadar hızlı çıkacağını bilmiyordum; artık yalnızca giriş/çıkış paralelliği değil, gerçek paralellik için WASM Threads de bekleniyor.
    Asenkronluk, paralellik ve çöp toplamayı etkili biçimde çözme fırsatı doğarsa WASM daha güçlü hale gelebilir ve geliştiriciler için bir karmaşa ya da zorluk kaynağı olmayabilir. WASI'nin önemli olmasının nedeni de POSIX kadar istikrarlı bir API tanımlama fırsatı sunması diye düşünüyorum.
    1: https://www.oilshell.org/blog/2022/02/diagrams.html
    2: https://github.com/cretz/asmble

    • https://github.com/cretz/asmble iyi çalışıyor, ancak çoğunlukla eğlence için yapılmış bir projeydi ve şu anda fiilen bakımı yapılmıyor.
      WASM ara temsilini JVM bytecode'una nasıl eşlediğime dair fikirlerin ve açıklamaların, daha resmî bir uygulama geliştiren birine yardımcı olmasını umarım. Şu anda WASM GC desteği planı yok.
    • GraalVM WASM çalıştırılabilir dosyalarını çalıştırabiliyor: https://www.graalvm.org/latest/reference-manual/wasm/
    • CLR'nin izinden 22 yıl gecikmeyle gidiliyor sayılır.
      “20'den fazla programlama aracı şirketi, C++, Perl, Python, Java, COBOL, RPG, Haskell dahil yaklaşık 26 programlama dilini .NET üzerinde sunuyor.”
      Kaynak: https://news.microsoft.com/2001/10/22/massive-industry-and-d...
    • Biraz titiz davranırsak JVM, çöp toplayıcılardan daha geniş bir kavramdır[^1]. Yine de JVM'in bir çöp toplama deney sahası olduğu doğru.
      Bunun nedeni akademinin JVM konusunda özellikle cesur olması değil; JVM programlarının yaygın kullanılması ve tek bir çöp toplama tekniğini zorlayacak biçimlerde sıkça kullanılmasıydı.
      [^1]: https://www.baeldung.com/jvm-garbage-collectors. Azul JVM'in de ayrı, farklı bir çöp toplayıcısı var. Bunlar sadece benim bildiklerim; muhtemelen epey eksik de vardır.
    • Kesin konuşmak gerekirse thread'ler eşzamanlılık sağlar, ille de paralellik sağlamaz. Bu yüzden buna gerçek paralellik demek tuhaf geliyor.
      Sanırım coroutine'lerle kıyaslayarak söylemiş, ama coroutine'ler sıralıdır. Çalıştırma sırası keyfî olabilir; yine de aynı anda çalışmadıklarına güvenebilirsiniz.
      wasm thread'leri benimserse, bu bir başka üzücü “Worse is Better” durumu olacak gibi. Thread'ler, tasarladığımız eşzamanlılık modelleri arasında en kötüye yakın olanlardan. Tabii concurrent COMEFROM gibi şeyleri saymazsak.

  • Julia WASM araçları bu özelliği destekleyen ya da buna ihtiyaç duyan uygulamalar oluşturabilir. Örneğin bir ODE çözücüsünü WASM'e derleme örneği https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp... adresinde var.
    Hemen çalışması için Chrome v119 gerekiyor; çünkü çöp toplama desteğini ilk etkinleştiren sürüm bu. WASM derleyicisinin ana sayfasında https://tshort.github.io/WebAssemblyCompiler.jl/stable/ daha fazla ayrıntı var.

    • Gerçekten büyük bir ilerleme.
      Yeni Memory{T} tipi sayesinde daha fazla kodun derlenebilir hale gelmesini umuyorum.

  • “wasm yeni LLVM” gibi hissettiriyor. Benzer hisseden var mı merak ediyorum
    Ne yapmaya çalıştığını anlıyorum ve gücünü gösteren demolar da gördüm, ama çoğu hâlâ teknik olarak çok düşük seviyeli ve pratikte kullanmak için epey zahmetli hâle gelebiliyor
    Mevcut yaklaşım yerine hedef olarak seçilecek kadar daha geniş çapta benimsenmeye ne zaman hazır olacağını düşündüğünüzü merak ediyorum

    • LLVM bir sanal makine değil, ama WASM bir sanal makinedir
      Adı yüzünden yaygın bir yanlış anlama doğuyor; LLVM başlangıçta bir sanal makine olarak düşünülmüştü ama gerçekte hiç öyle olmadı, bugün de değil. Ana sayfasının ilk cümlesi de bunu açıkça belirtiyor: https://llvm.org/
      Temelde zaman içinde değişen bir ara temsili uygulayan C++ kütüphaneleri kümesi ve derleyici yazmayı kolaylaştıran bir araçtır
      Yaklaşık 10 yıl önce Google'da WASM ile benzer bir alanı hedefleyen bir proje vardı; sanırım bu yanılgıya düşmüştü. LLVM'i sanal makine sanıyorlardı. Muhtemelen PNaCl gibi bir şeydi
      Bu, LuaJIT'in Lua'yı Lua 5.1'de sabitlemesine biraz benziyor. Lua bir standart değildi, ama yeniden uygulama için belirli bir sürümü sabitlemek mümkündür. Ancak bu yaklaşımın bariz bir sorunu var: yeniden uygulayan taraf, zaman içinde birlikte sabitlediği tüm hataları bilemez
      WASM'in “uzlaşmaları” bazen kaş kaldırtsa da, şüphe götürmeyen bir şey var: WASM gerçekten bir sanal makine
      WASM GC sunumunu izledim; yapanlar uzlaşı noktalarını dürüstçe anlattı. Örneğin başlangıçta runtime cast gerekeceği ve ölçülen ek yükün makul seviyede olduğu gibi. Bu tutum aksine güven veriyor
      https://old.reddit.com/r/ProgrammingLanguages/comments/17crk...
    • Benzer bir soru sormaya gelmiştim
      Açıkçası wasm'i pek anlamıyorum. Tam olarak hangi sorunu çözmeye çalıştığımız net değil
      Amacın JavaScript ya da JavaScript'e dönüştürülmüş kod olmayan dillerle uygulama yazmak olup olmadığını merak ediyorum. Bunun tarayıcının DOM gösterim katmanıyla etkileşen kısmı da kapsayıp kapsamadığını bilmiyorum. Benim anladığım kadarıyla pratikte bunu yapamıyorsunuz gibi; eğer öyleyse hedef, Flash gibi DOM içindeki özel bir canvas'ta uygulama çalıştırmak mı, onu da merak ediyorum. Öyleyse bu nişin ne kadar büyük olduğunu bilmiyorum
      Başka bir başlıkta Cloudflare Workers'ta wasm kullanıldığından da bahsediliyordu. Muhtemelen JavaScript yorumlayıcısı üzerinden çalıştığı içindir. Ama insanlar Cloudflare Workers'ı keyfî runtime'larla yazmak istiyorsa, Cloudflare'ın başka runtime desteği eklemesi yeterli olmaz mı diye düşünüyorum. O kapasiteye sahip olmalılar
      Ya da JavaScript ekosistemiyle bağlantısı dışında, wasm'in bayt kod olarak kendine özgü harika bir yanı olup olmadığını merak ediyorum
      Bu teknolojinin neden ilginç olduğunu anlatan giriş niteliğinde bir kaynağı kaçırmış gibiyim; ama bu noktada sormak biraz utandırıcı geliyor
    • wasmtime gibi şeylere bakınca, temelde birden çok dili destekleyen çok güvenli eklentilere sahip native programlar oluşturabiliyorsunuz. Aynı şekilde tarayıcıda da temel güvenlik modelini koruyarak çalışıyor
      LLVM, ciddi miktarda kod yazmadan “varsayılan olarak kolay bir güvenlik sandbox'ı” sunmuyor. wasmer'da LLVM backend'i var gerçi, ama kişisel olarak WASM'in en büyük farkı bu
    • “WASM yeni LLVM” demektense, WASM yeni JVM demek daha doğru
    • “wasm yeni Emscripten” demeye daha yakın. Tüm tarayıcılar genelinde çok daha resmîleştirilmiş bir standart
      LLVM ile aynı yöne gidiyor, ama henüz oradan oldukça uzak

  • Ne kadar harika olursa ve ne kadar çok olasılığın önünü açarsa açsın, günümüz tarayıcılarının aşırı karmaşık olduğu ve sıfırdan kendi tarayıcını yapmanın giriş bariyerinin neredeyse fazla dik olduğu gerçeğini düşünmeden edemiyorum

    • Kendi tarayıcını yapma eğrisi fazla dik olmanın ötesinde, kelimenin tam anlamıyla imkânsız. Tüm bir işletim sistemi yapmak, tarayıcı yapmaktan çok daha kolay
    • Google ve Apple bile sıfırdan başlamadı; WebKit'i, yani KDE KHTML'yi kullandılar
    • Kendi Linux'unu yapmak da imkânsız, ama kimse bundan şikâyet etmiyor. Android'in kolayca baştan yapılamıyor olması yüzünden de onu suçlamıyorlar
      Dünyanın en başarılı ve erişilebilir hipermedya platformunun neden kolayca uygulanabilir olması gerektiğini anlamıyorum. Elbette dünyanın en başarılı çevrimiçi sistemi karmaşık ve çok özellikli olur. Bu yüzden onu kullanıyoruz, bu yüzden kazandı
    • Doğru, ama bu çalışma, tüm bir tarayıcı motoru olmadan çalıştırılabilen daha basit alternatif runtime'ların temelini oluşturuyor. V8'e bağımlı Node veya Deno'yu düşünün
    • Modern birçok şey zaten bu noktaya geldi. Kendi arabanızı yapamazsınız; bir evi de tamamen sıfırdan kendi başınıza inşa etmek pratikte imkânsızdır. İmar mevzuatı gibi çok fazla uzmanlık bilgisi gerekir

  • Bunun sonunda gerçekten geliştirilip yayımlanmış olması etkileyici. WASM’e GC ekleme planını yıllardır duyuyorduk ve gerçekten olup olmayacağından emin değildim.
    WASM’i hedefleyen diller arasında runtime’ı dahil etmek zorunda kaldığı için binary’nin büyümesi sorunu yaşayan durumlarda ne kadar yardımcı olacağını merak ediyorum. Hatırladığım kadarıyla Blazor’da yalnızca hello world bile yaklaşık 1MB gerektiriyordu; WasmGC’nin buna yardımcı olup olmayacağını bilmiyorum

    • WasmGC’nin .NET için kullanılabilir hale gelmesi zaman alabilir. Tartışmalara göre WasmGC’nin ilk sürümü, bazı .NET’e özgü senaryoları ele almak için iyi bir yol sunmuyor ve bu senaryolar “post-post-mvp” olarak sınıflandırılmış [0]
      Elbette endişe verici olan, yalnızca .NET’in ihtiyaç duyduğu bir özellikse eklemek için güçlü bir teşvik olmaması. O noktada belirli bir GC sürümünü önbelleğe alıp başka WASM assembly’lerinin yükleyebileceği türden bir include benzeri özellik, sıkıntı yaratacak olsa bile daha faydalı olabilir.
      [0] - https://github.com/WebAssembly/gc/issues/77
    • Chrome’un Wasm ekibi, çalışma sırasında veri yapıları ayıran Fannkuch benchmark’ını C, Rust ve Java’dan derledi. C ve Rust binary’leri derleyici bayraklarına bağlı olarak 6.1K ile 9.6K arasındaydı; Java sürümü ise 2.3K ile çok daha küçüktü.
      C ve Rust garbage collector içermiyor, ancak bellek yönetimi için yine de malloc/free’yi paketlemek zorundalar. Java’nın burada daha küçük olmasının nedeni, bellek yönetimi kodunu hiç paketlemek zorunda olmaması.
      https://developer.chrome.com/blog/wasmgc/
      Blazor söz konusu olduğunda bu yalnızca GC’ye yardımcı olur. Hatırladığım kadarıyla Blazor tüm dotnet runtime’ını birlikte göndermek zorunda

  • Kotlin’in yeni wasm desteği epey heyecan verici. Tarayıcıyı hedefleyebilen deneysel bir Compose Multiplatform sürümü var ve bunun WASM kullanması planlanıyor.
    Compose Multiplatform temelde Android için Google Jetpack Compose’a diğer platform desteklerinin eklenmiş hali.
    Birkaç gün önceki duruma göre iOS desteği alfa aşamasında ve gelecek yıl beta olması planlanıyor. Android ve masaüstü desteği artık stabil. Bunlar stabil hale geldiğinde, fiilen her platformda çalışan UI uygulamaları yazmak mümkün olacak.
    wasm derleyicisi Kotlin’in bir sonraki ana sürümü olan Kotlin 2.0 ile çıkacak ve buna yeni derleyici k2 dahil olacak. Gelecek yılın başları gibi mümkün görünüyor. k2 şu anda beta olarak sunuluyor ve Kotlin 1.9.x’te etkinleştirilebiliyor.
    Kotlin multiplatform ekosisteminin avantajı, zaten birçok platformda çalışan çok sayıda kütüphane bulunması. Bu yüzden wasm derleyicisi de hızla bunun bir parçası olacak ve iyi kütüphaneleri devralacak. Genel olarak build ayarlarını ilgili ekosistemi hedefleyecek şekilde değiştirmek ve eksik platforma özgü davranışları uygulamak yeterli.
    Bu alandaki bir başka ilginç nokta da farklı dillerde yazılmış kütüphaneleri kullanmak ve bağlamak. Örneğin platforma özgü birçok bölümün, zaten var olan C veya Rust kütüphanelerine dayanması olası. Birçok durumda bunlar Kotlin Native’in kullandığı kütüphanelerle aynı da olabilir.

    • Web’de Compose Multiplatform’ın nasıl çalıştığını merak ediyorum. Flutter gibi Canvas’a çizip çizmediğini merak ediyorum.
      Masaüstü, web, iOS ve Android’de aynı widget’ları kullanıp kullanmadığını merak ediyorum. Android’de native olduğunu anlıyorum. Diğer platformlarda farklı stilleri taklit edip etmediğini bilmiyorum. Asıl soru, Android dışı platformlarda Compose Multiplatform uygulamasının hissinin nasıl olduğu.
      Örneğin web’de Dart bana kişisel olarak çok takılmalı geliyor; masaüstünde Electron da öyle. Masaüstünde Dart fena değil ama uygulamalarda genelde düğmeler ve boşluklar büyük olduğundan gerçek bir native uygulamadan çok emülatörde çalışan bir Android uygulaması gibi hissettiriyor.
      Yeni bir proje için Kotlin’i dil olarak önermeye değer olup olmadığını da merak ediyorum
    • Her denediğimde Gradle karmaşası yüzünden hevesim kırıldı

  • Bu blog yazısının ve Chrome duyuru yazısının neden Go’dan bahsetmediğini açıklayabilecek biri var mı merak ediyorum.
    Go da garbage collection kullanıyor; bu değişiklikten fayda sağlayamayacağı izlenimi veriyor.

    • WasmGC interior pointer (iç işaretçi) desteği sunmadığı için Go’nun bundan fayda görmesi zor. En azından fat pointer gibi çirkin bir yöntem olmadan zor

  • Çalışma zamanının C/C++/Rust’ın kullanabileceği yerleşik bir ayırma kütüphanesi sunmasının mantıklı olup olmadığını merak ediyorum
    Program, kendi ayırma kütüphanesini paketlemek yerine o kütüphaneyi seçebilir

    • Biraz alan tasarrufu sağlayan pratik bakış açısından mantıklı olabilir. Ancak tasarım açısından, zaten yapılamayan bir şeyi mümkün kılan “asgari gerekli özellik” olmadığı için, standardın bir parçası olarak belirtilirse sebepsiz yere şişkinlik yaratır
      Wasm GC ilkel özellikleri, mümkün olan en küçük eklemeyle en büyük iyileştirmeyi sağlayacak şekilde tasarlandı. SIMD gibi başka ilkel özellikler eklendiğinde de bunun nedeni, ilgili kabiliyeti elde etmek için “yaklaşık asgari ilkel özellikler” olmalarıdır. Burada da mümkün olduğunca küçük yapı taşlarına ihtiyaç var
      Ancak malloc/free gibi bellek ayırıcı API’leri asgari özellik değildir. Bellek ayırıcılar aslında politika ve tasarım kararlarının bir toplamıdır; algoritmalar da buradan çıkar. Bu alanın temel yapı taşı “ayırıcının sahip olduğu doğrusal bellek parçası”dır ve bu da WASM’in ilk günden beri sahip olduğu doğrusal bellektir
      Bireysel çalışma zamanlarının bunu sağlaması mantıklı olabilir. Örneğin yerleşik bir wasm import’una doğrusal belleğin bir kısmını geçirip bunu çalışma zamanı uygulamalı bir ayırıcıya işlettirmek gibi. Ancak standartlaştırılma olasılığının çok düşük olduğunu düşünüyorum. Ayrıca GC’siz Wasm dilleri için araçların çoğu, mevcut kod tabanlarını ve onların ayırıcılarını port etme yaklaşımına göre şekillenmiş durumda. Sonuçta tek seferlik bir uygulama için bakım yapılacak kod miktarı artar; harcanan emeğe değmeyebilir
    • Bu yaklaşımın zorluğu, ayırma kütüphanesinin davranışının standartlaştırılmış ve deterministik olması gerektiğidir
      Deterministik olmazsa program davranışındaki farklar önemli hale gelebilir. Örneğin bir tarayıcı belleği daha iyi yeniden kullanan “akıllı” bir ayırıcı koyarsa, başka bir tarayıcıda doğrusal bellek parçalanması nedeniyle bellek yetersizliğine düşen bir program o tarayıcıda başarılı olabilir. Tarayıcılar tarihsel olarak bu tür farklardan kaçınmak için davranışları standartlaştırmaya çok çaba gösterdi
      malloc/free uygulamasının davranışını standartlaştırmak da çeşitli nedenlerle zor. Birincisi, free list’in nasıl ele alındığı, hangi chunk boyutlarının kullanıldığı gibi konularda büyük bir karmaşıklık var. Spesifikasyona koymak için fazla. İkincisi, belirli bir davranış standartlaştırılırsa onu iyileştirmek mümkün olmaz; oysa daha iyi malloc/free fikirleri bugün hâlâ ortaya çıkıyor
      Bu nedenlerle bunun wasm spesifikasyonuna girme olasılığı konusunda şüpheliyim
      Buna karşılık GC bu sorunlardan kaçınır. Pointer değerleri gözlemlenebilir olmadığı için spesifikasyona yazılacak bir şey yoktur
    • Bu akıllıca bir yön gibi geliyor. alloc ve ilgili fonksiyonları çalışma zamanı fonksiyonları olarak ekleyip geleneksel kodun bunları çağırmasını sağlamak ve herhangi bir GC’nin bunun üzerine kurulabilmesine izin vermek yeterli

  • Bu yönde biraz şüpheliyim. WebAssembly’nin karmaşıklığını ciddi biçimde artırıyor
    Çöp toplayıcılar sızdıran soyutlamalardır. Bazıları iç işaretçileri destekler, bazıları desteklemez. Bazıları belleği paylaşan paralel işleri destekler, bazıları desteklemez. Bazıları sıkıştırma gerektirdiği için C FFI’yi daha zorlaştırır, bazıları gerektirmez. Bazılarının yeşil süreçler/iş parçacıkları ve genişletilebilir yığınlar için kullanılan mekanizmalarla derinlemesine entegre olması gerekir, bazılarının gerekmez
    Erlang, JavaScript, Python, Go gibi dillere bakınca, dil düzeyindeki tercihlerin bir ölçüde çöp toplayıcıya yansıdığını görüyoruz
    Birden çok dili destekleyen evrensel/genel sanal makine fikri JVM, CLR, Parrot vb. ile defalarca denendi ve başarısı sınırlı kaldı. Bu sefer neyin farklı olduğunu merak ediyorum

    • Bu sefer farklı olan, WASM’ın Sun JVM ve Microsoft CLR’ın denediği yöntemin zaman sırasını tersine çevirmiş olması
      JVM/CLR önce sanal makineyi, ara dil komutları spesifikasyonunu ve çalışma zamanını oluşturdu; ardından bunu mümkün olduğunca yaygın dağıtıp evrensel istemci benimsemesi bekledi. Yani “ara dil VM”inin o kadar çekici olacağı ve tüm sektöre yayılacağı umuluyordu. Bu beklenti yalnızca kısmen doğru çıktı. JVM/CLR masaüstü ve sunuculara yayıldı, ancak web tarayıcılarında Java Applet ve Microsoft Silverlight başarısız oldu; mobil platformlarda da yaygın biçimde benimsenmedi
      WASM ise ters sırada ilerliyor. Sektör genelinde zaten dağıtılmış ve benimsenmiş olan şeyden, yani JavaScript’ten geriye doğru yola çıkarak “sanal makine, ara dil komutları spesifikasyonu ve çalışma zamanı” oluşturuyor
      Bu açıdan, sözde “oyuncak dil” JavaScript, önce tüm istemcilere yaygın biçimde dağıtılmak için 20 yıllık bir Truva atıydı. Şimdi sektör adeta “Sunucu+masaüstü+tarayıcı+mobil için evrensel bir çalışma zamanı olan JavaScript’in zaten var olduğunu fark eden oldu mu? Bir ara dil çalışma zamanı yapıp bunu hızlandıralım” diyor
      Bazı teknik sorunlar da vardı. Sun JVM’de ham işaretçiler yoktu; bu yüzden C/C++ gibi işaretçi tabanlı diller için yüksek performanslı bir hedef olması zordu. MS CLR ise macOS’te kullanılamıyordu. Silverlight’ın minimal CLR’ı istisnaydı. Ancak bu teknik sınırlamalardan çok, JavaScript’in zararsız bir Truva atı gibi dağıtıldığı zaman sırası daha güçlü bir açıklama sunuyor
    • JVM ve CLR’ın birden çok dili desteklemek üzere tasarlandığını söylemek zor. JVM’in sahip dili Java’dır ve JVM’de çalışmak isteyen diğer diller Java tip sisteminden uzaklaştıkça daha büyük bir yük taşır
      Wasm, yukarıdaki bayt kodu biçimlerinin çoğundan daha düşük seviyelidir. Statik tipli struct ve diziler ekleyen Wasm GC ile tipli fonksiyonları getiren function-references önerisi dahil edilse bile bu böyledir. Wasm GC’de etiketli işaretçi i31ref için açık destek de vardır
      Bu noktalar nedeniyle Wasm GC, daha düşük seviyeli olduğu için yukarıda sayılan girişimlerden daha geneldir
    • WASM-GC desteği bilinçli olarak mümkün olduğunca basit tutuluyor. https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP... adresine bakılabilir
      Birden çok dili eşit ve sorunsuz biçimde destekleyen “evrensel” ya da “genel” bir VM yapmak WASM-GC’nin açık bir hedefi değil. Her uygulamanın WASM’in sunduğu temel desteğin üzerine kendi hack’lerine ve özel semantiğine ihtiyaç duyabileceği bekleniyor; FFI ve diller arası birlikte çalışabilirlik tamamen ayrı bir sorun olarak görüldüğü için bu kabul ediliyor
    • Farkın bu projenin önemi olduğunu düşünüyorum
      JavaScript çöp toplaması kalıcı olacak ve bahsedilen örnekler arasında en inatçı biçimde yerleşmiş olanı gibi görünüyor
      Birçok durumda daha düşük nitelikte olsa bile, diğer diller ve uygulamalar/kütüphaneler ona uyum sağlamak zorunda
    • wasm’in yaptığı şey önceki girişimlerden farklı. GC özelliği, diğer dillerle birlikte çalışabilirlik ya da dil çalışma zamanı uygulamaları arasında geliştirme kaynaklarını paylaşmak için sunulmuyor
      wasm, yönetilen bellek çalışma zamanı dillerinin sınırlı bellek modelinin kısıtları yüzünden sıkıntı yaşamadan wasm ortamını hedefleyebilmesi için GC özelliği sunuyor; ikincil olarak da paket boyutunu azaltmayı amaçlıyor
      wasm, konuk dilin özelliklerine daha iyi uyum sağlayacak şekilde daha ayarlanabilir GC parametreleri destekleyebilir. Ayrıca karşılaştırılan genel amaçlı dil çalışma zamanlarının aksine, dil uygulayıcılarının tamamen özelleştirilmiş bir çalışma zamanı yapma seçeneği zaten yok

  • WASM GC’nin uygulanabilirliğiyle ilgili mevcut çeşitli endişeler burada ele alınıyor. İngilizce Google çevirisi:
    https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl...
    Orijinal metin:
    https://habr.com/ru/articles/757182/
    Java ve JVM kodunu tarayıcıda verimli biçimde çalıştırma işiyle 10 yıldır uğraşan TeaVM’in yazarının yazısı. https://teavm.org/
    TeaVM’in mevcut Java-to-JavaScript dönüşümü, tarayıcının JS GC’sini kullanmasına rağmen iyi performans veriyor. WASM GC daha olgunlaşıp bundan daha hızlı hâle gelecek mi, görmek ilginç olacak

    • İlginç bir yazı
      Yazıda ele alınan sorunlarla ilgili not düşmek gerekirse, manuel gölge yığınına ihtiyaç duyulması sorunu WasmGC’de çözülüyor. Bağlantıda söylendiği gibi JS’te çalışan yöntemle aynı
      try-catch eksikliği, tarayıcılara zaten sunulmuş olan Wasm istisna işleme önerisiyle çözülüyor: https://github.com/WebAssembly/exception-handling/blob/main/...
      null denetimi de büyük ölçüde WasmGC ile çözülüyor. Spesifikasyon null olamayan yerel tipleri tanımlıyor ve VM, yazıda bahsedilen teknik gibi sinyalleri kullanarak bunu optimize edebilir. Örneğin Wizard bunu yapıyor
      Sınıf başlatma, yazıda söylendiği gibi zor bir sorun. J2Wasm ve Binaryen bunu araç zinciri düzeyinde statik analizle optimize etmeye çalışıyor. Yakın zamanda yazdığım PR bu yönde ilerleme sağladı: https://github.com/WebAssembly/binaryen/pull/6061
      Yazıda bahsedilen vtable ek yükü sorun olabilir. Ancak henüz iyi ölçümler bilinmiyor. Metot dispatch’i için post-MVP çözüm fikirleri var, ama henüz somut bir şey yok
      null denetimi ve trap konusunda, trap yerine istisna fırlatan GC komut varyantları üzerine tartışmalar olmuştu. Ancak ölçümlerde şu an büyük bir sorun olarak görünmediği için önceliği düşük
      Yazarın stack walking, sinyaller ve bellek denetiminin önemli alanlar olduğunu söylemesi doğru
      Genel olarak, WasmGC ve istisna işleme sayesinde, J2Wasm’in bugün ürettiği Java oldukça iyi bir konumda. Genellikle Java’yı JavaScript’e derleyen J2CL’den daha hızlı. Yine de kesinlikle iyileştirme alanı var