🚀 go-pugleaf

Przemek Pokrywka <adres@zastrzezony.com> writes:

> Chodzi o to, żeby zminimalizować koszt ich tworzenia i garbage
> collectingu.

Przy dobrym odśmiecaczu koszt alokacji obiektu to kilka instrukcji
maszynowych + wypełnienie go treścią, a koszt odśmiecania obiektu,
który żyje krótko, jest prawie zerowy (kosztuje tylko rozpoznanie
i wyprowadzenie młodych żywych obiektów).

Za to pozostawianie obiektów długo przy życiu i przypisania wskaźników
na młode obiekty do starych obiektów (write barrier) jest kosztowne.
I błędogenne.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Wed, 24 May 2006 19:25:54 +0200, Przemek Pokrywka
<adres@zastrzezony.com> wrote:

>Witam,
>
>W pewnej klasie aplikacji wymagane by³oby bardzo czêste tworzenie du¿ej 
>liczby obiektów, których czas ¿ycia by³by stosunkowo krótki.
>Chodzi o to, ¿eby zminimalizowaæ koszt ich tworzenia i garbage collectingu.
>
>Czy zna kto¶ z Pañstwa jakie¶ godne polecenia wzorce lub frameworki do 
>zarz±dzania pulami obiektów (definiowanymi przez u¿ytkownika)?

Moze poczytaj to zanim zaczniesz cos programowac...

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html


A.L.

Hmm, lektura Panów odpowiedzi nastraja optymistycznie... :-)
Koniec końców, wydajność zmierzy profiler.

--
Przemek

Dnia Wed, 24 May 2006 14:22:36 -0500, AL. skrobie:
> On Wed, 24 May 2006 19:25:54 +0200, Przemek Pokrywka
> <adres@zastrzezony.com> wrote:

> >Witam,
> >
> >W pewnej klasie aplikacji wymagane by?oby bardzo cz?ste tworzenie du?ej 
> >liczby obiektów, których czas ?ycia by?by stosunkowo krótki.
> >Chodzi o to, ?eby zminimalizowa? koszt ich tworzenia i garbage collectingu.
> >
> >Czy zna kto? z Pa?stwa jakie? godne polecenia wzorce lub frameworki do 
> >zarz?dzania pulami obiektów (definiowanymi przez u?ytkownika)?

> Moze poczytaj to zanim zaczniesz cos programowac...

O, widzę że Przemek Pokrywka dostąpił zaszczytu wypicia z panem "brudzia" :)

> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

To jest wszystko prawda to, co tam piszą - i oczywiście do tematu, który
został tutaj poruszony pasuje w 100%.

Jest w tym wszystkim tylko jedna drobna nieścisłość: autorzy (nie wiem, może
to tylko takie moje wrażenie) zupełnie mylnie łączą kwestię odśmiecania
pamięci jako element zarządzania pamięcią obiektów z kwestią odśmiecania
pamięci jako element językowy i tym samym element strategii tworzenia
oprogramowania.

Innymi słowy, odnoszę wrażenie że autorzy przyjmują milcząco, że tak sprawne
zarządzanie pamięcią, jakie oferuje nam odśmiecanie jest możliwe tylko wtedy,
gdy stosujemy "odśmiecany" model zarządzania obiektami, czyli inaczej mówiąc,
gdy polegamy na niejawnym usuwaniu zgubionych obiektów w przypadku wszystkich
istniejących obiektów w całym systemie. Przekonanie to jest moim zdaniem
całkowicie błędne.

Po pierwsze, zupełnie nie rozumiem, dlaczego takie znów niemożliwe byłoby
przyjęcie takiej strategii, że środowisko jest takie jakie, jak odśmiecane,
tylko że nie dokonuje się automatyczne trackowanie obiektów, a jest ono
uruchamiane dopiero w momencie zrobienia jawnego 'delete'. I to też
niekoniecznie za każdym, tylko z odpowiednią amortyzacją. Włączając w to
również możliwość przesuwania obiektów.

Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).

