Защо Java

GC е по-добър дори от стандартните malloc / free

Земи се събуди, мойто момче. От поне десет години оптимизирането на заявките към паметта съществува във всяка значима ОС за всяка по-сложна хардуерна система. Очевидно е, че освободеното парче памет може да се реюзва след известно време, и поради тая причина не се обявява за свободно преди някакъв таймаут. При постъпила заявка за парче със същите размери, просто му се опреснява състоянието, без да се налага да се търсят наново свободни участъци.
Жабата по принцип не може да се възползва от тоя фичър, тъй като виртуална й машина на практика е ОС в ОС-а, барабар с мениджъра на паметта - който е слой-дупликат над мениджъра на самата ОС. И е нормално в един момент да се извърви същия път относно оптимизирането на заявките - отново като слой-дубликат.И да се твърди, че слоят-дубликат е по-бърз от ядрото е просто смешно.

Що бе, в случая съм съгласен с него. И в науката е така - всички сложни теории обикновено се оказват неверни и се заменят с по-прости.

Абе от Април месец съм напуснал, не си спомням детайли вече. Обаче си спомням кво ми беше гадно като се върнах на 6-ца ( макар и с Азис ).
Нека някой жабар да разясни по-добре от мен какво имам предвид.

Общо взето страшно много неща прави вместо теб.
Например ако искаш да смениш името на някоя променлива, ама точно на нея, а не на всички които имат същото име зор ще видиш в голям сорс. А тва го прави само и във всички файлове.
Ако имаш Интерфейс ( демек наследяваш абстрактни функции ) тва може да ти ги напише ( празни, де ).
Ако някакъв код хвърля exception тва може да ти го загради в try catch. А ако не се лъжа throw спецификатора дори 7-цата не го поддържа ( за 6-цата е сигурно ).
В жаба Get и Set функциите имат по-широка семантика отколкото в C++ и имат смисъл дори да ти е публик променливата ( използват се при серизлизация ). Можеш с едно натискане да си ги изгенерираш за една или повече променливи на класа.
Ако ползваш некоя функция веднага получаваш списък с файловете дето можеш да инклуднеш за да я виждаш. Нема нужда да ходиш до началото на файла.

Абе много неща са, не мога да се сетя за всички. Те са малки неща, много на брой. Дреболии като женската работа вкъщи, която разбираш колко е много като зачезне жената. Просто страшно много ръкоделие спестява. Само с един два бързи клавиша върши работа дето на ръчица ще ти отнеме бая повече време.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Абе тя OS може да е оптимизирана, ама malloc/free работят с вътрешен мениджър на паметта и заделят от Win-а само големи блокове.

Навремето Гого беше доказал един бъг в мениджъра на паметта на Builder-а. С една функцийка на няколко реда, която с алокираше и деалокираше памет с подходящ размер и в определена последователност успяваше да глътне всичката свободна памет.

М/у другото ти къде бачкаш? Няма ли с теб да се уцелим най-после в някоя фирма :-) От Борг ме изхвърлиха и в момента съм безработен.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Наистина полезно, особено тва с преравянето на файловете на проекта. Мен ми се налага да го правя с външни тулове.
Обаче за try-catch трудна работа, що се касае C++, щото по принцип самите системни ф-ии (или такива от статични библиотеки) може да ти хвърлят ексепшъни.

Не е възможно да не се задейства колектора. Възможно е да си мисли, че паметта е заета - т.е. да има валиден указател към нея. Ако абсолютно не разбираш какво вършиш, и с малко талант, можеш да го постигнеш и с един цикъл.


Другия начин е библиотеката за обработка на изображения да използва native code, и неправилно да не си освобождава паметта. В този случай се налага да обвиним С кода в класическа грешка.


Разпространен мит е, че сетването на null въобще решава някакъв проблем. Той е сигурен признак, че някой не разбира как работят нещата. Също така издава VB background.


Недей да мислиш като някой джавар, който сяда да пише на C++ и казва: "това е бахти тъпия език, не освобождава динамично заделена памет, и свободната памет непрекъснато намалява" - и той наистина не освобождава ако викаш само new, трябва и delete. Виж, ако пробва да сетва променливата на null като приключи с нея, може пък да помогне.


Не е достатъчно да вярваш на това, което си видял, трябва и да го разбираш.
(това е за разпускане )

