Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Cyberax, Вы писали:

C>>Я читал статью разрабочтика MS в которой как раз обсуждалось почему нет
C>>GC для классов. Там писалось, что из-за большей гранулярности в CLR
C>>(минимальной единицей является сборка) в JIT-коде намного сложнее делать
C>>такое же разделение, как и в Sun JVM. Поэтому сборки не собираются
C>>мусорщиком и не могут быть выгружены.

L>Ты уверен, что статья была про Compact Framework?

Т.е. ты хочешь сказать, что CLR там совершенно другой?

Здравствуйте, Курилка, Вы писали:

L>>Ты уверен, что статья была про Compact Framework?

К>Т.е. ты хочешь сказать, что CLR там совершенно другой?

Конечно другой. Например, gc, в отличие от полного фреймворка, может собирать отджиттеный код.

Lloyd wrote:
> C>Я читал статью разрабочтика MS в которой как раз обсуждалось почему нет
> C>GC для классов. Там писалось, что из-за большей гранулярности в CLR
> C>(минимальной единицей является сборка) в JIT-коде намного сложнее делать
> C>такое же разделение, как и в Sun JVM. Поэтому сборки не собираются
> C>мусорщиком и не могут быть выгружены.
> Ты уверен, что статья была про Compact Framework?
Нет, про обычный. Я не думаю, что в CF что-то сильно поменяется —
ограничения те же самые, что и в обычном FW. Поэтому и такое решение —
просто выбросить весь JIT-код в случае необходимости, так как определить
какие части кода еще нужны весьма затруднительно.

Lloyd wrote:
> L>>Ты уверен, что статья была про Compact Framework?
> К>Т.е. ты хочешь сказать, что CLR там совершенно другой?
> Конечно другой. Например, gc, в отличие от полного фреймворка, может
> собирать отджиттеный код.
Нет. GC его не собирает, JIT-код лежит в отдельной куче, которая
при необходимости просто ЦЕЛИКОМ удаляется.

Здравствуйте, Cyberax, Вы писали:

C>Нет. GC его не собирает, JIT-код лежит в отдельной куче, которая
C>при необходимости просто ЦЕЛИКОМ удаляется.

Это непринцыпиально. Важен сам факт, что отджитеный код может быть убран из памяти.

Lloyd wrote:
> C>Нет. GC его не собирает, JIT-код лежит *в отдельной куче*, которая
> C>при необходимости просто ЦЕЛИКОМ удаляется.
> Это непринцыпиально. Важен сам факт, что отджитеный код может быть убран
> из памяти.
Это принципиально.

Во-первых, сами сборки остаются в памяти (а это тоже место).

Во-вторых, для обычных десктопных приложений это будет бесполезно. В
.NET CF такой метод используется для освобождения памяти для
background-приложений, когда приложение снова активируется — код снова
JIT'ится. Для обычных приложений такое не пройдет — объем кода в них
обычно намного больше, чем в .NET CF и нет четко выделенного "спящего"
состояния.

Здравствуйте, Cyberax, Вы писали:

C>Это принципиально.

C>Во-первых, сами сборки остаются в памяти (а это тоже место).

C>Во-вторых, для обычных десктопных приложений это будет бесполезно. В
C>.NET CF такой метод используется для освобождения памяти для
C>background-приложений, когда приложение снова активируется — код снова
C>JIT'ится. Для обычных приложений такое не пройдет — объем кода в них
C>обычно намного больше, чем в .NET CF и нет четко выделенного "спящего"
C>состояния.

Так в чем все-таки принцыпиальность — то? Факт того, что память очищается от отджитеного кода, остается фактом, не так ли?

Lloyd wrote:
> C>Во-вторых, для обычных десктопных приложений это будет бесполезно. В
> C>.NET CF такой метод используется для освобождения памяти для
> C>background-приложений, когда приложение снова активируется — код снова
> C>JIT'ится. Для обычных приложений такое не пройдет — объем кода в них
> C>обычно намного больше, чем в .NET CF и нет четко выделенного "спящего"
> C>состояния.
> Так в чем все-таки принцыпиальность — то? Факт того, что память
> очищается от отджитеного кода, остается фактом, не так ли?
Принципиальной является цена этой очистки и невозможность выгрузки
байт-кода.

Многие динамические языки для CLR/JVM используют генерацию байт-кода на
лету. В этом случае байт-код будет постоянно накапливаться. У меня лично
получалось случайно сделать OOM из-за программы с метаклассами на Ruby.NET.

Здравствуйте, Cyberax, Вы писали:

C>Принципиальной является цена этой очистки и невозможность выгрузки
C>байт-кода.

отджитеный код вычищается или нет?

Lloyd wrote:
> C>Принципиальной является цена этой очистки и невозможность выгрузки
> C>байт-кода.
> отджитеный код вычищается или нет?
Нет. Он удаляется целиком.

Я точно так же могу сказать, что в С++ есть сборщик мусора — ведь если
мы прибьем процесс, то вся занимаемая им память очистится. Чем не
сборщик мусора?

Здравствуйте, Cyberax, Вы писали:

>> отджитеный код вычищается или нет?
C>Нет. Он удаляется целиком.