To jest też prawda, że odśmiecacz zapobiega wyciekom pamięci i zmniejsza
niebezpieczeństwo istnienia wiszących wskaźników, ale związku z efektywnością
przydzielania pamięci nie ma to za grosz.

Można by zadać pytanie, dlaczego w takim razie w C++ wciąż stosuje się
"malloc-based" przydzielanie pamięci (taka jest niestety praktyka, nie tylko w
gcc). Nie wiem. Może ktoś z grupowiczów mógłby przedstawić jakieś potencjalne
problemy z zaimplementowaniem takiej metody, jak opisana w p1?

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Thu, 25 May 2006 10:16:10 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:

>Dnia Wed, 24 May 2006 14:22:36 -0500, AL. skrobie:
>> On Wed, 24 May 2006 19:25:54 +0200, Przemek Pokrywka
>> <adres@zastrzezony.com> wrote:
>
>> >Witam,
>> >
>> >W pewnej klasie aplikacji wymagane by?oby bardzo cz?ste tworzenie du?ej 
>> >liczby obiektów, których czas ?ycia by?by stosunkowo krótki.
>> >Chodzi o to, ?eby zminimalizowa? koszt ich tworzenia i garbage collectingu.
>> >
>> >Czy zna kto? z Pa?stwa jakie? godne polecenia wzorce lub frameworki do 
>> >zarz?dzania pulami obiektów (definiowanymi przez u?ytkownika)?
>
>> Moze poczytaj to zanim zaczniesz cos programowac...
>
>O, widzę że Przemek Pokrywka dostąpił zaszczytu wypicia z panem "brudzia" :)
>
>> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
>
>To jest wszystko prawda to, co tam piszą - i oczywiście do tematu, który
>został tutaj poruszony pasuje w 100%.
>
>Jest w tym wszystkim tylko jedna drobna nieścisłość: autorzy (nie wiem, może
>to tylko takie moje wrażenie) zupełnie mylnie łączą kwestię odśmiecania
>pamięci jako element zarządzania pamięcią obiektów z kwestią odśmiecania
>pamięci jako element językowy i tym samym element strategii tworzenia
>oprogramowania.
>

Ze co?... Moglby Pan to napisac optymalniej?...

A.L.

On Thu, 25 May 2006 10:16:10 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
 
>To jest wszystko prawda to, co tam piszą - i oczywiście do tematu, który
>został tutaj poruszony pasuje w 100%.
>
>Jest w tym wszystkim tylko jedna drobna nieścisłość: autorzy (nie wiem, może
>to tylko takie moje wrażenie) zupełnie mylnie łączą kwestię odśmiecania
>pamięci jako element zarządzania pamięcią obiektów z kwestią odśmiecania
>pamięci jako element językowy i tym samym element strategii tworzenia
>oprogramowania.
>
>Innymi słowy, odnoszę wrażenie że autorzy przyjmują milcząco, że tak sprawne
>zarządzanie pamięcią, jakie oferuje nam odśmiecanie jest możliwe tylko wtedy,
>gdy stosujemy "odśmiecany" model zarządzania obiektami, czyli inaczej mówiąc,
>gdy polegamy na niejawnym usuwaniu zgubionych obiektów w przypadku wszystkich
>istniejących obiektów w całym systemie. Przekonanie to jest moim zdaniem
>całkowicie błędne.
>
>Po pierwsze, zupełnie nie rozumiem, dlaczego takie znów niemożliwe byłoby
>przyjęcie takiej strategii, że środowisko jest takie jakie, jak odśmiecane,
>tylko że nie dokonuje się automatyczne trackowanie obiektów, a jest ono
>uruchamiane dopiero w momencie zrobienia jawnego 'delete'. I to też
>niekoniecznie za każdym, tylko z odpowiednią amortyzacją. Włączając w to
>również możliwość przesuwania obiektów.
>
>Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
>szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
>alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).
>
>To jest też prawda, że odśmiecacz zapobiega wyciekom pamięci i zmniejsza
>niebezpieczeństwo istnienia wiszących wskaźników, ale związku z efektywnością
>przydzielania pamięci nie ma to za grosz.
>
>Można by zadać pytanie, dlaczego w takim razie w C++ wciąż stosuje się
>"malloc-based" przydzielanie pamięci (taka jest niestety praktyka, nie tylko w
>gcc). Nie wiem. Może ktoś z grupowiczów mógłby przedstawić jakieś potencjalne
>problemy z zaimplementowaniem takiej metody, jak opisana w p1?

