Mam pytanie dot jawy. Dosyc slabo znam
jawe (ale ze jako tako znam tematy z ogolnego
programowania to jak trzeba cos tam moge sklecic)
i ostatnio sie jej wlasnie przygladam, dokonujac
przy tym paru obserwacji (dosyc banalnych zreszta zapewne) powstaje przy tym dla mnie
przy okazji tego studiowania javy zasadnicze pytanie :

Czy te rozmaite wysokopoziomowe myki tj konkretnie widze na dany moment dwa

1) rozmaite 'nie zwalnianie' obiektow,
2) rozmaite 'przekazywanie' (i wrappowanie) obiektow itp

sa w jawie 'bezpieczne'?

Tj mam na mysli wszelkie sytuacje gdzie nie przejmuje sie zwalnianiem czegokolwiek

(np w danej konkretnej sytuacji mam tablice[][] z pixelami ale zeby to wyswietlic
musze to opakowac w image pozniej wyswietlic, poniewaz robie to w kazdej ramce to po
prostu tworze nowy image za kazdym razem nie przejmujac sie starym i nie zwalniajac
go)

podobnie jest z przekazywaniem i robieniem najrozmaitrzej sieczki wrapperow,
powiedzmy ze
mam jeden oryginalny kawalek danych z pixelami, czy
pakujac to w najrozmaitsze obiekty po drodze zeby
cos zrobic wyswietlic, zapisac na dysk, itp
mam gwarancje ze dane te nie beda topornie kopiowane
tylko ze to wszystko beda lekkie operacje?

tj czy jawie mozna zaufac ze nmie przejmujac sie
problemem zwalniania i problemem przekazywania i wrappowania poradzi sobie ona tj nie
wykona jakichs
masywnych duplikatow (albo jakichs innych pokrewnych
zarzynek). mam nadzieje ze moje pytanie jest
zrozumiale, a jesli nie i jawa moze wykonac taką zarzynkę to prosilbym najlepiej o
konkretny przyklad takiej zarzyny ze strony jawy. tnx

do góry

On 28 Lis, 12:04, kenobi <p...@g...com> wrote:
> Mam pytanie dot jawy. Dosyc slabo znam
> jawe (ale ze jako tako znam tematy z ogolnego
> programowania to jak trzeba cos tam moge sklecic)

Czy ty w ogóle potrafisz obsługiwać komputer? Masz jakąkolwiek
przeglądarkę internetową? Czy po prostu jesteś zwykłym leniem i
dresem, któremu nie chce się wpisać trzech słów w wyszukiwarce googla?

> i ostatnio sie jej wlasnie przygladam, dokonujac
> przy tym paru obserwacji (dosyc banalnych zreszta zapewne) powstaje przy tym dla
mnie przy okazji tego studiowania javy zasadnicze pytanie :
>
>  Czy te rozmaite wysokopoziomowe myki tj konkretnie widze na dany moment dwa
>
> 1) rozmaite 'nie zwalnianie' obiektow,
> 2) rozmaite 'przekazywanie' (i wrappowanie) obiektow itp
>
> sa w jawie 'bezpieczne'?

Wyszukiwarka goole: "java garbage collector"
Tylko uważaj, bo będziesz musiał samodzielnie coś doczytać.

Powrotu do zdrowia życzę
Piotr

do góry

tak wogole to moge chyba stwierdzic ze jestem niezwolennikiem nie tylko oop ale tez
wlasnie opaqowych api - warto moze zaznaczyc ta rzecz;
mz niekoniecznie musza byc publikowane zrodla
ale w dokumentacji powinny byc raczej publikowane opisy wewn implementacji

(ok, powtorzylem sobie troche jawe :/ teraz albo
ja jeszcze troche połupie albo cos nowego :/)

do góry

Użytkownik "kenobi" napisał w wiadomości grup
dyskusyjnych:1ffc9e93-a4f8-4a4e-b43e-7e7a64531534@go
oglegroups.com...

>1) rozmaite 'nie zwalnianie' obiektow,

Jest ok, podobnie jak w C++/CLR wskaźniki^

>2) rozmaite 'przekazywanie' (i wrappowanie) obiektow itp

Sorry, ale to jest ok nawet w zwykłym C - programowanie z użyciem
interfejsów (tj. wskaźników do struktur, które to struktury są nieobjaśnione
w .h)

>tj czy jawie mozna zaufac ze nmie przejmujac sie

Można. Ale IMHO te zwalnianie następuje jednak kiedyś, gdzieś, jakoś. I
wtedy zapewne będzie obciążało CPU.

do góry