Вычищается или удаляется — эффект один — отсутствие отджитеного кода в памяти. Так ведь?

Lloyd wrote:
>> > отджитеный код вычищается или нет?
> C>Нет. Он удаляется целиком.
> Вычищается или удаляется — эффект один — отсутствие отджитеного кода в
> памяти. Так ведь?
Нет. Если вычищается — то имеем отсутствие НЕНУЖНОГО JIT-кода и
байт-кода в памяти. А если удаляется — то имеем отсутствие ВСЕГО JIT-кода.

Здравствуйте, Cyberax, Вы писали:

>> Вычищается или удаляется — эффект один — отсутствие отджитеного кода в
>> памяти. Так ведь?
C>Нет. Если вычищается — то имеем отсутствие НЕНУЖНОГО JIT-кода и
C>байт-кода в памяти. А если удаляется — то имеем отсутствие ВСЕГО JIT-кода.

Ок. Сцылки на такое определение в студию.

Lloyd wrote:
> C>Нет. Если вычищается — то имеем отсутствие НЕНУЖНОГО JIT-кода и
> C>байт-кода в памяти. А если удаляется — то имеем отсутствие ВСЕГО JIT-кода.
> Ок. Сцылки на такое определение в студию.
Я его только что придумал.

Мне уже надоело повторять одно и то же

Реализация CLR от MS в силу своей сути не может собирать с помощью GC
код классов. Обходы типа "удалить и пересоздать" помогают, но это только
полумеры.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Cyberax, Вы писали:

C>>Нет. GC его не собирает, JIT-код лежит в отдельной куче, которая
C>>при необходимости просто ЦЕЛИКОМ удаляется.

L>Это непринцыпиально. Важен сам факт, что отджитеный код может быть убран из памяти.

Это принципиально в том плане, что это не работа GC (garbage collectora) получается. GC должна собирать мусор, тут же описывается сбор всего — и мусора и нет.

Выглядит как обычная заплатка
То есть потребовалось хоть как-то спасать память — сделали как смогли.

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

Здравствуйте, Cyberax, Вы писали:

>> C>Нет. Если вычищается — то имеем отсутствие НЕНУЖНОГО JIT-кода и
>> C>байт-кода в памяти. А если удаляется — то имеем отсутствие ВСЕГО JIT-кода.
>> Ок. Сцылки на такое определение в студию.
C>Я его только что придумал.

C>Мне уже надоело повторять одно и то же

Я просто пытаюсь донести до тебя что удаления — это частный случай очистки. Но как-то безуспешно. Поэтому давай закроем эту тему.

Здравствуйте, MaxxK, Вы писали:

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

Ну тогда ассемблер для x86 — не ассемблер

Andrei N.Sobchuck wrote:
>> > А все-таки, интересно было бы услышать вкратце какая часть Java делает
>> > ее Greatest.
> C>Самого языка — никакая.
> Ну так уж прям. Greatest его делает то, что Жава живёт не благодаря, а
> вопреки. Куча идиотских решений: примитивные типы, неуклюжие анонимные
> классы, дурацкие проверяемые исключения, теперь кривые дженерики... А
> гляди ж ты, живёт.
Ну не знаю, по дизайн Java специально сделана примитивной почти до
минимума.

> C>Java великим достижением делает прежде всего сложившаяся экоструктура из
> C>разных библиотек, особенно в области enterprise.
> Это точно. При том, это наглядный пример того, что если есть выбор, и
> нет некоей всеподавляющей силы, то в конце концов вся система становится
> лучше. Яве повезло в двух вещах, во-первых, что она становилась на ноги
> во время интернет-бума, во-вторых, всё что придумали сантехники
> настолько криво, что сторонние библиотеки получили шанс на выживание. А
> тут уже сработал естественный отбор.
Скорее сантехники просто ничего особого не придумали Даже утиллиты
типа Ant'а были придуманы изначально вне Sun'а. И лучшие IDE тоже
писались не солнцевской братвой.

> C>Или сама JVM — с ней уже ни одна VM не сравнится. В JVM1.6 будут фичи,
> C>до которых остальным VM еще как до Луны.
> Это кстати классно, что через 10 лет у самого-самого появилась
> нормальная ВМ.
Ну лучше поздно чем никогда Хотя уже с версии 1.4 Sun JVM уже была
достаточно продвинутой.

Здравствуйте, Master Yoda, Вы писали:

MY>Понятно, на этом форуме появился еще один непризнанный гений Мы, жалкие ламеры, нервно курим в сторонке.

Что не мастер ни фига ты мне сдаётся, Йода.

W>> И ведь ни TeX, ни Metafont не помянули. DEC VMS как будто и не существовало...

MY>Аналогично

Вот зачем, зачем так явно расписываться в ламеризме?!?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ну так уж прям. Greatest его делает то, что Жава живёт не благодаря, а вопреки. Куча идиотских решений: примитивные типы, неуклюжие анонимные классы, дурацкие проверяемые исключения, теперь кривые дженерики... А гляди ж ты, живёт.

Ну тоды Visual Basic и Linux по таким критериям реально the greatest ever.