Çöp toplama, yerel olarak derlenen dillerde nasıl çalışır?


79

Birkaç cevaba göz attıktan sonra Yığın Taşması, bazı doğal olarak derlenmiş dillerin çöp toplama olduğu açıktır . Ama bunun tam olarak nasıl işe yarayacağı bana açık değil.

Çöp koleksiyonunun yorumlanmış bir dille nasıl çalışabileceğini anlıyorum. Çöp toplayıcı, tercüman ile birlikte çalışır ve kullanılmayan ve erişilemeyen nesneleri programın hafızasından siler. İkisi birlikte koşuyorlar.

Bu derlenmiş dillerle nasıl çalışır? Anladığım kadarıyla, derleyici kaynak kodu hedef koda ( özellikle de yerel makine koduna) derledikten sonra yapılır. İşi bitti. Öyleyse, derlenen program nasıl çöp toplanabilir?

Program "çöp" nesnelerini silmek için çalıştırılırken derleyici bir şekilde CPU ile çalışıyor mu? Veya derleyici, derlenmiş programın çalıştırılabilirinde bazı asgari çöp toplayıcı içeriyor mu?

Yığın Taşması ile ilgili bu cevabın bu alıntıdan dolayı, ikinci ifademin eskisinden daha fazla geçerliliğe sahip olduğuna inanıyorum :

Böyle bir programlama dili Eyfel'dir. Çoğu Eiffel derleyicisi taşınabilirlik nedeniyle C kodu üretir. Bu C kodu, standart bir C derleyicisi tarafından makine kodu üretmek için kullanılır. Eiffel uygulamaları bu derlenmiş kod için GC (hatta bazen doğru GC) sağlar ve VM'ye gerek yoktur. Özellikle, VisualEiffel derleyicisi doğrudan tam GC desteği ile yerel x86 makine kodu üretti .

Son ifade, derleyicinin, program çalışırken bir çöp toplayıcı görevi gören son çalıştırılabilir programda bir program içerdiğini gösteriyor gibi görünüyor.

D dilinin web sitesinde , doğal olarak derlenmiş ve isteğe bağlı bir çöp toplayıcısına sahip olan çöp toplama sayfasındaki sayfa, bazı arka plan programlarının, çöp toplama işlemini gerçekleştirmek için orijinal çalıştırılabilir programla birlikte çalıştığını ima etmektedir.

D, çöp toplama desteği olan bir sistem programlama dilidir. Genellikle, belleği açıkça boşaltmak gerekmez. Sadece gereken şekilde tahsis edin ve çöp toplayıcı, kullanılmayan tüm bellekleri düzenli olarak kullanılabilir bellek havuzuna geri gönderir.

Yöntem yukarıda bahsedilen takdirde edilir kullanıldığı, tam olarak nasıl çalışacak? Derleyici bazı çöp toplama programının bir kopyasını depolar ve oluşturduğu her çalıştırılabilir dosyaya yapıştırır mı?

Yoksa düşüncelerime karşı kusurlu muyum? Öyleyse, derlenmiş diller için çöp toplama işlemini uygulamak için hangi yöntemler kullanılır ve bunlar tam olarak nasıl çalışır?


1
Bu sorunun yakın seçmeninin tam olarak neyin yanlış olduğunu söyleyebileceğini ve düzeltebileceğimi söyleyebilirseniz memnun olurum.
Christian Dean,

6
GC'nin temelde belirli bir programlama dili uygulaması için gereken bir kütüphanenin bir parçası olduğunu kabul ederseniz, sorunuzun özü, GC ile kendi başınıza ve statik ve dinamik bağlantı ile ilgili hiçbir şey yapmaz .
Theodoros Chatzigiannakis

7
Çöp toplayıcının, dilin eşdeğerini uygulayan çalışma zamanı kitaplığının bir parçası olduğunu düşünebilirsiniz malloc().
Barmar

9
Bir çöp toplayıcısının çalışması , derleme modeline değil, tahsisatçının özelliklerine bağlıdır . Dağıtıcı tahsis edilen her nesneyi bilir; onları tahsis etti. Şimdi tek ihtiyacınız olan, hangi nesnelerin hala hayatta olduğunu bilmenin bir yoludur ve toplayıcı, onlar dışındaki tüm nesneleri serbest bırakabilir. Bu açıklamadaki hiçbir şey derleme modeliyle ilgisi yoktur.
Eric Lippert

