A.L. wrote:
[...]
>> Ech - ostatecznie chyba zrobię funkcję close(). Programiści Javy są do
>> takich funkcji mocno przyzwyczajeni, więc chyba nie będą marudzić przy
>> jeszcze jednej? :-|
>
> W jezkach z GC, wbrew powszechnej opinii, tez potzrebne sa
> destruktory. Czasami. Wiec nei widz nic zlego w close(), tyle ze ja
> taka metode nazywam destroy()

Jakby jeszcze takie destruktory miały wsparcie w języku w kierunku
deterministycznego/jak najszybszego wywoływania, to byłoby super.
Wystarczyłoby chyba wywołanie takiego destruktora w momencie porzucania
obiektu, a nie (jak finalizatora) w momencie usuwania przez GC. To
wprawdzie spowodowałoby wolniejszą obsługę referencji do tego typu
obiektów, ale za to byłaby możliwość dania dobrych wskazówek dla GC +
szybkie zwalnianie zewnętrznych zasobów.

--
Paweł Kierski
n...@p...net

do góry

On Jul 28, 2:48 pm, Paweł Kierski <n...@p...net> wrote:

>    Jakby jeszcze takie destruktory miały wsparcie w języku w kierunku
> deterministycznego/jak najszybszego wywoływania, to byłoby super.
> Wystarczyłoby chyba wywołanie takiego destruktora w momencie porzucania
> obiektu, a nie (jak finalizatora) w momencie usuwania przez GC.

Nie da się tego pogodzić z efektywnym GC. Nie wiadomo, kiedy dokładnie
obiekt jest "porzucany", bo do obiektu mogą się odwoływać różne inne
obiekty, więc potencjalnie trzeba by to wiedzieć o wszystkich - czyli
trzeba by uaktualniać wiedzę o dostępnych obiektach na bieżąco, przy
każdej operacji, zamiast amortyzowania tego po wielu operacjach.

do góry

On Tue, 28 Jul 2009 07:34:11 -0500, A.L. <a...@a...com> wrote:

>On Mon, 27 Jul 2009 13:36:43 -0700 (PDT), Maciej Sobczak
><s...@g...com> wrote:
>
>>On 2
>>Potrzebna jest taka mapa: Map<Long, Item> (ewentualnie jej
>>WeakReference warianty). W tej mapie kluczami są Longi a wpisy mają
>>być usunięte po porzuceniu wartości Item.
>>
>
>Ja mialem na mysli WeakHashMap w ktorej kluczem jest Item a waroscia
>slaba referencja na klucz. Item musi miec "equals" zaomplementowane na
>podstawie rownosci ID, a do wyszukiwania tzreba zrobic "dummy" Item z
>zainicjowana wartoscia ID taka jakiej poszukujemy
>
Napisalem krotki programik zeby pokazac o co mi chodzi

public class Test {

public static void main(String[] args) {
WeakHashMap<Item, WeakReference<Item>> m = new
WeakHashMap<Item, WeakReference<Item>>();
//
// Pierwszy element
//
Item item1 = new Item((long)20);
m.put(item1, new WeakReference<Item>(item1));
//
// Wyciagnij
//
Item dummy = new Item((long)20);
System.out.println(m.get(dummy).get());
//
// Odetnij referencje
//
item1 = null;
//
// Wstaw nowy element
//
Item item2 = new Item((long)30);
m.put(item2, new WeakReference<Item>(item1));
//
// Powiedz gc zeby sie uaktywnil
//
System.gc();
//
// Sprawdz czy element jest
//
if(m.get(dummy) == null) {
System.err.println("null");
} else {
System.out.println(m.get(dummy).get());
}
}
}

public class Item {
private Long _ID = null;

public Item(Long key) {
this._ID = key;
}

public long getkey() {
return this._ID;
}

public int hashCode() {
return this._ID.hashCode();
}

public String toString() {
return "ID " + this._ID;
}

public boolean equals(Object object) {
if(object == null) {
return false;
}
return this._ID.equals(((Item)object)._ID);
}
}

Program pisze

ID 20
null

