JVM internals - what does the JVM do? — Ian Rogers

[rzen]

Ё-моё, геттеры-сеттеры.
Я Java не знаю, в-принципе): нельзя из функции несколько значений вернуть.

вернуть List или HashMap или другой класс с кучей значений

Меня больше всего в джаве бесит отсутствие type inference и лямбд. А так со всем остальным можно жить.

лямбды будут в восьмой джаве, type inference (для дженериков) уже есть в седьмой джаве.

[crypto5]

Ё-моё, геттеры-сеттеры.
Я Java не знаю, в-принципе): нельзя из функции несколько значений вернуть.

вернуть List или HashMap или другой класс с кучей значений

Меня больше всего в джаве бесит отсутствие type inference и лямбд. А так со всем остальным можно жить.

лямбды будут в восьмой джаве, type inference (для дженериков) уже есть в седьмой джаве.

Это очень ограниченный type inference, в скала например оно работает для вызова метода типа:
val res = methodCall()
в джаве такого нету.

[rzen]

нету. и не будет.

[Montchik]

Не вкурсе я, ибо не использовал. Но имхо выглядит сыровато

Ну вам виднее
На самом деле какая там еще документация нужна? Показан код с lombok и показан аналогичный vanilla Java код, который генерится, с комментариями автора. Если кто-то не сможет в таком разобраться - ну так значит ему этот фреймворк и не нужен.

а когда это до ума доведут, в саму Java уже могут быть включены основные фичи.

Так вы расскажите, что там до ума доводить то нужно? Веб сайт красивее переделать? А так все хорошо работает - новые фичи добавляет, баги для новых фич оперативно фиксят.
А насчет, что в Джаву будут включены такие фичи, то ждите, ждите. Учитывая, что Java 8 выйдет только через год и никаких конкретных планов по поводу Java 9 нет (и еще не факт, что туда такое добавят), то ждать вам как минимум года 3.

Действительно, че там документировать-то! Кому надо - в исходниках разберуца, а не осилят значит фреймворк не для них.
Удачи с lombokom и прочим авангардом программизма! Она вам приходится.

[Интеррапт]

Удачи с lombokom и прочим авангардом программизма! Она вам приходится.

OMG. Да есть там документация Или вы кроме заглавной странички с видео дальше не открывали?
Ну что тут может быть непонятно?
http://projectlombok.org/features/GetterSetter.html
За 30 секунд все становится понятно - для чего и как.

или им нужно было это размазать на 20 страниц, чтобы заслужить звание хорошей документации?

[Flying Hen]

Почему бы им просто не добавить в язык необязательный оператор delete? Те кому надо будут его испльзовать, всех остальных удовлетворит GC.

[rzen]

Почему бы им просто не добавить в язык необязательный оператор delete? Те кому надо будут его испльзовать, всех остальных удовлетворит GC.

на двух стульях не усидеть, тут я с ними согласен.

[rzen]

Почему бы им просто не добавить в язык необязательный оператор delete? Те кому надо будут его испльзовать, всех остальных удовлетворит GC.

на двух стульях не усидеть, тут я с ними согласен.

[Интеррапт]

Почему бы им просто не добавить в язык необязательный оператор delete? Те кому надо будут его испльзовать, всех остальных удовлетворит GC.

Каким образом вы предлагаете это осуществить? Для этого придется, чтобы delete не только освобождал память, но и осуществлял dereference всех возможных ссылок, которые могут указывать на этот обьект. Т.е. каждый раз при вызове delete, нужно пробегаться по ссылкам и сбрасывать их. Будет ли это оптимательней по сравнению с обычным GC? Я, лично, очень сомневаюсь. Не считая того, что это сделает код очень error-prone по причине, что ссылки вдруг могут начать просто исчезать (попробуйте попрограммировать на Java cо сплошными weak references).

[Интеррапт]

Мне лично ObjectiveC-шный ARC нравится больше, чем GC

[rzen]