1
GC, yorumlayıcının bir özelliği değil, dinamik belleğin bir özelliğidir.
Dmitry Grigoryev

Yanıtlar:


52

Derlenmiş bir dilde çöp toplama, yorumlanmış bir dille aynı şekilde çalışır. Go gibi diller, kodları genellikle önceden makine koduyla derlenmiş olsalar bile, çöp toplayıcıları kullanırlar.

(İzleme) çöp toplama genellikle şu anda çalışmakta olan tüm iş parçacıklarının çağrı yığınlarını yürüterek başlar. Bu yığınlardaki nesneler daima canlıdır. Bundan sonra, çöp toplayıcı, canlı nesne grafiğinin tamamı keşfedilene kadar canlı nesnelerin işaret ettiği tüm nesneleri dolaşır.

Bunu yapmanın, C gibi dillerin sağlamadığı fazladan bilgi gerektirdiği açıktır. Özellikle, tüm işaretçilerin ofsetlerini (ve muhtemelen onların veri türlerini) içeren her bir işlevin yığın çerçevesinin bir haritasını ve aynı bilgiyi içeren tüm nesne düzenlerinin haritalarını gerektirir.

Bununla birlikte, güçlü tür garantileri olan dillerin (örneğin, farklı veri türlerine işaretçi göstergeleri izin verilmezse) gerçekten de bu haritaları derleme zamanında hesaplayabildiğini görmek kolaydır. Onlar sadece talimat adresleri ve yığın çerçeve haritaları arasında bir ilişkiyi ve ikilinin içindeki veri türleri ve nesne düzen haritaları arasında bir ilişkiyi depolarlar. Bu bilgi daha sonra onların nesne grafiği geçişini yapmalarına izin verir.

Çöp toplayıcının kendisi, C standart kütüphaneye benzer şekilde programa bağlı bir kütüphaneden başka bir şey değildir. Örneğin, bu kütüphane malloc()hafıza basıncı yüksekse toplama algoritmasını çalıştıran fonksiyona benzer bir işlev sağlayabilir .


9
Yardımcı program kitaplıkları ve JIT derlemesi arasında "derlenmiş olanı yerel" ile "çalışma zamanı ortamında çalışır" arasındaki satırlar giderek daha bulanık hale geliyor.
corsiKa

6
Sadece GC desteğiyle gelmeyen diller hakkında biraz bilgi eklemek için: C ve diğer dillerin arama yığınları hakkında bilgi sağlamadığı, ancak platforma özgü bir kodla (genellikle biraz dahil) montaj kodu) hala "koruyucu çöp toplama" uygulamak mümkündür. Boehm GC gerçek hayat programlarında kullanılan bu bir örnektir.
Matti Virkkunen

2
@ CorsiKa Veya daha doğrusu, çizgi çok daha belirgindir. Şimdi bunların birbiriyle ilişkili olmayan farklı kavramlar olduğunu ve birbirlerinin zıtlıkları olduğunu görüyoruz.
Kroltan

4
Derlenmiş veya yorumlanmış çalışma sürelerinde bilmeniz gereken ek bir karmaşıklık, cevabınızdaki şu cümleyle ilgilidir: "(Toplama) çöp toplama işlemi genellikle çalışan tüm iş parçacıklarının çağrı yığınlarını yürüterek başlar." GC'yi derlenmiş bir ortamda uygulama deneyimim, yığınları izlemenin yeterli olmamasıdır. Başlama noktası, genellikle iş parçacıklarını kayıt defterlerinden izleyebilecek kadar uzun süre askıya alır , çünkü bunlar henüz yığında depolanmamış kayıtlarda referansları olabilir. Bir tercüman için, bu genellikle değil ...
Jules

... bir problem, çünkü çevre, GC'nin, tercümanın tüm verilerin yorumlanmış yığınlarda güvenle saklandığını bildiği "güvenli noktalarda" yer almasını sağlayabilir.
Jules

123