On 28/11/2012 11:04, kenobi wrote:
> Mam pytanie dot jawy. Dosyc slabo znam
> jawe (ale ze jako tako znam tematy z ogolnego
> programowania to jak trzeba cos tam moge sklecic)
> i ostatnio sie jej wlasnie przygladam, dokonujac
> przy tym paru obserwacji (dosyc banalnych zreszta zapewne) powstaje przy tym dla
mnie przy okazji tego studiowania javy zasadnicze pytanie :
>
> Czy te rozmaite wysokopoziomowe myki tj konkretnie widze na dany moment dwa
>
> 1) rozmaite 'nie zwalnianie' obiektow,
> 2) rozmaite 'przekazywanie' (i wrappowanie) obiektow itp
>
> sa w jawie 'bezpieczne'?

Tak, obiektów nie musisz, a nawet nie możesz jawnie zwalniać, robi to za
ciebie GC.

> Tj mam na mysli wszelkie sytuacje gdzie nie przejmuje sie zwalnianiem czegokolwiek

Obiektów nie musisz zwalniać, natomias "cokolwiek" można różnie rozumieć
- są inne rodzaje zasobów, które trzeba odpowiednio zwalniać.

> (np w danej konkretnej sytuacji mam tablice[][] z pixelami ale zeby to wyswietlic
musze to opakowac w image pozniej wyswietlic, poniewaz robie to w kazdej ramce to po
prostu tworze nowy image za kazdym razem nie przejmujac sie starym i nie zwalniajac
go)

Nie musisz zwalniać, ale musisz przypilnować, że nie trzymasz referencji
do starych image'ów.

> podobnie jest z przekazywaniem i robieniem najrozmaitrzej sieczki wrapperow,
powiedzmy ze
> mam jeden oryginalny kawalek danych z pixelami, czy
> pakujac to w najrozmaitsze obiekty po drodze zeby
> cos zrobic wyswietlic, zapisac na dysk, itp
> mam gwarancje ze dane te nie beda topornie kopiowane
> tylko ze to wszystko beda lekkie operacje?

Kopiowanie będziesz miał wtedy, kiedy skopiujesz obiekt, np. metodą
clone(). Operacja wrapper.bebechy = mojObiekt nie kopiuje obiektów,
tylko ustawia referencję (to coś takiego jak wskaźnik) na istniejący obiekt.

Natomiast w zależności od tego, jak masz skonfigurowaną maszynę
wirtualną, sama operacja GC może powodować kopiowanie danych między
różnymi generacjami sterty. Ogólnie jeśli się chce optymalizować
programy w Javie pod względem wydajności warto wiedzieć jak działa GC i
z jakich strategii można korzystać. W większości przypadkó nie jest to
potrzebne.

> tj czy jawie mozna zaufac ze nmie przejmujac sie
> problemem zwalniania i problemem przekazywania i wrappowania poradzi sobie ona tj
nie wykona jakichs
> masywnych duplikatow (albo jakichs innych pokrewnych
> zarzynek). mam nadzieje ze moje pytanie jest
> zrozumiale, a jesli nie i jawa moze wykonac taką zarzynkę to prosilbym najlepiej o
konkretny przyklad takiej zarzyny ze strony jawy. tnx

Przykładow możesz mieć zarzynkę z powodu stop-the-workd GC, co ma
miejsce w przypadku przepełnienia którejś tam generacji sterty.

do góry

W dniu środa, 28 listopada 2012 14:59:25 UTC-5 użytkownik slawek napisał:
> Użytkownik "kenobi" napisał w wiadomości grup
> dyskusyjnych:1ffc9e93-a4f8-4a4e-b43e-7e7a64531534@go
oglegroups.com...
> >1) rozmaite 'nie zwalnianie' obiektow,
> Jest ok, podobnie jak w C++/CLR wskaźniki^

Pierwsze gc powstawalo w 80tych, przy chyba 16K pamieci. Jest ok.

> >2) rozmaite 'przekazywanie' (i wrappowanie) obiektow itp
> Sorry, ale to jest ok nawet w zwykłym C - programowanie z użyciem
> interfejsów (tj. wskaźników do struktur, które to struktury są nieobjaśnione
> w .h)

Trzeba faktycznie sprobowac zaimplementowac gc, zeby wiedziec tak
naprwade z czym to sie je. Wtedy latwiej jest zrozumiec co oznacza
"find nearest gc root" czy powod istnienia generacji w Javie
jak i doymslnie braku przeczesywania klas i ogolnie permGena.

> >tj czy jawie mozna zaufac ze nmie przejmujac sie
> Można. Ale IMHO te zwalnianie następuje jednak kiedyś, gdzieś, jakoś. I
> wtedy zapewne będzie obciążało CPU.

Ten, no, jawie mozna ufac, snu tez.

Powstalo sporo prac na temat benchmarkow Javy m.in. z tego powodu. Wiele
metod benchmarku nie uwzglednia gc, co jest takim machaniem rekami.
Oprocz gc dochodza generacje obiektow, JIT, miedzywatkowe optymalizacje
i wiele innych, ale nawet powazne publikacje nt. benchmarkow Javy
ograniczaja sie do uwglednienia gc, bo tak naprawde nikt tego nie ogarnia.