Силно казано - вътрешен мениджър. Просто в дебъг режим има определени особености - най-вече, че всеки заделен блок се записва някъде, за да ти плюе после инфо за лийкове. За да придобиеш определена представа за опримизиациите, пробвай следното нещо - пусни си самото VS, затвори го, после го пусни веднага пак. И виж времето за което се стартира първия път и колко втория. Още по-приятен пример е Photoshop.
Ти Гого от Icom ли имаш предвид?

Иначе в момента съм в Сиела. Много приятна фирма, изобщо си мисля, че по принцип българските фирми са по-приятни от западните/близкоизточните и изобщо работещите в тоя дух. Ако искаш, може да отвориш друга тема за това.
Аз също кандидатствах в Борг, ама нещо не ме харесаха. Макар, че бих им бил много полезен, предвид хобито ми. Но - хората си имат критерии. Бях силно стресиран от условията на работа там - наблъскали 100 човека като говеда в едно огромно хале. Баси гадорията.

GC може наистина да е по-добър от malloc/free. Например защото:

1. не би извършил определени деалокации, които биха се случили при ползването на free)

2. Може да "уплътни" обектите и по този начин да намали шанса за cache miss
(например някой копиращи GC)

3. Може да намали фрагментацията на паметта и по този начин да се окаже, че "дебелата GC програмка" харчи по-малко памет от "ръчно оптимизираната програмка с ръчно управление на паметта"

4. GC програмката никога няма да прочете онзи указател от вече освободената памет, преди това заемана от една структура, и в резултат никога няма да се случи Segmentation fault (по тази причина).

5. Не се налага програмиста да мисли кой, кога заделя памет и кой трябва да я освободи. Това МНОГО, ама МНОГО, невероятно МНОГО, опростява писането на модулен код, което МНОГО, ....., ама МНОГО помага на програмиста да не пише БОЗАВ код.

Горното не го казвам в защита на Джава (немога да защитавам Джава, нееееее)
Впечатлението ми от Джава е че е доста тежка, но става за писане на UI.
Не съм запознат с GC на Джава. Чувал съм че бил сложен, но това не го прави непременно по-добър.

What evil shall I do today?

Този механизъм е за намаляване на фрагментацията, на практика няма отношение към скоростта. Свободните парчета памет си се държат в свързан списък и този списък се обхожда докато не се намери достатъчно голямо парче памет. Поддръжката на свързания списък е овърхеда при С.

Как така са те изхвърлили от Борг, Стефчо е такава добра душа...

Лисп например има същия тип колектор, обаче познай дали някоя реализация на Лисп има толкова оптимизиран колектор колкото Java... просто Javaта е достатъчно масова за да си струва да я оптимизираш.

Ми не му се оплаках на време при какви условия работя. Аз съм първия човек когото Стефан изхвърля. Изпокарахме се като цигани с тийм лидера, та цял Борг разбра. После той ми сложи ниски оценки и така. Абе шибана работа, направо ме срина психически. От месец и нещо вчера за пръв път пуснах CV, че почвам да приключвам ресурсите.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Я! Какъв колектор има лисп? И кой лисп? Има мнооооого различни колектори за разни лиспове и дори (не съм проверявал!) никъде стандарта (например за Common Lisp или Scheme) не казва какъв колектор се ползва. Това е Implementation specific.
Все пак ми е интересно да разбера какво ползва Джавата.

What evil shall I do today?

Алгоритъма зависи от реализацията, но колектора трябва да отговаря на определени условия, например не може да е с reference counting защото няма да освобождава циклични области от графа от обекти. Това имам предвид под "същия тип".

Java също има различни колектори според това кой е правил JVM, коя версия е и например дали е клиентско или сървърско, но спецификацията е една и функционално са еднакви.

В отговор на:

---

GC може наистина да е по-добър от malloc/free. Например защото:

---

Почти всичко може да се случи в добре подбрани частни случаи.

Например може човек да спечели 6-ца от тотото.
Или да оцелее като падне от 25 метра.
Или квото там се сетиш малко вероятно.

Факт е, че няма регистриран случай на жабешка програма дето да не гълта памет като ламя. Обикновено има и еквивалент писан на старомеден език, който е незабележим.

Ето какво обикновено става:

В отговор на:

---