Derleyici bir çöp toplama programının bir kopyasını saklar ve oluşturduğu her çalıştırılabilir dosyaya yapıştırır mı?

Kulağa tuhaf ve garip geliyor ama evet. Derleyici, yalnızca çöp toplama kodundan çok daha fazlasını içeren bir yardımcı program kitaplığına sahiptir ve bu kitaplığa yapılan çağrılar, oluşturduğu her çalıştırılabilir dosyaya eklenecektir. Buna çalışma zamanı kitaplığı denir ve genellikle kaç farklı işe hizmet ettiğini görünce şaşıracaksınız.


51
@ChristianDean C bile bir çalışma zamanı kütüphanesine sahip olduğunu unutmayın. O GC olmasa da, yine de bu çalışma zamanı kitaplığı aracılığıyla bellek yönetimini gerçekleştirir: malloc()ve free()dile inşa edilmez, işletim sisteminin bir parçası değildir, ancak bu kütüphanede fonksiyonlardır. C ++ bazen dilin akılda tutulmasıyla tasarlanmamış olsa bile, bir çöp toplama kütüphanesiyle derlenir.
amon,

18
C ++ dynamic_cast, GC eklememiş olsanız bile, make ve istisnalar gibi işleri yapan bir çalışma zamanı kütüphanesi içerir .
Sebastian Redl

23
Çalışma zamanı kitaplığının her çalıştırılabilir dosyaya kopyalanması zorunlu değildir (statik bağlantı olarak adlandırılır), yalnızca referans gösterilebilir (kitaplığı içeren ikili dosyaya giden bir yol) ve yürütme sırasında erişilir: bu dinamik bağlantıdır.
mouviciel

