November 28, 2012

Alıntı (zekeriyadurmus:1353958384):

>
> 	char[] x;
> 	file.read(x);
> 	GC.free(&x);
> ```

>

Keşke daha önce dikkat etseymişim. :( İngilizce forumda birisi söyleyince farkettim. Dilimin belleğini açıkça geri vermek için bir de 'GC.free(x.ptr)' dener misin. Nedeni, veri &x'te değil, x.ptr'dedir.

Ali

-- 
[ Bu gönderi, <http://ddili.org/forum>'dan dönüştürülmüştür. ]
November 28, 2012

Alıntı (Salih Dinçer):

>

önceden ~100 MB.'lık bellek bölgesi ayrılırken şimdi ~200 MB. ayrılmaya başladı

İlgisi olmayabilir: Ben de bu programları Linux altında ilk denediğimde hiç GC.free'yi çağırmadığım halde hem 200M hem de 100M kullanıldığını görmüştüm. Çöp toplayıcının bilinen belirsizliğine bağlı olduğuna karar vermiştim.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

November 29, 2012

Ali bey teşekkür ederim.

Attıklarınızı inceliyorum şu an.

En iyisi dediğiniz gibi 100mb lık parçalara böleyim.
GC.free(x.ptr) yapınca oldu bunu sonsuz bir döngüye soktum sürekli okuyup gc.free çalıştırdım 1 dakikaya yakın bir süre sonra hata verdi ama çok ta önemli birşey değil açıkcası :D

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

November 29, 2012

Bunun bir sorun olmadığı anlaşıldı.

Bu konu şu üç gerçeğin bir araya gelmesinden oluşuyor:

  • Riske girmek istemeyen çeşitten olan çöp toplayıcı (conservative garbage collector)

  • 32 bitlik adres alanı

  • Büyük bellek bölgesi ayırma

dmd'nin şu anda kullandığı çöp toplayıcı hassas değil: Ayrılmış olan bellek bölgelerini gösteriyor sanılabilecek her değerin gerçekten de o bölgeyi gösterdiği varsayılıyor. Örneğin, değeri tesadüfen 0x12345678 olan bir int bile daha önce ayrılmış olan ve 0x12345670 adresinden başlayan bellek alanını gösteren bir gösterge olarak kabul ediliyor. Conservative çöp toplayıcılar böyle işlerler.

32-bit ortamda böyle bir çöp toplayıcıyla çalışılınca, bir gigabayt belleğin gösteren rasgele değerlerin olasılığı çok yüksek oluyor: 1G, 32-bit alanın %25'idir. Walter Bright açtığım hatayı kapatırken bunu hatırlattı:

http://d.puremagic.com/issues/show_bug.cgi?id=9094#c1

64 bitlik bir ortamda çalışıldığında bu durumun olasılığı 4 milyar kat azalıyor.

Başka bir seçenek, her seferde çok daha küçük bellek bölgeleri ayırmak. Zekeriya, bu seçeneği hemen gözardı etmemeni öneririm. Bunun gerçekten önemli bir yavaşlık getireceğini ölçmeden bilemiyoruz.

Daha başka bir seçenek, otomatik bellek olanaklarını bir kenara bırakarak kendi belleğimizi kendimiz yönetmek. GC.free'yi açıkça çağırdığımızda da zaten belleğin yönetimini üstlenmiş oluyoruz. Elle bellek yönetiminin bir çok yolu var. Şu bölum bu konulara değiniyor:

http://ddili.org/ders/d/bellek_yonetimi.html

Şuradaki yazıda da bütün seçenekler var:

http://dlang.org/memory.html

Uyarı: Oradaki new ve delete işleçleri emekliye ayrıldılar.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

1 2 3
Next ›   Last »