equals jes tzrobione tak sobie, ale do tego testu wystarczy

mam nadzieje ze sie nie pomylilem nigdzie :)

A.L.

do góry

On Tue, 28 Jul 2009 14:53:22 -0500, A.L. <a...@a...com> wrote:

>On Tue, 28 Jul 2009 07:34:11 -0500, A.L. <a...@a...com> wrote:
>
>>On Mon, 27 Jul 2009 13:36:43 -0700 (PDT), Maciej Sobczak
>><s...@g...com> wrote:
>>
>>>On 2
>>>Potrzebna jest taka mapa: Map<Long, Item> (ewentualnie jej
>>>WeakReference warianty). W tej mapie kluczami są Longi a wpisy mają
>>>być usunięte po porzuceniu wartości Item.
>>>
>>
>>Ja mialem na mysli WeakHashMap w ktorej kluczem jest Item a waroscia
>>slaba referencja na klucz. Item musi miec "equals" zaomplementowane na
>>podstawie rownosci ID, a do wyszukiwania tzreba zrobic "dummy" Item z
>>zainicjowana wartoscia ID taka jakiej poszukujemy
>>
>Napisalem krotki programik zeby pokazac o co mi chodzi
>
>public class Test {
>
> public static void main(String[] args) {
> WeakHashMap<Item, WeakReference<Item>> m = new
>WeakHashMap<Item, WeakReference<Item>>();
> //
> // Pierwszy element
> //
> Item item1 = new Item((long)20);
> m.put(item1, new WeakReference<Item>(item1));
> //
> // Wyciagnij
> //
> Item dummy = new Item((long)20);
> System.out.println(m.get(dummy).get());
> //
> // Odetnij referencje
> //
> item1 = null;
> //
> // Wstaw nowy element
> //
> Item item2 = new Item((long)30);
> m.put(item2, new WeakReference<Item>(item1));
>

No, pomylilem sie. Powinno byc

m.put(item2, new WeakReference<Item>(item2));

Ale to nie ma znaczenia dla ogolnej koncepcji...

A.L.

do góry

Marcin 'Qrczak' Kowalczyk wrote:
> On Jul 28, 2:48 pm, Paweł Kierski <n...@p...net> wrote:
>
>> Jakby jeszcze takie destruktory miały wsparcie w języku w kierunku
>> deterministycznego/jak najszybszego wywoływania, to byłoby super.
>> Wystarczyłoby chyba wywołanie takiego destruktora w momencie porzucania
>> obiektu, a nie (jak finalizatora) w momencie usuwania przez GC.
>
> Nie da się tego pogodzić z efektywnym GC. Nie wiadomo, kiedy dokładnie
> obiekt jest "porzucany", bo do obiektu mogą się odwoływać różne inne
> obiekty, więc potencjalnie trzeba by to wiedzieć o wszystkich - czyli
> trzeba by uaktualniać wiedzę o dostępnych obiektach na bieżąco, przy
> każdej operacji, zamiast amortyzowania tego po wielu operacjach.

A gdyby trzymać taką wiedzę tylko o pewnych klasach obiektów? Np.
implementujących "szybki" destruktor?

--
Paweł Kierski
n...@p...net

do góry

On 28 Lip, 21:53, A.L. <a...@a...com> wrote:

> Napisalem krotki programik zeby pokazac o co mi chodzi
>
> public class Test {
>
>     public static void main(String[] args) {
>        WeakHashMap<Item, WeakReference<Item>> m = new
> WeakHashMap<Item, WeakReference<Item>>();

[...]

Teraz rozumiem. Tak, to ciekawy pomysł. Trochę psuje interfejs klasy
Item - ta klasa i mapa są w różnych pakietach, przez co dodatkowy
konstruktor Item musiałby być publiczny, wbrew innym założeniom tego
projektu. Można z tym powalczyć psując projekt jeszcze gdzieś indziej
(np. przez hierarchię klas, użycie różnych typów w mapie i
rzutowanie), ale koncepcyjnie jest to jakieś rozwiązanie.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

> Użyj mapy gdzie klucze też mogą być słabymi referencjami.

miało być: _wartości_ też mogą...

PL

do góry

Użytkownik Paweł Kierski napisał:
> Marcin 'Qrczak' Kowalczyk wrote:
>> Nie da się tego pogodzić z efektywnym GC. Nie wiadomo, kiedy dokładnie
>> obiekt jest "porzucany", bo do obiektu mogą się odwoływać różne inne
>> obiekty, więc potencjalnie trzeba by to wiedzieć o wszystkich - czyli
>> trzeba by uaktualniać wiedzę o dostępnych obiektach na bieżąco, przy
>> każdej operacji, zamiast amortyzowania tego po wielu operacjach.
>
> A gdyby trzymać taką wiedzę tylko o pewnych klasach obiektów? Np.
> implementujących "szybki" destruktor?
>

W praktyce i tak należałoby trzymać taką wiedzę dla wszystkich obiektów.
Można by zrobić GC w oparciu o zliczanie referencji z dodatkowo fazą
usuwającą cykle. Taki GC jest np. w Pythonie. W każdym razie unikając
cykli da się w tym przypadku uzyskać deterministyczne wołanie
destruktorów. Zastanawiają mnie koszty takiego rozwiązania, ponieważ
nie słyszałem, aby to rozwiązanie było powszechnie stosowane w Java VM.

Pozdrawiam
KK

do góry

On Jul 29, 9:04 am, Paweł Kierski <n...@p...net> wrote:

> > Nie da się tego pogodzić z efektywnym GC. Nie wiadomo, kiedy dokładnie
> > obiekt jest "porzucany", bo do obiektu mogą się odwoływać różne inne
> > obiekty, więc potencjalnie trzeba by to wiedzieć o wszystkich - czyli
> > trzeba by uaktualniać wiedzę o dostępnych obiektach na bieżąco, przy
> > każdej operacji, zamiast amortyzowania tego po wielu operacjach.
>
>    A gdyby trzymać taką wiedzę tylko o pewnych klasach obiektów? Np.
> implementujących "szybki" destruktor?

Przynależność do tej klasy byłaby zaraźliwa. Rozważ takie przypadki:

- Typ obiektu nie jest statycznie znany. Nie wiadomo, czy go śledzić.

- Obiektem jest obiekt funkcyjny, do którego środowiska należy obiekt,
który trzeba śledzić (ten fakt nie jest widoczny w typie funkcji). To
jest szczególny przypadek poprzedniego punktu.

Trzeba by więc albo śledzić mnóstwo obiektów niepotrzebnie, kiedy
statycznie nie wiadomo, czy rzeczywiście trzeba (tak robi kanoniczna
implementacja Pythona), albo wprowadzać podział w systemie typów na
dwa światy z utrudnioną komunikacją między nimi, w szczególności
zabronić odśmiecanym obiektom odwoływania się do nieodśmiecanych
(chyba tak jest w C++/CLI).

do góry

On Wed, 29 Jul 2009 00:42:05 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 28 Lip, 21:53, A.L. <a...@a...com> wrote:
>
>> Napisalem krotki programik zeby pokazac o co mi chodzi
>>
>> public class Test {
>>
>>     public static void main(String[] args) {
>>        WeakHashMap<Item, WeakReference<Item>> m = new
>> WeakHashMap<Item, WeakReference<Item>>();
>
>[...]
>
>Teraz rozumiem. Tak, to ciekawy pomysł. Trochę psuje interfejs klasy
>Item - ta klasa i mapa są w różnych pakietach, przez co dodatkowy
>konstruktor Item musiałby być publiczny, wbrew innym założeniom tego
>projektu. Można z tym powalczyć psując projekt jeszcze gdzieś indziej
>(np. przez hierarchię klas, użycie różnych typów w mapie i
>rzutowanie), ale koncepcyjnie jest to jakieś rozwiązanie.

Do kreowania "dummy" ja bym bie robil konstruktora ale statyczna
metode createKey. Na dodatek, wystarczy jeden egzemplarz "dummy"
jeseli zrobimy druga methode umozliwiajaca zmiane ID

A.L.

do góry