то байткод и это байткод но с другим названием

А я не говорил, что это не байткод

Перечитай

ну пиздец, я с тобой только с адвокатом буду общаться

:D

DCOM получается, только для IL only?

А что делать тем, кто не на нем?

а что там в llvm на эту тему?

В общем, мое ИМХО, насчет GC в ОС: Пихать в библиотечную составляющую ОС - то же самое, что и встроенный в ЯП. Пихать механизмы в ядро - небезопастно, непродуктивно и бессмысленно, т.к. плюсов нет

а что там в llvm на эту тему?

А что делать тем, кто сразу же в машинный код идет?

> плюсов нет Может быть ОС видя ситуацию целиком сможет более лучше GC делать

А что делать тем, кто сразу же в машинный код идет?

не вижу разницы между машинным кодом и CIL

не вижу разницы между машинным кодом и CIL

У CIL JIT-компилятор

Т.е. вполне может быть дополнительные команды, говорящии о том, что этот объект можно освободить

К слову, у V8 тоже есть свой байткод :D

Т.е. вполне может быть дополнительные команды, говорящии о том, что этот объект можно освободить

они могут быть и у ОС в качестве сисколлов

они могут быть и у ОС в качестве сисколлов

Ты посчитай, сколько по времени обойдется такими сисколлами ОС дергать и помножь на пару десятков процессов

ОС не любит, когда ее по мелочам дергают

какая разница кого дёргать ГЦ или ОС?

но у ОС видение ширше

GC дергается в пределах одного процесса, а ОС дергается переходом в ядро

дык это дёшево щас

Дороже простого вызова

И не только по времени

лет 10 назад согласился бы, щас сомневаюсь

Ну начнем с того, что как только ты добавишь сисколл, ты его высечешь в камне

Убрать его из соображений обратной совместимости будет нельзя

ну в шарпе высекли же и ничего

ну в шарпе высекли же и ничего

Где там сисколл?

убрать нельзя но добавить ещё 2-3 будет легко

Где там сисколл?

там его аналог, ведь там тоже есть GC

Да бля

Мы говорим о сисколлах в режим ядра

ну и ? ты аналогию - я тебе тоже.

у моём компьютере камней нет)

При чем тут аналогия?

а

Не

Это некорректная аналогия

Грубо говоря, в шарпе все еще можно переписать

ну ты же намекаешь на то что интерфейс работы с ГЦ - он раз и навсегда, как posix?

Если он будет сисколлами - то да

ну так вот - нет.

имеем право добавлять вызовы, по крайней мере

Убирать не можем

ну и ладно

вот кстати, хорошая аналогия - libeventы эти все

понаплодили их уже штук 5

все они по сути обёртка для штатных средств ОС которые разные

но у ОС видение ширше

Кокрастыке не ширше а намного уже, это же написано по твоей же ссылке.

ОС не знает и знать ничего не может ов нутренних структурах программы и ЯП и чего там на что ссылается и как все это посчитать.

Это понятно

Дмитрий не может, видимо, корректно описать, что он хочет сделать

Я вижу, что он хочет за счет ОС выделять мелкие фрагменты

Ну так malloc/free этим и занимается

Ну так это не ОС

Грубо говоря

Речь идет о вкомпиливании в ядро поддержки таких механизмов

> это же написано по твоей же ссылке. я ещё в процессе

> это же написано по твоей же ссылке. я ещё в процессе

Завершился бы - ОС бы уже прибрала память

Ой

Ты про другое

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

Завершился бы - ОС бы уже прибрала память

ну это та причина по которой мы найти утечку в управляемой памяти не можем

Речь идет о вкомпиливании в ядро поддержки таких механизмов

Ну да а еще в ядро можно вкомпилить Ruby, Java VM, C#/F# PHP Python Kotlin и все остальное :)

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

ничем не отличается от стандартных библиотек

ничем не отличается от стандартных библиотек

Как раз есть чем

ERROR: S client not available

чем?

ничем не отличается от стандартных библиотек

еще как отличается

Тем, что мы входим в режим ядра

попробуй убери опасный strcmp из стандартной либы

попробуй убери опасный strcmp из стандартной либы

Не используй стандартную либу :)

сискол это накладные расходы на вход в ядро

А с ядром так не выйдет

сискол это накладные расходы на вход в ядро

Я ему про то же говорю

А он

"Ну сейчас это дешево"

для отслеживания работы гц достаточно юзерспейса, как это сделано для java и хз еще каких языков со сборщиками

В общем, мое ИМХО, насчет GC в ОС: Пихать в библиотечную составляющую ОС - то же самое, что и встроенный в ЯП. Пихать механизмы в ядро - небезопастно, непродуктивно и бессмысленно, т.к. плюсов нет

Я ему про то же говорю

и я )

Денис ушел за адвокатом, видимо

для отслеживания работы гц достаточно юзерспейса, как это сделано для java и хз еще каких языков со сборщиками

неа - они отъедают большой кусок и сидят на нём вечно

неа - они отъедают большой кусок и сидят на нём вечно

Ядро сидит на святом духе

народ наоборот стремится то что было сисколлом вывести в юзерспейс https://en.wikipedia.org/wiki/VDSO

Не нравится такое явление - общая библиотек-GC

народ наоборот стремится то что было сисколлом вывести в юзерспейс https://en.wikipedia.org/wiki/VDSO

Это понятно, т.к. ядро не простой процесс, например, вытеснить его нельзя

неа - они отъедают большой кусок и сидят на нём вечно

у тебя имхо угол зрения не совпадает с моим

А с моим совпадает?

А с моим совпадает?

не знаю, возможно )

народ наоборот стремится то что было сисколлом вывести в юзерспейс https://en.wikipedia.org/wiki/VDSO

ок верю. микроядерность, все дела, забыл про это

Микроядра из другой оперы, вроде

ну общий тренд такой - всё выкинуть из ядра

Это не тренд, а, скорее, цель

А в чем проблема? Виртуальные машины сами по себе маленькие OS

они тупят-тормозят

Вот смотрю я на BEAM - эрланговская виртуальная машина - это самая натуральная OS

они тупят-тормозят

они не тупят-тормозят

равняюсь на твою аргументацию :)

А в чем проблема? Виртуальные машины сами по себе маленькие OS

О каких виртуальных машинах идет речь?