--
Edek

do góry

W dniu środa, 28 listopada 2012 06:04:33 UTC-5 użytkownik kenobi napisał:
> Mam pytanie dot jawy. Dosyc slabo znam
>
> jawe
> tylko ze to wszystko beda lekkie operacje?

Nie, nie beda lekkie, zarzadzanie pamiecia nigdy nie jest lekkie. W RT
zarzadzanie pemiecia musi byc poza RT.

> tj czy jawie mozna zaufac ze nmie przejmujac sie
> problemem zwalniania i problemem przekazywania i wrappowania poradzi sobie ona tj
nie wykona jakichs
> masywnych duplikatow (albo jakichs innych pokrewnych
> zarzynek). mam nadzieje ze moje pytanie jest
> zrozumiale, a jesli nie i jawa moze wykonac taką zarzynkę to prosilbym najlepiej o
konkretny przyklad takiej zarzyny ze strony jawy. tnx

Tworcy JVM mowia tak, i tyle moge powtorzyc: po prostu pisz kod. Nie probuj
udziwniac. Nie probuj robic pooli obiektow, JVM tego nie lubi. Nie
probuj ustawiac nieuzywanych rzeczy na null, o ile nie jestes pewien
ze to zwalnia cala chmure i nie zwolniloby inaczej (bo ma sciezke do gc root).

Czy w Javie bedziesz mial jakies zwiechy, nieprzewidywalne zachowania
pod wzgledem czasu wykonania (btw, w c i c++ alokacja i dealokacja tez nie jest
przewidywalna, w dowolnym wywolaniu moze stwierdzic, ze defragmentuje sterte),
jest nieprzewidywalne. Mozesz zmieniac opcje JVM, m.in. na concurrentGC,
ale YMMV.

Jedyna rzecza, ktora GC naprawde skutecznie poprawia, jest fragmentacja
sterty, ktora wystepuje w niektorych przypadkach gdy obiektow nie
mozna przeniesc w inne miejsce. Cala reszta to machanie rekami.

--
Edek

do góry

w sumie to ostatnimi czasy wyksztalcil mi sie
(co zreszta widac z posta) jakis obraz zdaje sie obowiazujacego podejscia do owej
jawy i
wydaje sie ze kluczowym slowem jest tu
wlasnie zaufanie.
Z tym ze do konca nie wiem jak to jest i
przydaloby sie chyba jak mowie doprecyzowac
tu jakos te kwestie a nie tylko robic wszystko
co mozna i ufac ze to jest napisane ok.
Tak wogole to ostatnimi czasy moje podejscie do myslenia i programowania coraz
bardaziej
sie trywializuje i wulgaryzuje poniekad na
skutek nasiakniecia popularna glupotą ktora
zewszad wlewa sie drzwiami i oknami (powinienem pewnie odizolowac sie i samodzielnie
pomyslec)

Co do ew uniemozliwienia kopiowań w javie to
bylaby to akurat fajna rzecz, w c nie byloby
to mozliwe (ale tak to jest rozne ew ciekawe
rzeczy pojawiaja sie w swiecie callbackow)

Co do teego ze te problemy z nieprzezroczystoscia dotycza tez api w c
to fakt, mnie to denerwuje i ew trzebebedzie
kiedys pomyslec czy nie da sie tego jakos opracowac.

Co do tutejszych odpowiedzi to na podstawowa
kwestie pt 'jak upewnic sie ze dany kod w javie
jest dobrze napisany i w miare lekko dziala'
niestaty nie uzyskalem odpowiedzi (a zdawaloby sie ze ci co pisza w javie powinni to
wiedziec )

do góry

Użytkownik <e...@g...com> napisał:

> Pierwsze gc powstawalo w 80tych, przy chyba 16K pamieci. Jest ok.

Edziu, doucz sie historii.
Pierwsze GC powstalo w latach 60tych
W dodatku bylo to bardzo dobre GC.

AK

do góry

Dnia 28.11.2012 e...@g...com <e...@g...com> napisał/a:
> W dniu środa, 28 listopada 2012 14:59:25 UTC-5 użytkownik slawek napisał:
>> Użytkownik "kenobi" napisał w wiadomości grup
>> dyskusyjnych:1ffc9e93-a4f8-4a4e-b43e-7e7a64531534@go
oglegroups.com...
>> >1) rozmaite 'nie zwalnianie' obiektow,
>> Jest ok, podobnie jak w C++/CLR wskaźniki^
>
> Pierwsze gc powstawalo w 80tych, przy chyba 16K pamieci. Jest ok.

A nawet wcześniej, w latach 60-tych (LISP)

do góry