Автор Тема: Oberon & GCless modules  (Прочитано 24247 раз)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Oberon & GCless modules
« : Август 09, 2012, 01:05:21 pm »
У Си (не С++) есть очень приятная особенность: если ты видишь что в юните нет инклюда #include <stdlib.h>, то и память там никто в куче (скорее всего! ибо манипуляция адресами как хочешь не запрещена) не выделяет.

В Обероне же когда смотришь на модуль не ясно использует он динамическую память (NEW) или же нет. А это иногда бывает важно. Например пишешь ты некий сервер, причем пишешь так, чтобы он работал гарантированно без сборщика мусора (и сборщик мусора для этого отключаешь возможно даже) - все либо на стеке, либо глобально. И используешь стороннюю либу, которой из самых общих соображений нет причин использовать динамическую память. А тут бац, в одном модуле внезапно кто-то использует. И все. Либо тормоза, либо память кончится.

Или же скажем программирование под мелкоконтроллеры - памяти там скажем 512 Байт (а может быть конечно и 8 Кб). Ясно что динамическая память и тем более сборщик мусора там противопоказан. Но, тем не менее, иногда хочется повторно использовать там хорошо зарекомендовавшие себя модули с больших систем. И неплохо бы изначально убедиться что они не используют динамическую память.

Я тут вижу три варианта решения проблемы:
1) Модификация языка, такая, что для использования NEW было необходимо скажем импортировать модуль MemManager.
2) Решение на уровне компилятора - при специальном ключике компилятора он отрубит сборщик мусора и динамическую память вообще, и на NEW будет ругаться плохими словами.
3) Сторонняя тулза которая прошерстит исходники даденых модулей и скажет если вдруг кто-то динамической памятью там пользуется (хм. можно просто сделать grep * NEW).

При выборе варианта, видимо, не следует смотреть на обратную совместимость с существующими компиляторами и исходниками на Обероне.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #1 : Август 09, 2012, 02:00:40 pm »
3) Сторонняя тулза которая прошерстит исходники даденых модулей и скажет если вдруг кто-то динамической памятью там пользуется (хм. можно просто сделать grep * NEW).
Вероятно, это проще всего, и поэтому никто и не делает пункты 1 и 2...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #2 : Август 09, 2012, 02:01:24 pm »
3) Сторонняя тулза которая прошерстит исходники даденых модулей и скажет если вдруг кто-то динамической памятью там пользуется (хм. можно просто сделать grep * NEW).

Лично я именно про это и подумал сразу - grep и все дела. Просто и надежно. Список всех модулей для "проверяемого" проекта все равно обязан быть на руках.

P.S. А кто мешает в C (не С++) сделать malloc без #include? ;)

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #3 : Август 09, 2012, 02:14:02 pm »
Изменять язык не нужно, достаточно модифицировать компилятор. NEW это встроенная процедура и привязать её к какому-нибудь псевдомодулю - несколько строк кода.
Вместо ключей лучше прагму, чтобы видно было.
Либо, если я правильно понял, тебе надо что-то вроде спецификации модуля, что решит и ряд других проблем

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #4 : Август 09, 2012, 02:29:16 pm »
P.S. А кто мешает в C (не С++) сделать malloc без #include? ;)
Стандарт C99. (не говоря уже о C12)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #5 : Август 09, 2012, 02:30:43 pm »
Либо, если я правильно понял, тебе надо что-то вроде спецификации модуля, что решит и ряд других проблем
Спецификация модуля (явная) это то, чего мне реально не хватает во всех этих новомодных языках, начиная от оберона и жабы и кончая Rust, Go, D.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #6 : Август 09, 2012, 02:36:23 pm »
Либо можно сделать как в Сириусе.
У нас псевдомодуль SYSTEM оставлен для совместимости, а вместо него используются модификаторы модуля
MODULE [UNSAFE, HOST, CPU, BOARD, TARGET...] Name;
Так же можно сделать и MODULE [STATIC]... и всё

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #7 : Август 09, 2012, 02:40:30 pm »
Либо можно сделать как в Сириусе.
У нас псевдомодуль SYSTEM оставлен для совместимости, а вместо него используются модификаторы модуля
MODULE [UNSAFE, HOST, CPU, BOARD, TARGET...] Name;
Так же можно сделать и MODULE [STATIC]... и всё
То есть, по сути, атрибуты модуля? Его свойства. Да, идея хороша.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #8 : Август 09, 2012, 03:04:12 pm »
Да, хотя эти атрибуты придется хранить в символьных/объектных файлах со всеми вытекающими по модификации

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #9 : Август 09, 2012, 03:09:19 pm »
Да, хотя эти атрибуты придется хранить в символьных/объектных файлах со всеми вытекающими по модификации
А зачем? В том смысле, зачем эта информация в рантайме вообще? Ну и как атрибуты одного модуля могут влиять на процесс компиляции другого модуля?
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #10 : Август 09, 2012, 03:31:54 pm »
ну как же, если у нас все модули одна статика, и статически слинкованы, то зачем нам вообще грузить/линковать модуль управления памятью

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #11 : Август 09, 2012, 03:44:07 pm »
ну как же, если у нас все модули одна статика, и статически слинкованы, то зачем нам вообще грузить/линковать модуль управления памятью
Давай не будем путать статическую и автоматическую память (а также динамическую память) со статической/динамическом компоновкой/линковкой. (я не к тому что ты путаешь, просто у тебя в предложении как-то это смешалось все, народ может войти в заблужденье)

