OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 23 Октябрь, 2018 08:26

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
СообщениеДобавлено: Понедельник, 22 Январь, 2018 19:34 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
prospero78 писал(а):
Я правильно понимаю: взяли инструмент с исходно кривыми ручками, неудобными рабочими частями, и теперь страдая и потея пытаются исправить инструмент под давно назревшие задачи?))

В данном случае "кривость" не так уж однозначно интерпретируется. С маркетинговой точки зрения выбор Java понятен, и такие вещи, как PTC Perc Java, JamaicaVM и др. разработчики профиля "живут себе припеваючи", судя хотя бы по их "white papers" и док-ам (всё-таки, здесь не HotSpot). Устаканивание API для управления процессами, взаимодействия с оборудованием и т.д. и т.п. -- вроде нормальное явление.
Насчёт управления памятью, здесь затронутое. У каждого вендора сейчас есть свои технологии обеспечить real-time (и прочее для задач). В своих док-ах предлагают использование "регионов" в рамках RTSJ лишь для удовлетворения каких-то потребностей соответствовать предопределенным требованиям (ну или для решения специфичных задач аля спецконтейнеры данных). А вокруг (с постепенным переносом в продакшн) кроме "ручного" API наблюдаются техники как в диссере "Cooperative Memory Management ..." (по ссылке в предшествующем посте) -- статический анализ кода для автоматического определения времени жизни объектов и их взаимоотношений, распределения по иерархическим регионам (включая и стеки функций) и в динамическом хипе (а также в спец-памяти) и т.д. (плюс сопутствующее выявление эффектов типизации с последующим их учётом -- что там может изменяться, иметь или нет null, "coalesce" для переменных и пр.). В той же публикации есть акцент на любопытном моменте. При использовании принципов аллокации как в FijiVM -- выделение блоков относительно небольшими порциями ("arraylet"-ы) по некоторым правилам для снижения проблем фрагментации -- языки аля С/С++ и Паскаль-производные создают больше проблем, чем Java, т.к. они предусматривают "композицию": понимание структур как "value"-сущности и "включение" в себя других объектов (поля-структуры), что в итоге может потребовать какие-то выкрутасы фоновой "нарезки" в runtime с нарушением семантики типизации.
В общем, в данном случае стремление быть на уровне примитивного "бейсика" не выглядит кривым (да и, фактически, java используется прежде всего как байткод в качестве метаданных, т.е. сам текстовый язык Java во второстепенных ролях).
А что там будет в SCJ -- сложно сказать. Вероятно, в конечном счёте, сформируется как подмножество RTSJ (к примеру, как текущее понимание Level 0 и 1, а прочее -- как RTSJ со всей динамикой в памяти).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 22 Январь, 2018 22:42 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1067
Откуда: СССР v2.0 rc 1
Вот прочитал ключевую фразу: "стремление к примитивному бейсику". Здесь, имхо, кроется некое противоречие. Примитивность предполагает под собой некий порог простейшего, который даже слишком прост. Бейсик -- наоборот, сделан очень уж неравномерным по качеству действий и по пространству действий (если можно так сформулировать). И получается, что вроде желаем как можно проще, а значит надёжней, но не безопасными средствами (размещение данных в памяти непосредственно, вместо языковых средств, например), а с другой хочется иметь язык не имеющий ограничений на выражение текста программы, но чтобы он был точным. Т.е. какое-то странное закручивание гаек с двух сторон.
Понятно, что наработанные методики достаточно изощрённые. Кто-то что-то наверняка делал и по множествам задач в едином адресном пространстве, и автоматическое управлению памятью, и межпроцессное/межпроцессорное взаимодействие, а на практике имеем фейл практически со всеми популярными архитектурами ЦП при работе с кешем. Да такой фейл, что после патча Windows загружаться перестал. Это вот такой к счастью не частый, но всё же реальный показатель попыток сделать нечто хорошее из нечто плохого.
Все правила MISRA, авиационные и военные стандарты я бы разделил на две большие категории:
1. Физические ограничения реальных материалов.
2. Технологические ограничения, чтобы выжать максимум из реальных материалов.
С материалами мы уже ничего не сделаем. Есть и есть. А вот с технологией я вижу только два пути:
1. Навязать такие правила, чтобы шаг влево, шаг вправо -- падение по ассерту.
2. Делать устройства ооочень узкоспециализированные,с той же реакцией на шаг влево, шаг вправо.

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

RTSJ -- да, решит часть проблем. Но не решит наследуемой сложности той же виртуальной машины Java. А это сложность лежит на ещё как минимум одном уровне сложности. Уж сколько раз Java оказывалась под критическими угрозами? Думаю, это повторится ещё не раз.

Завинчивание гаек, имхо, не даст желаемого эффекта. Чтобы гайки держали прикладываемую нагрузку -- они должны быть большего диаметра с более широкой внутренней резьбой))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 23 Январь, 2018 20:26 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
prospero78 писал(а):
RTSJ -- да, решит часть проблем. Но не решит наследуемой сложности той же виртуальной машины Java. А это сложность лежит на ещё как минимум одном уровне сложности. Уж сколько раз Java оказывалась под критическими угрозами? Думаю, это повторится ещё не раз.

Видимо, PTC Perc не имеет лицензии от Oracle (если в википедии не врут) непросто так... :)

Засада ещё в другом. Глобально, фишка "write once, run anywhere" вряд ли продвинется. Даже если в рамках RTSJ/SCJ выпрямят политику работы с той же памятью, но вряд ли решения станут общими для всей Java-инфраструктуры.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB