Neden Java ve Python çöp toplama yöntemleri farklı?

oy
47

Python nesne ömrünü işlemek için başvuru sayısı yöntemini kullanır. Yani artık kullanımı vardır bir nesne derhal imha edilecektir.

Ancak, Java, GC (çöp toplama), artık, belirli bir zamanda kullanılan nesneleri yok eder.

Neden Java bu stratejiyi seçmek ve fayda bundan ne kadardır?

Bu Python yaklaşımından daha mı iyi?

Oluştur 22/08/2008 saat 06:35
kaynak kullanıcı
Diğer dillerde...                            


9 cevaplar

oy
8

Ben makale "düşünüyorum : çöp toplama kısa tarihi Java teori ve pratik IBM'den sahip sorulardan bazıları açıklamaya yardımcı olmalıdır".

Cevap 22/08/2008 saat 06:40
kaynak kullanıcı

oy
43

Referans sayacı kullanılarak sakıncaları vardır. en fazla sözü edilen bir dairesel referanslar aşağıda verilmiştir: referanslar B varsayalım, B C başvuran ve B'ye başvurusunu damla olsaydı Cı B başvuran, B ve C de hala bir 1 referans sayısı sahip olacak ve silinmez geleneksel bir referans sayma. CPython (referans sayma piton kendisinin bir parçası değildir, ancak C uygulamasının bir kısmını) periyodik olarak çalışır bir çöp toplama rutin dairesel referanslar yakalar ...

Başka bir dezavantajı: Referans sayımı icra yavaş yapabilir. Bir nesne başvurulan ve duruma gelmiş her defasında, tercüman / VM sayısı 0 aşağı gitti olmadığını kontrol edilmelidir (idiyse ve sonra ayırması). Çöp Toplama bunu yapmak gerekmez.

(Biraz yanıltıcı olabilir gerçi) Ayrıca, Çöp Toplama ayrı bir konu yapılabilir. RAM dolu ve çok yavaş bellek kullanmasına süreçleri için makinelerde, hiç GC yapıyor olmak istemeyebilir! Referans sayma performansı açısından orada bir dezavantajı biraz olacağını ...

Cevap 22/08/2008 saat 08:10
kaynak kullanıcı

oy
13

Darren Thomas iyi cevap verir. Ancak, Java ve Python yaklaşımlar arasındaki büyük bir fark ortak durumda referans sayma (hayır dairesel referanslar) nesneler bazı belirsiz sonraki bir tarihte daha hemen yerine temizlediğini olmasıdır.

Örneğin, örneğin, CPython özensiz, taşınabilir olmayan kod yazmak

def parse_some_attrs(fname):
    return open(fname).read().split("~~~")[2:4]

en kısa sürede açık dosyaya referans uzağa giderse, dosya çöp toplandı ve dosya tanıtıcı serbest olduğundan ve ben açılmış bu dosya için dosya tanıtıcı hemen temizlenecektir. Ben Jython veya IronPython ya da muhtemelen PYPY çalıştırırsanız Elbette, daha sonra çöp toplayıcı mutlaka çok sonrasına kadar yayınlanmaz; muhtemelen ilk dosya tanımlayıcıları tükenecek ve benim program kilitlenmesine.

Yani benziyor kod yazarken ÖNERİ

def parse_some_attrs(fname):
    with open(fname) as f:
        return f.read().split("~~~")[2:4]

ama bazen insanlar bazen kodunuzu biraz daha kısa yapabilir çünkü her zaman kendi kaynaklarını serbest bırakmak için referans sayma güvenmek ister.

Ben en iyi Çöp toplayıcı vb size nasıl farklar şu anda tüm bu çılgın optimizasyonlar ayrı bir konu çalıştırabilirsiniz Java tarzı kuşak çöp toplayıcılar gibi görünüyor ve sahip en iyi performansı biri olduğunu söyleyebilirim kodunuzu ihmal edilebilir ve ideal olmayan olmalıdır yazın.

Cevap 22/08/2008 saat 11:40
kaynak kullanıcı

oy
2

son Sun Java VM aslında ince ayar yapabilirsiniz birden GC algoritmaları var. Java VM özellikler kasıtlı farklı sanal makineler için farklı (ve çoklu), GC algoritmaları izin vermek için, gerçek GC davranışlarının çıkartıldı.

Örneğin, varsayılan Sun Java VM GC davranışı "dur-dünya" yaklaşımı sevmediğim tüm insanlar için, örneğin VM vardır IBM'in WebSphere Real Time Java çalıştırmak için gerçek zamanlı uygulama sağlar.

Java VM Spec kamuya açık olduğundan, CPython en GC algoritmasını kullanan bir Java VM uygulamaktan herkes durdurma (teorik olarak) hiçbir şey yoktur.

Cevap 22/08/2008 saat 21:58
kaynak kullanıcı

oy
2

Referans sayma çok dişli bir ortamda etkin bir şekilde yapmak için özellikle zordur. Ben bile donanım destekli işlemler veya benzeri (şu anda) olağandışı atomik talimatlar girmeden bunu yapmak için başlardım bilmiyorum.

Referans sayım uygulanması kolaydır. JVMs rakip uygulamalara gömülmüş çok para vardı, yüzden onlar çok iyi çözümleri çok zor problemler için uygulamak olması şaşırtıcı olmamalıdır. Ancak, JVM favori hedef dile giderek kolay oluyor.