а мне нравился (нынче неосуществимый) вариант управления памятью от турбопаскаля, вернее в турбовижене они его реализовали. управление памятью по сути делалось так (уж не серчайте если по памяти что напутаю). объект при инициализации эвристически заказывал сколько ему потребуется памяти, получал его в куче, и больше о памяти не беспокоился. если не хватило—прога падала. но таких неугадываний случалось _исключительно_ мало. ценой такой роскоши был некоторый перерасход памяти. но это малая цена за отсутствие головной боли с управлением памятью

[Montchik]

а мне нравился (нынче неосуществимый) вариант управления памятью от турбопаскаля, вернее в турбовижене они его реализовали. управление памятью по сути делалось так (уж не серчайте если по памяти что напутаю). объект при инициализации эвристически заказывал сколько ему потребуется памяти, получал его в куче, и больше о памяти не беспокоился. если не хватило—прога падала. но таких неугадываний случалось _исключительно_ мало. ценой такой роскоши был некоторый перерасход памяти. но это малая цена за отсутствие головной боли с управлением памятью

А как объект отдавал память назад в кучу?

[dotcom]

Вобще лучше всего пока гибридный подход к памяти сделан в D. Там есть GC, есть возможность давать ему подсказки, можно исподьзовать malloc/free, если приспичит. Игровые конторы стали любить язык все больше и больше. Кармак активно вот следит за развитием языка. Недавно зарелизили OpenGL обертку. Т.е. похоже, что язык игростроителям нужен.

[Интеррапт]

Вобще лучше всего пока гибридный подход к памяти сделан в D. Там есть GC, есть возможность давать ему подсказки, можно исподьзовать malloc/free, если приспичит.

Ну так это и в C# можно делать, в unsafe контексте.

[rzen]

а мне нравился (нынче неосуществимый) вариант управления памятью от турбопаскаля, вернее в турбовижене они его реализовали. управление памятью по сути делалось так (уж не серчайте если по памяти что напутаю). объект при инициализации эвристически заказывал сколько ему потребуется памяти, получал его в куче, и больше о памяти не беспокоился. если не хватило—прога падала. но таких неугадываний случалось _исключительно_ мало. ценой такой роскоши был некоторый перерасход памяти. но это малая цена за отсутствие головной боли с управлением памятью

А как объект отдавал память назад в кучу?

ох ну ты как спросишь

куча работала как стек, запрашиваешь память, куча "растёт", перед созданием очередной коллекции объектов отмечаешь текущее состояние кучи, создаёшь нужное количество объектов не перепроверяя доступную память, когда нужда в объектах пропадает, релизишь кучу (=все объекты одним махом). аналог пула молодых объектов в JVM но без собссно GC.

поскрипев мозгами смутно припоминаю что кажется была зона памяти если куча до неё дорастала то возникало нефатальное исключение ООМ. но только в том случае если создаваемый объект не был больше чем эта зона. если больше то каюк.

[Flash-04]

если не хватило—прога падала

ну ни хренасе...

[rzen]

если не хватило—прога падала

ну ни хренасе...

времена были такие, досовские. прога падала и всю систему за собой тянула. в те времена ctrl-alt-del не вызывало окошко для логина, а ребутило систему без лишних вопросов

[Flying Hen]

Каким образом вы предлагаете это осуществить? Для этого придется, чтобы delete не только освобождал память, но и осуществлял dereference всех возможных ссылок, которые могут указывать на этот обьект. Т.е. каждый раз при вызове delete, нужно пробегаться по ссылкам и сбрасывать их. Будет ли это оптимательней по сравнению с обычным GC? Я, лично, очень сомневаюсь. Не считая того, что это сделает код очень error-prone по причине, что ссылки вдруг могут начать просто исчезать (попробуйте попрограммировать на Java cо сплошными weak references).

Например, сделать так: delete обнуляет только текущую ссылку. Если больше ссылок на объект нет, то память возвращается в пул. Если ссылки есть, то выкидывается exception. Это даст возможность грамотным девелоперам держать память под контролем, если это критично.

Если подход с авто GC не работает, то какой смысл упорствовать? А то получается как у M$, дядя Бил за вас обо всем подумал, расслабьтесь и получайте удовольствие. Агащаз.

[crypto5]