Ясное дело что в объектнике (или sym-файле, не важно) должны быть указание на то, какие функции/процедуры оно использует и из какого модуля. Естественно если оно использует NEW, то это там должно быть прописано. И если при статической компоновке мы (компоновщик ака линкер) видим что кто-то этот NEW использует, то нужно достать из загашника модуль менеджера динамической памяти и включить его в сборку (если только нам это явным образом программер не запретил, если запретил, то ошибку нарисовать).

В случае же динамической загрузки может быть вообще все веселее - подгружать менеджер памяти можно не тогда когда загружается модуль, а когда кто-то первый раз пытается использовать NEW. В этом случае этот NEW в sym/obj может не светиться вообще.

PS. Вообще, на современном этапе развития девелоперского железа я не вижу проблемы в скорости сборки исходников на Обероне.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #12 : Август 09, 2012, 05:03:00 pm »
дак я то же самое сказал )))
но да, у меня есть такая проблема - очевидные для меня вещи я опускаю, в результате возникает недопонимание, потому как иногда это приводит к двусмысленности

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: Oberon & GCless modules
« Ответ #13 : Август 09, 2012, 05:07:15 pm »
А тут бац, в одном модуле внезапно кто-то использует. И все. Либо тормоза, либо память кончится.
Зацени размеры бедствия. В дотнете при преобразовании структуры System.DateTime из UTC в локальное время в динамической памяти создаётся мусор в виде boxed объекта System.Int32. При преобразовании структуры System.Guid в System.String тоже генерируется какой-то мусор уже не помню какой. При использовании foreach по коллекции из System.Object или по рукописной коллекции в куче генерируется мусор в виде объекта иттератора (хотя foreach по встроенным generic коллекциям (System.Collections.Generic.*) мусора не генерит). При вызове процедуры с переменным количеством аргументов генерируется мусор в виде массива этих аргументов. В частности, при конкатенации более трёх строк "aaa" + s1 + "bbb" + s2 неявно вызывается процедура с переменным количеством аргументов, то есть создаётся мусорный массив из строк. Ну и тому подобное ещё вагон и маленькая тележка...

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #14 : Август 09, 2012, 05:27:54 pm »
А тут бац, в одном модуле внезапно кто-то использует. И все. Либо тормоза, либо память кончится.
Зацени размеры бедствия. В дотнете при преобразовании структуры System.DateTime из UTC в локальное время в динамической памяти создаётся мусор в виде boxed объекта System.Int32. При преобразовании структуры System.Guid в System.String тоже генерируется какой-то мусор уже не помню какой. При использовании foreach по коллекции из System.Object или по рукописной коллекции в куче генерируется мусор в виде объекта иттератора (хотя foreach по встроенным generic коллекциям (System.Collections.Generic.*) мусора не генерит). При вызове процедуры с переменным количеством аргументов генерируется мусор в виде массива этих аргументов. В частности, при конкатенации более трёх строк "aaa" + s1 + "bbb" + s2 неявно вызывается процедура с переменным количеством аргументов, то есть создаётся мусорный массив из строк. Ну и тому подобное ещё вагон и маленькая тележка...
Угу. В java нечто аналогичное происходит. Но все это компенсируется поколенным сборщиком, то есть это неэффективность в малом, оно не расползается на большое. Впрочем, если вдруг в какой-нибудь mono тупой консервативный (или даже точный, но без поколений) сборщик мусора, то ой.

В хаскеле, кстати, по крайней мере для некого небольшого объема новейших данных (мегабайт что-ли) используется копирующий сборщик, который работает тем быстрее чем больше в этом самом мегабайте мусора :-) То есть промежуточный мусор это не есть большая проблема если вся система (не ОС, а комплекс из рантайма, компилятора и так далее) на это заточена. В случае Оберонов никто под это дело затачивать систему не собирается. Поэтому там имеет смысл пойти по другому пути :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"