Dnia Wed, 28 Mar 2012 06:51:52 +0000, M.M. napisal:

> Czesc
>
> Kiedyś dawno z lat temu 10 albo jeszcze dawniej, przeczytałem
> straszną rzecz o wyjątkach w C++. Pisał sam Lippman więc się trochę
> przejąłem. Pisał on mianowicie że po włączeniu wyjątków skompilowany
> program nie zmieścił się w pamięci ram. Nie zastanawiając się głębiej
> uznałem że wyjątki wiążą się z jakimś narzutem i gdy była ważna
> szybkość działania programu to ich nie używałem.

Dzisiaj różnica w szybkości działania jest prawie żadna, o ile
wyjątek nie jest rzucony. Jest narzut na obsługę wyjątku w postaci
kodu obsługującego (czy masło jest wystarczająco maślane? ;) i
straconych optymalizacji - to już zależy od języka i implementacji
wyjątków.

Odniosę się do C++ głównie.

> Teraz gdy się zastanawiam to wydaje mi się kompletnie bezsensowne aby
> wyjątki wiązały się z jakimś dużym narzutem. Do czego ten narzut niby jest
> potrzebny?

Musi być kod robiący wszystko to, co jest przewidziane. W C++ oznacza
to destrukcję lokalnych obiektów, sprawdzenie catch-clauses i
unexpected-handlera, poza samym stack unwind.

>
> Gdy kompilator napotyka instrukcję try to co musi zrobić? Moim zdaniem
> musi gdzieś zapamiętać adres wejścia do sekcji catch. Coś takiego
> chyba najlepiej zapamiętać na jakimś stosie. Więc dużo zależy od tego
> jak stos jest realizowany. Jeśli odkładanie elementu na stos jest
> związane z malloc to mamy narzut taki sam jaki narzut ma malloc. Jeśli
> stos jest budowany bez malloc to narzut jest pomijalny, wystarczy tylko
> zapamiętać trochę danych, może z 20-30 bajtów.

Implementacja zależy od języka. W c++ zapamiętuje się call-site'y
i opisuje zachowanie na wypadek wyjątku w specjalnych strukturach.

W Javie (bytekod) zapamiętuje się regiony.

>
> Gdy kompilator napotyka koniec sekcji catch to co musi zrobić? Chyba tylko
> musi usunąć ze stosu to co wcześniej na nim zapamiętał. Więc o wydajności
> decyduje sposób w jaki to kompilator zapamiętuje.

(?) Nie kompiluje mi się to co napisałeś.

>
> A co gdy kompilator napotyka throw Object? Zdaje się że musi odczytać
> kolejno zapamiętane informacje przy napotkaniu try. Jeśli znajdzie
> pasujący catch( Object ) to musi odtworzyć stos pointer. Potem na stos
> odkłada Object i musi zrobić long jump do odpowiedniego catch.

Sam fakt, że wyjątek ma stos zmienia optymalizacje. W c++
stos zależy od optymalizacji; w Javie generalnie nie, ale czasami
tak.

>
> Jednak wyjatki rzadko sie uaktywniają. Najczęściej mamy
> if( false ) throw Object. Czy kompilator jak widzi ze w
> procedurze jest throw Object to musi wygenerować jakiś
> kod który się wykona pomimo że wyjątek nie będzie rzucony?
> Moim zdaniem nie musi.
>
> Gdzie tu jest problem z wydajnością, albo z ogromną pamięcią? Nie
> mogę się doszukać. Lippman bzdury pisał czy ja czegoś nie rozumiem?

Przykład z Javy: jeżeli JIT ciężko optymalizuje fragment kodu,
odwołuje się do referencji. Domyślnie mimo wszystko zakłada, że mogą
być null-em, ale upraszcza rzucanie NullPE - rzucane są bez stosu
w ogóle, nie tylko stosu bez wyoptymalizowanego fragmentu. Jest opcja,
która zmienia zachowanie i NPE zawsze ma stos, kosztem słabszej
optymalizacji.

Sam fakt, że JIT domyślnie upraszcza zachowanie tak, że zmienia
semantykę NPE, świadczy o tym, że architekci uznali że warto.

Edek