Cevap 05/09/2008 saat 19:03
kaynak kullanıcı

oy
5

Yeterli bellek varsa Çöp toplama, referans sayma daha hızlı (daha fazla zaman verimli) 'dir. Örneğin, bir kopyalama gc yeni alana "canlı" nesneleri ve kopya onları geçtiği ve bir bütün bellek bölgesini işaretleyerek tek adımda tüm "ölü" nesneleri geri olabilir. Bu, çok verimli olmadığını yeterli belleğe sahip. Kuşak koleksiyonları "en nesneler genç ölür" bu bilgiyi kullanmak; genellikle nesnelerin sadece birkaç yüzde kopyalanması gerekir.

[Bu gc / ücretsiz malloc daha hızlı olabilir nedeni de]

o Hafýzayý o ulaşılamaz olur çok anı reclaims beri Referans sayma, çöp toplama çok daha fazla yer verimlidir. Eğer nesnelere finalizers (örneğin File nesnesi ulaşılamaz alır sonra bir dosyayı kapatmak için) eklemek istediğinizde bu güzel. belleğin sadece bir kaç yüzde özgür olduğunda bir referans sayma sistemi bile çalışabilir. Ama sahip yönetim maliyeti artırmak için ve her işaretçi atama üzerine eksiltme sayaçları çok zaman mal ve çöp toplama çeşit hala döngüleri kurtarmak için gereklidir.

Yani ticaret-off açıktır: Bir bellek kısıtlı bir ortamda çalışmak zorunda, yoksa kesin finalizers gerekirse, referans sayma kullanırsanız. Eğer yeterli hafızaya sahip ve hız gerekiyorsa, çöp toplama kullanın.

Cevap 16/09/2008 saat 15:38
kaynak kullanıcı

oy
26

Aslında sayım başvuru ile Sun JVM tarafından kullanılan stratejiler tüm çöp toplama algoritmaları farklı türleri vardır.

izleme ve referans sayma: Ölü nesneleri aşağı izlemek için iki geniş yaklaşım vardır. GC izleme yılında "kökler" den başlar - yığını referanslar gibi şeyler ve tüm ulaşılabilir (canlı) nesneleri izler. ulaşılamazsa şey ölü olarak kabul edilir. her seferinde sayma atfen referans nesnesi en onların sayısı güncelledik dahil değiştirilir. kimin başvuru sayısı sıfır olarak ayarlanmış olur herhangi bir nesne ölü olarak kabul edilir.

temelde tüm GC uygulamaları ile ticaret off var ama izleme koymak (yani hızlı) çalışması sayesinde yüksek için genellikle iyidir ancak daha uzun süreleri (UI veya program kadar donabilir büyük boşluklar) pause etmiştir. Referans sayma küçük parçalar çalışabilir, ancak daha yavaş genel olacaktır. Daha az donuyor ama kötü performans, toplamda anlamına gelebilir.

Buna ek olarak GC sayan bir referans tek başlarına başvuru sayısı tarafından yakalanmış olmayacak bir döngüde herhangi bir nesne temizlemek için bir döngü dedektör gerektirir. Perl 5 kendi GC uygulanmasında bir döngü detektörü yoktu ve siklik olduğu bellek sızıntısı olabilir.

Araştırma ayrıca, her iki dünyanın en iyisini (düşük duraklama süreleri, yüksek verimlilik) almak için yapılmıştır: http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/urc-oopsla-2003.pdf

Cevap 13/10/2008 saat 00:42
kaynak kullanıcı

oy
1

Geç oyunda fakat Python RC için bir önemli gerekçe sadeliği olduğunu düşünüyorum. Bu bak Alex Martelli tarafından e-posta örneğin.

(Python listesinde 13'üncü ekim 2005 google önbellek, e-posta tarih dışında bir bağlantı bulamadık).

Cevap 22/10/2009 saat 00:11
kaynak kullanıcı

oy
3

Java'nın izleme GC biri büyük dezavantajı zaman zaman bu "dünya durdurmak" olacak ve tam bir GC yapmak nispeten uzun süre uygulanması dondurmak olmasıdır. yığın büyük ve nesne ağacı kompleksi ise, birkaç saniye donar. Ayrıca her tam GC tekrar tekrar bütün nesne ağacı, muhtemelen oldukça verimsiz bir şey ziyaret eder. Java GC yapma şeklinin bir diğer dezavantajı (varsayılan yeterince iyi değilse) ne istediğinizi yığın boyutu Jvm anlatmak zorunda olmasıdır; JVM yığın içerisine istifleme çok fazla çöp olduğunda GC işlemini tetikler bu değer birkaç eşik türemiştir.

Bu iOS düzgünlüğü ile karşılaştırıldığında, hatta en pahalı cep telefonları üzerinde, aslında (Java tabanlı) Android'in sarsıntılı hissi ana nedeni olduğunu tahmin (ObjectiveC dayanmaktadır ve RC kullanarak).

Ben RC bellek yönetimini etkinleştirmek için bir jvm seçeneği görmek isteriz ve sol artık hafıza varken belki GC tutarak sadece son çare olarak çalıştırın.

Cevap 19/10/2011 saat 17:40
kaynak kullanıcı

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more