Cytuje w calosci. Jest to Perelka Prawdziwego Nonsensu.

A.L.

Sektor van Skijlen wrote:

> 
> Innymi słowy, odnoszę wrażenie że autorzy przyjmują milcząco, że tak sprawne
> zarządzanie pamięcią, jakie oferuje nam odśmiecanie jest możliwe tylko wtedy,
> gdy stosujemy "odśmiecany" model zarządzania obiektami, czyli inaczej mówiąc,
> gdy polegamy na niejawnym usuwaniu zgubionych obiektów w przypadku wszystkich
> istniejących obiektów w całym systemie. Przekonanie to jest moim zdaniem
> całkowicie błędne.
> 
> Po pierwsze, zupełnie nie rozumiem, dlaczego takie znów niemożliwe byłoby
> przyjęcie takiej strategii, że środowisko jest takie jakie, jak odśmiecane,
> tylko że nie dokonuje się automatyczne trackowanie obiektów, a jest ono
> uruchamiane dopiero w momencie zrobienia jawnego 'delete'. I to też
> niekoniecznie za każdym, tylko z odpowiednią amortyzacją. Włączając w to
> również możliwość przesuwania obiektów.
Można tak by zrobić. Zostaje tylko pytanie po co. Po to żeby nie 
odśmiecały się obiekty jak ktoś zapomni o delete ?
I wtedy lepiej będzie pisać:
	 new Object().delete(); //żeby środowisko trackowało :-)

> Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
> szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
> alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).

Najefektywniejszym w jakim sensie ?
Np. w sesnie zużycia CPU to prawdopodobnie najefektywniejszym jest 
dokupienie kilku terabajtów pamięci i wyłaczenie gc :-)

> To jest też prawda, że odśmiecacz zapobiega wyciekom pamięci
nie
> i zmniejsza
> niebezpieczeństwo istnienia wiszących wskaźników, 
tak
> ale związku z efektywnością
> przydzielania pamięci nie ma to za grosz.

?


> Można by zadać pytanie, dlaczego w takim razie w C++ wciąż stosuje się
> "malloc-based" przydzielanie pamięci (taka jest niestety praktyka, nie tylko w
> gcc). Nie wiem. Może ktoś z grupowiczów mógłby przedstawić jakieś potencjalne
> problemy z zaimplementowaniem takiej metody, jak opisana w p1?

bo to by już nie było C++ tylko Java-- ?

-- 
jarekr

Dnia Thu, 25 May 2006 16:04:32 +0200, Jarek Ratajski skrobie:
> > Po pierwsze, zupełnie nie rozumiem, dlaczego takie znów niemożliwe byłoby
> > przyjęcie takiej strategii, że środowisko jest takie jakie, jak odśmiecane,
> > tylko że nie dokonuje się automatyczne trackowanie obiektów, a jest ono
> > uruchamiane dopiero w momencie zrobienia jawnego 'delete'. I to też
> > niekoniecznie za każdym, tylko z odpowiednią amortyzacją. Włączając w to
> > również możliwość przesuwania obiektów.
> Można tak by zrobić. Zostaje tylko pytanie po co.

Po to, żeby przydział i zwolnienie pamięci były mniej zasobożerne.

> Po to żeby nie 
> odśmiecały się obiekty jak ktoś zapomni o delete ?
> I wtedy lepiej będzie pisać:
>          new Object().delete(); //żeby środowisko trackowało :-)

Nie. Po prostu delete object; jak normalnie w C++.

A trackowanie obiektów w tym przypadku odbywałoby się tylko jako
"zabezpieczenie przed wyciekami". W przypadku, gdy na każdym obiekcie musisz
jawnie zrobić "delete", trackowanie może co najwyżej pomóc na defragmentację.

> > Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
> > szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
> > alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).

> Najefektywniejszym w jakim sensie ?
Zużycia czasu procesora na czynności związane z przydziałem i zwalnianiem
pamięci przeznaczonej na obiekty.

> Np. w sesnie zużycia CPU to prawdopodobnie najefektywniejszym jest 
> dokupienie kilku terabajtów pamięci i wyłaczenie gc :-)

Pomińmy to milczeniem. Jeśli się nie zgadzasz - proszę bardzo, masz pole do
popisu, tylko konkretnie, proszę.

> > To jest też prawda, że odśmiecacz zapobiega wyciekom pamięci
> nie
> > i zmniejsza
> > niebezpieczeństwo istnienia wiszących wskaźników, 
> tak
> > ale związku z efektywnością
> > przydzielania pamięci nie ma to za grosz.

> ?

Czego w powyższym zdaniu nie zrozumiałeś?

> > Można by zadać pytanie, dlaczego w takim razie w C++ wciąż stosuje się
> > "malloc-based" przydzielanie pamięci (taka jest niestety praktyka, nie tylko w
> > gcc). Nie wiem. Może ktoś z grupowiczów mógłby przedstawić jakieś potencjalne
> > problemy z zaimplementowaniem takiej metody, jak opisana w p1?

> bo to by już nie było C++ tylko Java-- ?

Taaa... może wybitny specjalista od języków wszelakich p. Andrzej Lewandowski
podpowie ci, w jaki sposób w Javie zapewnia się deterministyczność usuwania
obiektów.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Thu, 25 May 2006 08:17:12 -0500, A..L. skrobie:
> Cytuje w calosci. Jest to Perelka Prawdziwego Nonsensu.

Starzejesz się pan, niestety.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen napisał(a):
> Dnia Thu, 25 May 2006 16:04:32 +0200, Jarek Ratajski skrobie:
> 
>>>Po pierwsze, zupełnie nie rozumiem, dlaczego takie znów niemożliwe byłoby
>>>przyjęcie takiej strategii, że środowisko jest takie jakie, jak odśmiecane,
>>>tylko że nie dokonuje się automatyczne trackowanie obiektów, a jest ono
>>>uruchamiane dopiero w momencie zrobienia jawnego 'delete'. I to też
>>>niekoniecznie za każdym, tylko z odpowiednią amortyzacją. Włączając w to
>>>również możliwość przesuwania obiektów.
>>
>>Można tak by zrobić. Zostaje tylko pytanie po co.
> 
> 
> Po to, żeby przydział i zwolnienie pamięci były mniej zasobożerne.
> 
> 
>>Po to żeby nie 
>>odśmiecały się obiekty jak ktoś zapomni o delete ?
>>I wtedy lepiej będzie pisać:
>>         new Object().delete(); //żeby środowisko trackowało :-)
> 
> 
> Nie. Po prostu delete object; jak normalnie w C++.
> 
> A trackowanie obiektów w tym przypadku odbywałoby się tylko jako
> "zabezpieczenie przed wyciekami". W przypadku, gdy na każdym obiekcie musisz
> jawnie zrobić "delete", trackowanie może co najwyżej pomóc na defragmentację.

Weź sobie napisz symulator tego rozwiązania i zobacz jaka jest rónica w 
stosunku do normalnego gc (bez operacji delete).
Otóż ja widzę jedną istotną różnicę - obiekty długożyjące. Teraz 
powstaje pytanie: dużo takich masz? I czy warto się w to bawić skoro
narzut na ich śledzenie jest rozsądnie kompensowany w dowolnym 
generacyjnym gc.


>>>Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
>>>szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
>>>alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).
> 
> 
>>Najefektywniejszym w jakim sensie ?
> 
> Zużycia czasu procesora na czynności związane z przydziałem i zwalnianiem
> pamięci przeznaczonej na obiekty.
> 
> 
>>Np. w sesnie zużycia CPU to prawdopodobnie najefektywniejszym jest 
>>dokupienie kilku terabajtów pamięci i wyłaczenie gc :-)
> 
> 
> Pomińmy to milczeniem. Jeśli się nie zgadzasz - proszę bardzo, masz pole do
> popisu, tylko konkretnie, proszę.

