Юрий Арапов (yuridichesky) wrote,
Юрий Арапов
yuridichesky

Category:

memory management war is not over

Как-то в прошлом году ходил на Java-Day в Воронеже, который держал DataArt. Со знакомыми повидаться, на секту эту джавскую изнутри посмотреть (шутка) :-)

Послушал там доклад об устройстве GC в джаве, young generation, old generation, etc. Докладчик говорил, что GC написан исходя из гипотезы, что "достаточно много объектов не ссылаются на будущие поколения" (ну или что-то типа того, смысл в целом был в том, что хватает immutable объектов).

И вот теперь столкнулся с JVM лично, и столкновение меня сильно озадачило. В Clojure все immutable, что как-бы намекает, что GC должно быть хорошо. Если, конечно, собственно сама Clojure (или сам?) внутри не сильно mutable, что вряд-ли. А я при этом наблюдаю, что чтение 5 миллионов пар чисел из файла -- прочитал строку и распарсил два инта -- превращается а ад для GC. Имитация call-стека на куче при помощи списка -- еще больший ад при большой глубине вызовов. И еще без указания вручную, что джава может взять 2 гига под хип, вся конструкция уходила в нирвану и пилила что-то свое бесконечно долго.

И что с этим делать? Как-то специально оптимизировать размещение данных в памяти? Вот народ пишет, что ... and now the solution to problems with garbage collection is to manually manage memory? ... if memory allocations in a garbage collected language are still something to be calorie-counted, then maybe the memory management debates aren't over.

Перепишу сначала на CL, а потом на хаскеле, и посмотрю кто кого :-)
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 4 comments