Каким образом вы предлагаете это осуществить? Для этого придется, чтобы delete не только освобождал память, но и осуществлял dereference всех возможных ссылок, которые могут указывать на этот обьект. Т.е. каждый раз при вызове delete, нужно пробегаться по ссылкам и сбрасывать их. Будет ли это оптимательней по сравнению с обычным GC? Я, лично, очень сомневаюсь. Не считая того, что это сделает код очень error-prone по причине, что ссылки вдруг могут начать просто исчезать (попробуйте попрограммировать на Java cо сплошными weak references).

Например, сделать так: delete обнуляет только текущую ссылку. Если больше ссылок на объект нет, то память возвращается в пул. Если ссылки есть, то выкидывается exception. Это даст возможность грамотным девелоперам держать память под контролем, если это критично.

Если подход с авто GC не работает, то какой смысл упорствовать? А то получается как у M$, дядя Бил за вас обо всем подумал, расслабьтесь и получайте удовольствие. Агащаз.

Если умело пользоваться escape analysis то можно тоже создавать удалять обьекты в обход ГЦ. Ну и в чем вообще проблема с ГЦ? 95%(а наверное и больше) типичных джава application с гарбадж коллектором проблем не бывает. Если проблемы возникают есть прозрачные способы его тюнит которые покрывают еще процента 4, а если вы попали в оставшийся процент, то может действительно стоит воспользоваться более системным языком(c++)?

[Интеррапт]

Например, сделать так: delete обнуляет только текущую ссылку. Если больше ссылок на объект нет, то память возвращается в пул. Если ссылки есть, то выкидывается exception. Это даст возможность грамотным девелоперам держать память под контролем, если это критично.

Круто Не хотел бы я под такой платформой программировать. Какой смысл обнулять текущую ссылку вообще? (обычно рекомендуют ссылки обнулять, чтобы код было легче отлаживать), но как раз с текущей ссылкой особых проблем нет, вы ей сделали уже delete и знаете, что ее использовать не нужно. Зачем ее обнулять? А вот со всеми остальными ссылками...

Т.е., по вашему, вот такой код должен exception выкидывать?

Code: Select all

String s1 = new String("hello world");
String s = s1;
delete s1;

До такого даже в низкоуровневых языках не додумались

Если подход с авто GC не работает, то какой смысл упорствовать? А то получается как у M$, дядя Бил за вас обо всем подумал, расслабьтесь и получайте удовольствие. Агащаз.

Почему подход с GC не работает? В большинстве случаев работает. И при чем здесь дядя Бил или Sun? Не хотите работать в managed environment никто вам не мешает из этих языков native код вызывать или даже просто писать свои программы на Asm, C, C++.

[Flash-04]

времена были такие, досовские. прога падала и всю систему за собой тянула. в те времена ctrl-alt-del не вызывало окошко для логина, а ребутило систему без лишних вопросов

вот не надо, я ведь когда-то и на "Turbo C" писал

[rzen]

времена были такие, досовские. прога падала и всю систему за собой тянула. в те времена ctrl-alt-del не вызывало окошко для логина, а ребутило систему без лишних вопросов

вот не надо, я ведь когда-то и на "Turbo C" писал

чего не надо? трёхкнопочый ребут был насущной реальностью

[Flash-04]

я к тому что принцип "failing gracefully" был известен и тогда

[rzen]

я к тому что принцип "failing gracefully" был известен и тогда

принцип то был известен, я не спорю

[dotcom]

Почему подход с GC не работает? В большинстве случаев работает. И при чем здесь дядя Бил или Sun? Не хотите работать в managed environment никто вам не мешает из этих языков native код вызывать или даже просто писать свои программы на Asm, C, C++.

Опять же, оно все хорошо только на словах, а когда дело доходит до практики, то кошмар нафиг. JNI например в ICS поменял правила игры. Падает с ошибками, что ошибки компиляции в STL покажутся сказкой. Хорошо, что сами ошибки уникальны и легко гуглятся. Но вобще вся эта дребедень с локальным и глобальным контекстами сделана ровно для того, чтобы убить любое желание писать нативный код.