граммофон wrote: > C>Или сама JVM — с ней уже ни одна VM не сравнится. В JVM1.6 будут фичи, > C>до которых остальным VM еще как до Луны. > Если можно, отсюда поподробнее. Какие текущие фичи делают JVM особенной > и какие сделают еще более?
1) ОЧЕНЬ мощный GC с огромным количеством политик и настроек. Даже
.NETовский еще до этого уровня не дорос.
2) HotSpot-компилятор — сперли из Strongtalk'а, но довели до гораздо
более высокого уровня.
3) Оптимизации работы с памятью типа escape analysis как часть HotSpot'а.
4) Портабельность на кучу архитектур.
> Остальные пункты конечно перпендикулярны Java как таковой.
Нет. Их ортогональность — это как раз следствие развития языка. Такой
экосистемы нет больше ни для какого другого языка, даже для .NET.
> Тем более что по части IDE со Smalltalk нелегко тягаться в силу его > рефлексивной image-природы.
Да элементарно. Ни одна ST-IDE не дотягивает до IDEA, и рефлексивная
природа здесь непричем.
C>1) ОЧЕНЬ мощный GC с огромным количеством политик и настроек. Даже C>.NETовский еще до этого уровня не дорос.
GC к VM не имеет никакого отношения. Его можно поменять или вообще отключить и VM не заметит.
У JVM их вообще несколько.
Кроме того чем это в JVM более настраиваемо, чем Caml'овский GC или GС в VisualWorks?
И кстати, generational GC, которым Java и .NET так гордятся впервые был реализован в Smalltalk-системе в восьмидесятых и в Caml VM в 91 году.
Но повторю — это к VM все не относится. В принципе, я могу взять GC от JVM и прикрутить его к Smalltalk системе с незначительными правками.
C>2) HotSpot-компилятор — сперли из Strongtalk'а, но довели до гораздо C>более высокого уровня. C>3) Оптимизации работы с памятью типа escape analysis как часть HotSpot'а.
Это именно что оптимизации — к VM не относится. Оптимизировать и добавлять JIT можно в любую VM.
И кстати если вообще без оптимизаций, то Caml VM (ZAM) гораздо быстрее JVM. Это вообще была первая VM, которая без всяких оптимизаций по скорости смогла приблизиться к native коду (Ну это если не считать некоторых смецифических форт-машин).
C>4) Портабельность на кучу архитектур.
Это вообще непонятно к чему. Портабельность опять же не является свойством VM, да и не то, чтобы Java была потрабельнее большинства языков с VM.
>> Остальные пункты конечно перпендикулярны Java как таковой. C>Нет. Их ортогональность — это как раз следствие развития языка. Такой C>экосистемы нет больше ни для какого другого языка, даже для .NET. >> Тем более что по части IDE со Smalltalk нелегко тягаться в силу его >> рефлексивной image-природы. C>Да элементарно. Ни одна ST-IDE не дотягивает до IDEA, и рефлексивная C>природа здесь непричем.
После общения с VisualWorks и Dolphin Smalltalk у меня такое впечатление отсутствует.
В IDEA я разумеется тоже работал, хотя для большинства задач предпочитаю Eclipse (он удобнее когда в проекте появляются другие языки).
прежде чем понять рекурсию, необходимо понять рекурсию.
FR>Угу только Форт тяжело назвать тонкой пленкой
Если процессор выполняет фортовский код, то форт — это и есть тонкая пленка. Если бы мы не могли делать полиэтиленовую пленку (и пленку из любого другого материала) тоньше, чем, скажем, 0.5 мм, то пленка толщиной 0.6 мм для нас все равно была бы тонкой.
Здравствуйте, Cyberax, Вы писали:
>> Если можно, отсюда поподробнее. Какие текущие фичи делают JVM особенной >> и какие сделают еще более? C>1) ОЧЕНЬ мощный GC с огромным количеством политик и настроек. Даже C>.NETовский еще до этого уровня не дорос.
GC в JVM отвратителен. Оверхед на выделение маленьких объектов просто ужасен (сравниваем с GC в OCaml, а там тоже далеко не шедевр). GC для классов практически отсутствует как класс, его наличие чисто номинальное. Короче говоря — полный тормоз.
C>2) HotSpot-компилятор — сперли из Strongtalk'а, но довели до гораздо C>более высокого уровня.
Вы, пардон, в исходники hotspot смотрели? Если нет — то и не советую, потом кошмары сниться будут.
C>3) Оптимизации работы с памятью типа escape analysis как часть HotSpot'а.
MLTon им ещё догонять и догонять.
C>4) Портабельность на кучу архитектур.
Чисто номинальная. В реале же она оборачивается кучей неразрешимых проблем.
Win2k wrote: > C>Или сама JVM — с ней уже ни одна VM не сравнится. > В JVM даже хвостовых вызовов и оптимизации табличных переходов нет. А в > CLI есть. > Значит JVM никак не greatest, бывает и лучше
Хвостовые вызовы обещали в 1.6 (вместе с escape analysis'ом), насчет
табличных переходов не смотрел.
Так что JVM выигрывает по совокупности. Например, CLR не может собирать
байт-код и JIT-код сборок, а JVM спокойно может собирать ненужные классы
(что очень не вредит динамическим языкам).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: What's The Greatest Software Ever Written?
Win2k wrote: > C>1) ОЧЕНЬ мощный GC с огромным количеством политик и настроек. Даже > C>.NETовский еще до этого уровня не дорос. > GC в JVM отвратителен. Оверхед на выделение маленьких объектов просто > ужасен (сравниваем с GC в OCaml, а там тоже далеко не шедевр). GC для > классов практически отсутствует как класс, его наличие чисто > номинальное. Короче говоря — полный тормоз.
Чаго? В JVM используется two-instructions alloc — то есть выделение
маленьких объектов занимает всего ДВЕ ассемблерные инструкции (немного
больше на x86, на самом деле ). Так что не надо говорить о чем не знаете.
GC для классов как раз присутствует (отключается опцией -Xnoclassgc), а
в CLR он как раз отсутсвует как класс.
> C>2) HotSpot-компилятор — сперли из Strongtalk'а, но довели до гораздо > C>более высокого уровня. > Вы, пардон, в исходники hotspot смотрели? Если нет — то и не советую, > потом кошмары сниться будут.
Смотрел. Как и в исходники GC (когда интересно стало как они там
политики GC реализовали). Чего там страшного?
> C>3) Оптимизации работы с памятью типа escape analysis как часть HotSpot'а. > MLTon им ещё догонять и догонять.
Тут уже ML обсуждали — использование tagged-памяти для GC убивает всю
производительность.
> C>4) Портабельность на кучу архитектур. > Чисто номинальная. В реале же она оборачивается кучей неразрешимых проблем.
Ну-ка, ну-ка. Перечислите их поименно.
Здравствуйте, Cyberax, Вы писали:
>> А все-таки, интересно было бы услышать вкратце какая часть Java делает >> ее Greatest. C>Самого языка — никакая.
Ну так уж прям. Greatest его делает то, что Жава живёт не благодаря, а вопреки. Куча идиотских решений: примитивные типы, неуклюжие анонимные классы, дурацкие проверяемые исключения, теперь кривые дженерики... А гляди ж ты, живёт.
C>Java великим достижением делает прежде всего сложившаяся экоструктура из C>разных библиотек, особенно в области enterprise.
Это точно. При том, это наглядный пример того, что если есть выбор, и нет некоей всеподавляющей силы, то в конце концов вся система становится лучше. Яве повезло в двух вещах, во-первых, что она становилась на ноги во время интернет-бума, во-вторых, всё что придумали сантехники настолько криво, что сторонние библиотеки получили шанс на выживание. А тут уже сработал естественный отбор.
C>Например, IDEA — это самая лучшая из существующих IDE (Eclipse тоже C>вполне себе ничего), полных аналогов которой нет ни в ST, ни в OCaml.
Да, было бы смешно, если бы на Java нельзя было написать даже ИДЕ, и приходилось бы привлекать OCaml или ST. Хотя было и такое время.
C>Или сама JVM — с ней уже ни одна VM не сравнится. В JVM1.6 будут фичи, C>до которых остальным VM еще как до Луны.
Это кстати классно, что через 10 лет у самого-самого появилась нормальная ВМ. .Net в этом плане, безусловно, выглядит печально.
Здравствуйте, Mamut, Вы писали:
C>>Или сама JVM — с ней уже ни одна VM не сравнится. В JVM1.6 будут фичи, C>>до которых остальным VM еще как до Луны. M>Ну, не знаю. Если бы в ней были бы такие же легковесные процессы, как в Эрланге... А так — ничего особенного
Они уже были несколько раз почти реализованы Например, в Sun JVM1.3 в Линуксе использовались "зеленые потоки", а в JRockit JVM они до сих пор работают.
Ну а если появятся полноценные замыкания, то и до легких потоков уже недалеко.
Здравствуйте, Cyberax, Вы писали:
C>Так что JVM выигрывает по совокупности. Например, CLR не может собирать C>байт-код и JIT-код сборок, а JVM спокойно может собирать ненужные классы C>(что очень не вредит динамическим языкам).
.Net Compact Framework может.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: What's The Greatest Software Ever Written?
Lloyd wrote: > C>Так что JVM выигрывает по совокупности. Например, CLR не может собирать > C>байт-код и JIT-код сборок, а JVM спокойно может собирать ненужные классы > C>(что очень не вредит динамическим языкам). > .Net Compact Framework может.
А можно ссылки? Поиск в Гугле ничего не дал.
В .NET FW 2 единственное добавление — это возможность сборки мусорных
делегатов.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[11]: What's The Greatest Software Ever Written?
C>>>Или сама JVM — с ней уже ни одна VM не сравнится. В JVM1.6 будут фичи, C>>>до которых остальным VM еще как до Луны. M>>Ну, не знаю. Если бы в ней были бы такие же легковесные процессы, как в Эрланге... А так — ничего особенного C>Они уже были несколько раз почти реализованы Например, в Sun JVM1.3 в Линуксе использовались "зеленые потоки", а в JRockit JVM они до сих пор работают.
C>Ну а если появятся полноценные замыкания, то и до легких потоков уже недалеко.
In response to low memory conditions, .NET Compact Framework will
release all of the JIT’d code and return this memory to the operating
system. For planning purposes, assume that the entire JIT’d code
space is backed by physical memory while the application is the
foreground. When the program moved into the background, .NET Compact
Framework released all the JIT’d code and returns the physical memory
back to the operating system.
То есть GC не собирает мусорные классы/сборки, а просто может убирать
весь JIT-код.
GC в Sun JVM умеет собирать отдельные ненужные классы и ненужный JIT-код.
> C>В .NET FW 2 единственное добавление — это возможность сборки мусорных > C>делегатов. > Делегаты и раньше прекрасно собирались. Добавили сборку кода, > сгенеренного через DynamicMethod.
Это я и имел в виду.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[13]: What's The Greatest Software Ever Written?
Lloyd wrote: > C>GC в Sun JVM умеет собирать отдельные ненужные классы и ненужный JIT-код. > Пардон, а что конкретно вы имеете в виду, когда говорите о сборке > отдельных классов?
Вот такой пример:
public class Something
{
public Object anything;
};
....
//Здесь у нас загрузится (посредством ClassLoader'а)
//байт-код класса Something. В Java нет сборок, поэтому
//каждый класс загружается отдельно.
Something smth=new Something();
//А теперь у нас загрузится класс Anything
smth.anything=new Anything();
//Все, после этой строки класс Anything нигде больше
//не используется. Он является мусором и может быть подобран GC.
smth.anything=null;
То есть сам код классов является предметом GC. Также GC умеет собирать и
результаты HotSpot-компиляции. Это достаточно важно, так как один и тот
же байт-код при изменении условий может быть перекомпилирован в JIT-код
несколько раз (в .NET JIT-компиляция происходит только один раз).
В Java это еще очень хорошо сочетается с системой classloader'ов, про
которую еще можно долго писать. А AppDomain'ы я считаю весьма неудачной
вещью.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[15]: What's The Greatest Software Ever Written?
Здравствуйте, Cyberax, Вы писали:
C>То есть сам код классов является предметом GC. Также GC умеет собирать и C>результаты HotSpot-компиляции. Это достаточно важно, так как один и тот C>же байт-код при изменении условий может быть перекомпилирован в JIT-код C>несколько раз (в .NET JIT-компиляция происходит только один раз).
Не дам ссылок, но мне кажется, я где-то читал, что байт-код (msil) в Compact Framework-е тоже может быть выгружен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: What's The Greatest Software Ever Written?
Lloyd wrote: > C>То есть сам код классов является предметом GC. Также GC умеет собирать и > C>результаты HotSpot-компиляции. Это достаточно важно, так как один и тот > C>же байт-код при изменении условий может быть перекомпилирован в JIT-код > C>несколько раз (в .NET JIT-компиляция происходит только один раз). > Не дам ссылок, но мне кажется, я где-то читал, что байт-код (msil) в > Compact Framework-е тоже может быть выгружен.
Я читал статью разрабочтика MS в которой как раз обсуждалось почему нет
GC для классов. Там писалось, что из-за большей гранулярности в CLR
(минимальной единицей является сборка) в JIT-коде намного сложнее делать
такое же разделение, как и в Sun JVM. Поэтому сборки не собираются
мусорщиком и не могут быть выгружены.
Единственный способ сделать выгрузку кода — создать для него отдельный
AppDomain и выгружать его в случае необходимости целиком. Но вызовы
между AppDomain'ами очень медленные из-за маршаллинга.
Поэтому мне classloader'ы и нравятся больше — все загруженные классы в
Java работают в одном пространстве без всяких маршаллеров, а изоляция
получается примерно как у AD. Вдобавок, classloader'ы еще и образуют
дерево (с кучей интересных и полезных эффектов).
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[17]: What's The Greatest Software Ever Written?
Здравствуйте, Cyberax, Вы писали:
C>Я читал статью разрабочтика MS в которой как раз обсуждалось почему нет C>GC для классов. Там писалось, что из-за большей гранулярности в CLR C>(минимальной единицей является сборка) в JIT-коде намного сложнее делать C>такое же разделение, как и в Sun JVM. Поэтому сборки не собираются C>мусорщиком и не могут быть выгружены.
Например, в Sun JVM1.3 в Линуксе использовались "зеленые потоки", а в JRockit JVM они до сих пор работают.