16
Derleyici, programınızın giriş noktasına başka hiçbir şey olmadan doğrudan atlamak zorunda değildir. Her derleyicinin çağrılmadan önce bir sürü platforma özel başlatma kodu main()eklediğini ve bu kodda bir GC iş parçacığını ateşlemenin tamamen yasal olduğunu tahmin etmek konusunda bilinçli bir tahmin yapıyorum . (GC'nin bellek ayırma çağrıları içinde gerçekleştirilmediğini varsayarsak.) Çalışma zamanında, GC yalnızca bir nesnenin hangi parçalarının işaretçiler veya nesne referansları olduğunu bilmesi gerekir ve derleyicinin bir nesne referansını bir işaretçiye çevirmek için kodu vermesi gerekir. GC nesnelerin yerini değiştirirse.
millimoose

15
@millimoose: Evet. Örneğin, GCC’de, bu kod parçası crt0.o(“ C R un T ee, çok temel” anlamına gelir), her programla (veya en azından bağımsız olmayan her programla ) bağlantılıdır.
Jörg W Mittag

58

Veya derleyici, derlenen programın kodunda bazı asgari çöp toplayıcı içeriyor mu?

“Derleyici, programı çöp toplama işlemi yapan bir kütüphane ile bağlar” demenin garip bir yolu. Ama evet, olan budur.

Bu özel bir şey değil: derleyiciler genellikle bağlantı ton onlar derlemek programlarına kütüphanelerinin; Aksi halde derlenmiş programlar birçok şeyi sıfırdan yeniden uygulamadan pek bir şey yapamazlardı: Ekrana bir metin yazmak bile / bir dosya /… bir kütüphane gerektirir.

Fakat belki GC, kullanıcının aradığı açık API'ler sağlayan bu diğer kütüphanelerden farklıdır?

Hayır: çoğu dilde, çalışma zamanı kitaplıkları, GC'nin ötesinde, genel kullanıma açık API olmadan birçok sahne arkası işi yapar. Bu üç örneği ele alalım:

  1. İstisna yayılımı ve istifleme çözme / yıkıcı çağrısı.
  2. Dinamik bellek ayırma (çöp toplama olmasa bile, genellikle C de olduğu gibi sadece bir işlev çağırmaz).
  3. Dinamik tip bilgisinin izlenmesi (yayın vb. İçin).

Yani bir çöp toplama kütüphanesi hiç özel değildir ve bir priori'nin bir programın önceden derlenmiş olup olmadığı ile ilgisi yoktur.


Bu, 3 saat önce yayınlanan en çok cevaplanan ve yapılan puanlar üzerinde önemli bir şey sunmuyor gibi görünüyor
gnat

11
@gnat Yararlı / gerekli olduğunu düşündüm, çünkü en iyi cevap yeterince güçlü değil: benzer gerçeklerden bahsediyor, ancak çöp toplama işlemini seçmenin tamamen yapay bir ayrım olduğunu belirtmiyor. Temel olarak, OP'nin varsayımı hatalı ve en üstteki cevap bundan söz etmiyor. Maden (“kusurlu” teriminden oldukça kaba bir ifadeden kaçınırken).
Konrad Rudolph

O kadar özel bir şey değil, ama biraz özel olduğunu söyleyebilirim , çünkü genellikle insanlar kütüphaneleri açıkça kodlarından çağırdıkları bir şey olarak görür; temel bir dil semantiği uygulaması yerine. Bence OP'nin buradaki yanlış varsayımı, bir derleyicinin, yazarın belirlemediği kütüphane çağrıları ile çalmak yerine, kodu daha az ya da çok basit bir şekilde çevirmek olduğunu düşünüyorum.
millimoose

7
@millimoose Runtime kütüphaneleri, açıkça kullanıcı etkileşimi olmadan sahnelerin arkasında çok çeşitli şekillerde çalışır. İstisna yayılımını göz önünde bulundurun ve istirahat / yıkıcı çağrısını istifleyin. Dinamik bellek ayırmayı düşünün (genellikle çöp toplama olmasa bile, C'deki gibi sadece bir işlev çağırmaz). Dinamik tip bilgisini ele almayı düşünün (yayınlar vb. İçin). Yani GC gerçekten eşsiz değil.
Konrad Rudolph

3
Evet, garip bir şekilde ifade ettiğimi itiraf ediyorum. Çünkü basitçe derleyiciye böyle bir şey yapma konusunda şüpheliydim. Ama şimdi düşünüyorum da, bu çok daha mantıklı. Derleyici, standart kütüphanenin herhangi bir bölümü gibi bir çöp toplayıcısını bağlayabilir. Kafamın bir kargaşasının çöp toplayıcıyı tercüman uygulamasının bir parçası olarak düşünmesinden kaynaklandığına inanıyorum, kendi başına ayrı bir program değil.
Christian Dean,

23

Bu derlenmiş dillerle nasıl çalışır?

İfadelerin yanlış. Bir programlama dili , bazı teknik raporlarda yazılı bir özelliktir (iyi bir örnek için bkz. R5RS ). Aslında, belirli bir dil uygulamasından bahsediyorsunuz (ki bu bir yazılımdır).

(bazı programlama dilleri kötü özelliklere sahiptir, hatta eksik olanları veya bazı örnek uygulamalara uygun olduğu gibi; yine de bir programlama dili bir davranışı tanımlar - örneğin bir sözdizimi ve anlambilimi vardır - bir yazılım ürünü değildir , ancak uygulanan bazı yazılım ürünü ile; birçok programlama dilleri var birkaç uygulamaları; özellikle de "derlenmiş" bir sıfat için geçerli olan uygulamaları - bazı programlama dilleri derleyici tarafından daha tercümanlar tarafından uygulanan daha kolay olsa bile).

Anladığım kadarıyla, derleyici kaynak kodu hedef koda (özellikle de yerel makine koduna) derledikten sonra yapılır. İşi bitti.

Tercümanların ve derleyicilerin gevşek bir anlamı olduğuna dikkat edin ve bazı dil uygulamalarının her ikisi de olarak kabul edilebilir. Başka bir deyişle, arasında bir süreklilik var. Son Oku Ejderha Kitabı ve düşünmek bayt , JIT derleme , dinamik içinde derlendiği C kodu yayan bazı ardından "eklentisi" dlopen (3) aynı işlemle -ed (ve mevcut makinelerde, bu uyumlu olacak kadar hızlıdır etkileşimli bir REPL , bunu görün )


GC el kitabını okumanızı şiddetle tavsiye ederim . Cevaplamak için bütün bir kitaba ihtiyaç var . Ondan önce, Çöp Toplama Wikipajını okuyun (aşağıdakileri okumadan önce okuduğunuzu varsayıyorum).

Çalıştırma sistemi derlenmiş dil uygulama çöp toplayıcısı ihtiva etmektedir ve derleyici kod üreten bir uyum söz konusu çalışma zamanı sistemi ile ilgilidir. Özellikle, tahsisat ilkeleri (çalışma kodunu çağıracak (veya çıkarabilecek) makine koduna derlenir).

Öyleyse, derlenen program nasıl çöp toplanabilir?

Sadece çalışma zamanı sistemini kullanan (ve "dost" ve "uyumlu" olan) makine kodunu yayarak.

Çok sayıda çöp toplama kütüphanesini, özellikle Boehm GC'yi , Ravenbrook'un MPS'sini ve hatta (kullanılmayan) Qish'imi bulabileceğinizi fark edin . Ve basit bir GC'yi kodlamak çok zor değildir (ancak, hata ayıklamak daha zordur ve rekabetçi bir GC'yi kodlamak zordur ).

Bazı durumlarda, derleyici muhafazakar bir GC ( Boehm GC gibi ) kullanır. O zaman kodlayacak bir şey yok. Muhafazakar GC (derleyici tahsis rutinini çağırdığında veya GC rutininin tamamını çağırdığında ) bazen tüm çağrı yığınını tarar ve çağrı yığınından ulaşılabilen herhangi bir hafıza bölgesinin (dolaylı olarak) çağrı yığınından canlı olduğunu varsayar. Buna muhafazakar GC denir, çünkü yazma bilgileri kaybolur: çağrı yığındaki bir tamsayı bir adrese benzeyecek olursa, takip edilir, vb.

Diğer (daha zor) durumlarda, çalışma zamanı, nesiller arası bir kopya çöp toplama işlemi sağlar (tipik bir örnek, Ocaml kodunu, böyle bir GC kullanarak makine koduna derleyen Ocaml derleyicisidir). O zaman mesele tam olarak aramada tüm işaretçileri istifler ve bir kısmı GC tarafından taşınır . Sonra derleyici, çalışma zamanının kullandığı çağrı yığını çerçevelerini tanımlayan meta veri üretir. Dolayısıyla, çağrı yapan sözleşmeler ve ABI bu uygulamaya (yani derleyici) ve çalışma zamanı sistemine özgü hale geliyor .

Bazı durumlarda, derleyici tarafından üretilen makine kodu (aslında ona işaret eden kapaklar bile ) toplanan çöptür . Bu, özellikle her REPL etkileşimi için makine kodu üreten SBCL (iyi bir Common Lisp uygulaması) için geçerlidir . Bu aynı zamanda kodu ve içinde kullanılan çağrı çerçevelerini tanımlayan bazı meta veriler gerektirir.

Derleyici bazı çöp toplama programının bir kopyasını depolar ve oluşturduğu her çalıştırılabilir dosyaya yapıştırır mı?

Sıralama-of. Bununla birlikte, çalışma zamanı sistemi paylaşılan bir kütüphane olabilir, vb. Bazen (Linux ve diğer POSIX sistemlerinde), örneğin bir shebang ile yürütmek için geçirilen (2) bir betik yorumlayıcısı bile olabilir . Veya bir ELF tercüman, bkz elf (5) ve vbPT_INTERP

BTW, çöp toplama dilleri için pek çok derleyici (ve çalışma zamanı sistemi) bugün ücretsiz bir yazılımdır . Kaynak kodunu indirin ve inceleyin.


5
Açık bir spesifikasyon olmadan birçok programlama dili uygulaması olduğunu kastediyorsunuz . Evet, buna katılıyorum. Ancak benim açımdan, programlama dilinin bir yazılım olmadığı (bazı derleyiciler veya tercümanlar gibi) olduğu anlamına gelir. Sözdizimi ve anlambilim içeren bir şeydir (belki ikisi de tanımsızdır).
Basile Starynkevitch

4
@KonradRudolph: Bu tamamen "biçimsel" ve "şartname" tanımınıza bağlıdır :-D Ruby 1.8 ve 1.9'un kesişiminin küçük bir alt kümesini belirten ISO / IEC 30170: 2012 Ruby Programlama Dili Belirtimi vardır. Bir tür "çalıştırılabilir özellik" olarak hizmet veren bir dizi sınır örneği örneği olan Ruby Spec Suite vardır . Ardından, David Flanagan ve Yukihiro Matsumoto'nun Ruby Programlama Dili .
Jörg W Mittag

4
Ayrıca, Ruby Belgeleri . Ruby Issue Tracker ile ilgili konuların tartışılması . Yakut-çekirdekli (İngilizce) ve ruby-dev (Japonca) posta listeleri üzerine tartışmalar. Topluluğun sağduyu beklentileri (örneğin Array#[], O (1) en kötü durum, Hash#[]O (1) en kötü durum itfa edilmektedir). Ve son fakat en az olmayan: matz'in beyni.
Jörg W Mittag

6
@KonradRudolph: Mesele şu ki: resmi şartnamesi olmayan bir dil ve sadece tek bir uygulama hala "dil" (soyut kurallar ve kısıtlamalar) ve "uygulama" (bu kurallara göre kod işleme programları ve kısıtlamalar). Ve uygulama hala önemsiz olsa da, bir şartnameye yol açıyor, yani: "kod ne yaparsa, spec". Sonuçta, ISO özelliği, RubySpec ve RDocs, nihayetinde şöyle yazılmıştı: tümüyle ve / veya ters mühendislik MRI'sı ile oynayarak.
Jörg W Mittag

1
Bohem'nın çöp toplayıcısını getirmene sevindim. OP çalışmasını öneriyorum çünkü mevcut bir derleyiciye "cıvatalandığında" bile basit çöp toplama işleminin ne kadar basit olabileceğinin mükemmel bir örneği.
Cort Ammon

6

Zaten bazı iyi cevaplar var, ancak bu sorunun arkasındaki bazı yanlış anlamaları gidermek istiyorum.

Kendiliğinden "yerel olarak derlenmiş dil" diye bir şey yoktur. Örneğin, aynı Java kodu eski telefonumda (Java Dalvik) yorumlandı (ve sonra çalışma zamanında kısmen yapıldı) ve yeni telefonumda (ART) derlendi.

Yerel kod çalıştırma ve yorumlama arasındaki fark, göründüğünden çok daha az katıdır. Her ikisi de çalışmak için bazı çalışma zamanı kitaplıklarına ve bazı işletim sistemlerine ihtiyaç duyar (*). Yorumlanan kod bir yorumlayıcıya ihtiyaç duyar, ancak yorumlayıcı çalışma zamanının bir parçasıdır. Ancak tercüman yerine (tam zamanında) bir derleyici koyabildiğiniz için bu kesin değildir. Maksimum performans için ikisini birden isteyebilirsiniz (masaüstü Java çalışma zamanı bir tercüman ve iki derleyici içerir).

Kodu nasıl çalıştırdığınız önemli değil, aynı şekilde davranması gerekir. Belleği ayırmak ve serbest bırakmak, çalışma zamanı için bir görevdir (tıpkı dosyaları açmak, konuları başlatmak, vb.). Kendi dilinizde sadece yazmak new X()veya benzer. Dil belirtimi ne olması gerektiğini ve çalışma zamanının ne yaptığını söylüyor.

Bazı boş hafıza tahsis edilir, yapıcı çağrılır, vb. Alır. Yeterli hafıza olmadığında, çöp toplayıcı çağrılır. Zaten yerel bir kod parçası olan çalışma zamanında olduğunuz için bir tercümanın varlığı hiç önemli değil.

Kod yorumlama ve çöp toplama arasında doğrudan bir bağlantı yoktur. Sadece C gibi düşük seviyeli diller, yerel olmayan kod veya çöp toplayıcı fikrine uymayan her şeyin hızını ve hassas kontrolünü sağlamak için tasarlandı. Yani sadece bir korelasyon var.

Bu, örneğin Java tercümanının çok yavaştığı ve çöp toplayıcısının verimsiz olduğu eski zamanlarda çok doğruydu. Günümüzde, işler çok farklı ve çevrilmiş bir dilden bahsetmek hiçbir anlam ifade etmiyor.


(*) En azından genel amaçlı koddan bahsederken, önyükleme yükleyicilerini bir kenara bırakın ve benzerleri.


Hem Ocaml hem de SBCL yerel derleyicilerdir. Yani olan "doğal derlenmiş dil" uygulamaları.
Basile Starynkevitch

@BasileStarynkevitch WAT? Daha az bilinen derleyicileri adlandırmanın cevabımla ilgisi nedir? Başlangıçta yorumlanmış bir dilin derleyicisi olarak SBCL, ayrımın bir anlam ifade etmediği iddiamı destekleyen bir argüman değil mi?
maaartinus

Common Lisp (veya başka bir dili) olduğu değil yorumlanır veya derlenmiş. Bu bir programlama dilidir (bir şartname). Uygulaması bir derleyici, tercüman veya aralarındaki bir şey olabilir (örneğin bir bytecode tercüman). SBCL, Common Lisp'in interaktif bir şekilde derlenmiş bir uygulamasıdır. Ocaml ayrıca bir programlama dilidir (hem bytecode tercümanı hem de uygulama olarak yerel bir derleyici ile).
Basile Starynkevitch

@BasileStarynkevitch İddia ettiğim şey bu. 1. Tercüme edilmiş veya derlenmiş dil diye bir şey yoktur (C nadiren yorumlanır ve LISP nadiren derlenirdi, ama bu gerçekten önemli değil). 2. En iyi bilinen diller için yorumlanmış, derlenmiş ve karışık uygulamalar vardır ve derleme veya yorumlamadan önce bir dil yoktur.
maaartinus

6
Bence argüman çok mantıklı. Grok'un kilit noktası, her zaman bir "yerel program" veya "asla" çalıştırmanızdır, ancak görmek istersiniz. Windows'ta hiçbir exe çalıştırılabilir değildir; sadece başlamak için bir yükleyici ve diğer işletim sistemi özelliklerine ihtiyaç duyuyor ve aslında kısmen de "yorumlanıyor". Bu .net çalıştırılabilirleriyle daha belirgin hale gelir. java myproggibi çok veya az yerli grep myname /etc/passwdya da ld.so myprogBir argüman alır ve veri işlemleri gerçekleştirir (yani ne olursa olsun) bir çalıştırılabilir.
Peter A. Schneider,

3

Ayrıntılar, uygulamalar arasında değişiklik gösterir, ancak genel olarak aşağıdakilerin bir kombinasyonu:

  • Bir GC içeren bir çalışma zamanı kütüphanesi. Bu, bellek tahsisini idare edecek ve bir "GC_now" fonksiyonu dahil olmak üzere başka bazı giriş noktalarına sahip olacaktır.
  • Derleyici, GC için tablolar oluşturacak ve hangi veri tiplerinin hangi alanlarda referans olduğunu bileceklerdir. Bu, GC'nin istiften izleyebilmesi için her fonksiyon için yığın çerçeveleri için de yapılacaktır.
  • GC artımlıysa (GC aktivitesi programla iç içe geçiyorsa) veya eşzamanlı (ayrı bir iş parçacığında çalışır), derleyici referanslar güncellendiğinde GC veri yapılarını güncellemek için özel nesne kodunu da içerecektir. İkisinin veri tutarlılığı için benzer sorunları var.

Artımlı ve eşzamanlı GC'de, derlenen kod ve GC'nin bazı değişmezleri korumak için işbirliği yapması gerekir. Örneğin bir kopyalayıcı kollektörde GC, canlı verileri A alanından B alanına bırakarak çöpleri geride bırakarak çalışır. Bir sonraki döngü için A ve B'yi döndürür ve tekrarlar. Bu nedenle, bir kural, kullanıcı programının herhangi bir zamanda A uzayındaki bir nesneye başvurmaya çalıştığından emin olmak olabilir; bu tespit edilir ve nesne derhal B alanına kopyalanır ve burada programın erişmeye devam edebilir. GC'ye, bunun gerçekleştiğini belirtmek için nesneye yapılan diğer başvuruların izlendiklerinde güncellenmeleri için A alanında bir adres bırakılır. Bu bir "okuma engeli" olarak bilinir.

GC algoritmaları 60'lardan beri çalışılmaktadır ve konuyla ilgili geniş bir literatür vardır. Google daha fazla bilgi istiyorsanız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.