1. не би извършил определени деалокации, които биха се случили при ползването на free)

---

1. Не извършва на време някои деалокации, които един деструктор би направил и поддържа постоянно ниво на по-висока консумация.

В отговор на:

---

2. Може да "уплътни" обектите и по този начин да намали шанса за cache miss
(например някой копиращи GC)

---

2. Но далеч по-вероятно е да ги раздели и така да получи cache miss в ситуация в която един C/C++ ако му е важно да не се получи ще ги задели на съседни места.

В отговор на:

---

3. Може да намали фрагментацията на паметта и по този начин да се окаже, че "дебелата GC програмка" харчи по-малко памет от "ръчно оптимизираната програмка с ръчно управление на паметта"

---

Да, това може да стане. Но само ако C/C++ програмата е написана зле. Но C/C++ програмистите рядко алокират в унес като жабарите. Ако на един добър C++ програмист му се налага да алокира множество малки обекти ще го направи с по-големи блокове и placement new, или с по-сложен RecordManager.

В отговор на:

---

4. GC програмката никога няма да прочете онзи указател от вече освободената памет, преди това заемана от една структура, и в резултат никога няма да се случи Segmentation fault (по тази причина).

---

Тая грешка не съм я виждал от години. Има много други грешки които не могат да се допуснат на жаба, защо точно тая ти хареса?

[qoute]5. Не се налага програмиста да мисли кой, кога заделя памет и кой трябва да я освободи. Това МНОГО, ама МНОГО, невероятно МНОГО, опростява писането на модулен код, което МНОГО, ....., ама МНОГО помага на програмиста да не пише БОЗАВ код.

---

И той наистина не мисли за паметта, а я приема за даденост несвършваща. И за това няма значение колко е добър gc - накрая винаги ще е изразходвал повече от човек с навици за работа с паметта.

И аз не го казвам в обида на Джава. Все пак езикът е прекрасен. Само да беше малко по-малко рестриктивен. Да кажем ако викането на gc беше по-малко пожелателно щях да съм доволен. Ще взема да науча C#, чувал съм че той бил по-читав в това отношение. Един език трябва да те оставя да си счупиш главата ако много държиш да го направиш.

Току що се сетих още един недостатък на жаба, който е фундаментален - няма деструктори. Конструкторите и деструкторите не се ползват само за памет, а и за двойки действия. А ако второто действие е да се затвори някой сокет става лошо, щото той не е подвластен на gc.

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

Java също така е и безплатна. Това също е едно от обясненията защо се предпочита Java-та.

Те тва изказване ме разби! Какво значи един език да е безплатен? Той и българският е безплатен, ма по света не е много разпространен.
А InteliJ Idea струва към $500. Програмистите взимат пари независимо на какво пишат.

П.С. 'junior' на чист английски ли се пише 'jounior'? Не съм го виждал така написано. Май напоследък всичко живо пери на американски :-)

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

В отговор на:

---

Току що се сетих още един недостатък на жаба, който е фундаментален - няма деструктори. Конструкторите и деструкторите не се ползват само за памет, а и за двойки действия. А ако второто действие е да се затвори някой сокет става лошо, щото той не е подвластен на gc.

---

Малко късно влизам в караницата, ама... Не ти трябват деструктори в Джава, за да освобождаваш ресурси. Имаш try/catch-finally. Във finally клаузата освобождаваш. По-скоро виждам липсата на finally в Ц++ като недостатък на езика.

В C# е по-добре -- имаш using блокове и IDisposable дето автоматично чистят и генерират finally частта.

В Smalltalk и Ruby виждам друг идиом -- заграждаш блок от код в блок за прихващане на изключения. Подаваш какъвто искаш блок. Вчера слушах интервю с Дон Бокс където обяснява, че гласят същият подход в новия .НЕТ за осигуряване на API за транзакции.

"В Smalltalk и Ruby виждам друг идиом -- заграждаш блок от код в блок за прихващане на изключения. Подаваш какъвто искаш блок. Вчера слушах интервю с Дон Бокс където обяснява, че гласят същият подход в новия .НЕТ за осигуряване на API за транзакции."

Нещо не разбрах Може ли по-подробно?

На gcc (примерно) какво му плащаш?!

Само да отбележа, че има аналог на деструкторите и това е метода finalize на класа Object.