Podałem rozwiązanie IMHO lepsze od twojego przy założeniu że 
minimalizujemy użycie CPU na allokacje/deallokacje. A więc - dedykowane 
allokatory NIE są najefektywniejsze (w podanym sensie).

> 
> 
> Czego w powyższym zdaniu nie zrozumiałeś?
> 

to paragraf-mydło - wnosi nic do dyskusji. (poza jedną wskazaną nieprawdą)
> 
> Taaa... może wybitny specjalista od języków wszelakich p. Andrzej Lewandowski
> podpowie ci, w jaki sposób w Javie zapewnia się deterministyczność usuwania
> obiektów.

No właśnie: jak będzie wyglądała ta deterministyczność przy twoim 
rozwiązaniu z trackowaniem po delete ? (zwłaszcza przy wzmiankowanej 
"amortyzacji" i "przesuwaniu" obiektów (cokolwiek to przesuwanie nie 
oznacza))

-- 
http://www.99-bottles-of-beer.net/language-java-866.html

On Thu, 25 May 2006 15:52:06 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
>
>> bo to by ju¿ nie by³o C++ tylko Java-- ?
>
>Taaa... mo¿e wybitny specjalista od jêzyków wszelakich p. Andrzej Lewandowski
>podpowie ci, w jaki sposób w Javie zapewnia siê deterministyczno¶æ usuwania
>obiektów.

Ja nie bede Panu odpowiadal bo nie da sie. Niech Pan sie najpierw
zastanowi co Pan pisze.

A jak idzie o deterministyczny garbege collector w Javie, to wie Pan,
mam jeda rade: uczyc sie, uczyc sie i uczyc sie. To czego sie Pan
nauczyl na studiach dawno juz nieaktulne, a na usenecie sa tylko
"urban legends".

Proponuje aby Pan pzreczytal na przyklad 

Fridtjof Siebert (aicas GmbH):
Constant-Time Root Scanning for Deterministic Garbage Collection

Fridtjof Siebert (aicas GmbH):
Eliminating External Fragmentation in a Non-Moving Garbage Collector
for Java

Fridtjof Siebert (aicas GmbH):
Hard Real-Time Garbage Collection in Java Virtual Machines

Fridtjof Siebert (aicas GmbH):
Guaranteeing Non-Disruptiveness and Real-Time Deadlines in an
Incremental Garbage Collector (corrected version)

na tej stronie

http://www.aicas.com/publications.html

Proponuje etz popatzrec tutaj:

http://www.aicas.com

i zajrzec pod JamaicaVM

No i moze Pan poczytac textbook (sczerze doardzam, zanim sie Pan
zacznie wymadrzac)

Concurrent and Real-Time Programming in Java 
by Andrew Wellings

gdzie jest napisane Jak To Sie Robi w Real Time Java.

No i najwyzszy czas zeby sie Pan dowiedzial co to jest naprawde
"garbage collector" i jak dziala. Tego tez sie uczy studentow, na
ptrzyklad z nastepuajcej ksiazki

Garbage Collection : Algorithms for Automatic Dynamic Memory
Management by Richard Jones, Rafael Lins 

czy tez stad

http://www.cs.kent.ac.uk/people/staff/rej/gc.html

Ze co?... Ze Pan nie musi czytac bo Pan wszystko juz wie?... No to ja
nic nie poradze...

A.L.

Dnia Thu, 25 May 2006 18:20:41 +0200, jarekr skrobie:
> Weź sobie napisz symulator tego rozwiązania i zobacz jaka jest rónica w 
> stosunku do normalnego gc (bez operacji delete).
> Otóż ja widzę jedną istotną różnicę - obiekty długożyjące. Teraz 
> powstaje pytanie: dużo takich masz? I czy warto się w to bawić skoro
> narzut na ich śledzenie jest rozsądnie kompensowany w dowolnym 
> generacyjnym gc.

Jasne; jaka jest różnica pomiędzy "dobrze zoptymalizowanym" śledzeniem, a
brakiem śledzenia? Sam sobie odpowiedz.

Nie interesuje mnie, jaka jest różnica pomiędzy tak przedstawionym sposobem
zarządzania pamięci, a tym, co ma Java. Interesuje mnie różnica względem
tradycyjnego malloc().

> >>>Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
> >>>szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
> >>>alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).
> > 
> > 
> >>Najefektywniejszym w jakim sensie ?
> > 
> > Zużycia czasu procesora na czynności związane z przydziałem i zwalnianiem
> > pamięci przeznaczonej na obiekty.
> > 
> > 
> >>Np. w sesnie zużycia CPU to prawdopodobnie najefektywniejszym jest 
> >>dokupienie kilku terabajtów pamięci i wyłaczenie gc :-)
> > 
> > 
> > Pomińmy to milczeniem. Jeśli się nie zgadzasz - proszę bardzo, masz pole do
> > popisu, tylko konkretnie, proszę.

> Podałem rozwiązanie IMHO lepsze od twojego przy założeniu że 
> minimalizujemy użycie CPU na allokacje/deallokacje. A więc - dedykowane 
> allokatory NIE są najefektywniejsze (w podanym sensie).

Zatem, twoim zdaniem, jak firma będzie sprzedawać oprogramowanie, to do
każdego egzemplarza powinna dołączać sztukę procesora i parę kości pamięci.

Podsuń ten pomysł firmom stosującym SOA. Myślę, że bardzo im się taki pomysł
przyda.

> > 
> > 
> > Czego w powyższym zdaniu nie zrozumiałeś?
> > 

> to paragraf-mydło - wnosi nic do dyskusji. (poza jedną wskazaną nieprawdą)

Dyskusja to się, prawdę mówiąc, jeszcze nie zaczęła ;)

> > Taaa... może wybitny specjalista od języków wszelakich p. Andrzej Lewandowski
> > podpowie ci, w jaki sposób w Javie zapewnia się deterministyczność usuwania
> > obiektów.

> No właśnie: jak będzie wyglądała ta deterministyczność przy twoim 
> rozwiązaniu z trackowaniem po delete ? (zwłaszcza przy wzmiankowanej 
> "amortyzacji" i "przesuwaniu" obiektów (cokolwiek to przesuwanie nie 
> oznacza))

Dokładnie tak samo, jak to wygląda aktualnie w C++. To język C++ gwarantuje ci
ową deterministyczność, a nie podsystem alokacji pamięci, którego
zaprojektowanie leży w gestii producenta implementacji lub systemu (jeśli
implementacja zwala to na system).

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Thu, 25 May 2006 12:31:09 -0500, AL. skrobie:
> A jak idzie o deterministyczny garbege collector w Javie, to wie Pan,
> mam jeda rade: uczyc sie, uczyc sie i uczyc sie. To czego sie Pan
> nauczyl na studiach dawno juz nieaktulne,

Akurat nie uczyłem się tego na studiach, pewnie na szczęście, skoro to już
bezużyteczne :)

> a na usenecie sa tylko "urban legends".

To, co pan pisze, też?

> na tej stronie

> http://www.aicas.com/publications.html

> Proponuje etz popatzrec tutaj:

> http://www.aicas.com

> i zajrzec pod JamaicaVM

Dziękuję. Właśnie o to mi chodziło.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Przemek Pokrywka <adres@zastrzezony.com> napisal:
> W pewnej klasie aplikacji wymagane byłoby bardzo częste tworzenie dużej 
> liczby obiektów, których czas życia byłby stosunkowo krótki.
> Chodzi o to, żeby zminimalizować koszt ich tworzenia i garbage collectingu.
> 
> Czy zna ktoś z Państwa jakieś godne polecenia wzorce lub frameworki do 
> zarządzania pulami obiektów (definiowanymi przez użytkownika)?

Jezeli to COM+, to moze zastosowac pooling?
-- 
Pozdrawiam,

Jacek Pietraszek