Совмещение разных объектных моделей на одном фреймворке - Философия программирования

Господа, просветите пожалуйста на такую тему:
У многих ОО-языков разные ОО-модели (то есть, понятия о том что есть объект, класс, метод/сообщение, наследование и т.п. — и следующие из этого возможности)

При этом, насколько я понимаю, платформа Java, платформа .Net имеют более-менее конкретную объектную модель, и предполагают, что все языки, работающие поверх этих платформ, должны исповедовать именно ее.

Тем не менее, на обе платформы более-менее успешно портируются разные языки, изначально для этих платформ не предназначенные (хотя бы IronPython, Jython, J#, JScript.Net, F#, та же Scala изначально работала на обеих платформах).

Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

Спасибо.

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

ЗХ>>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

V>на столько, насколько позволяет виртуальная машина.
V>а она, в общем, позволяет очень многое.

Хоцца конкретики какой-то

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

Возможно, чтобы ответить на этот вопрос, стоит начать с модификации Си++ для дотнета:
C++ --> Managed C++ --> C++/CLI.
http://en.wikipedia.org/wiki/Managed_C%2B%2B
http://en.wikipedia.org/wiki/C%2B%2B/CLI
Насколько я понимаю, среди RSDN-щиков достаточно программистов, пишущих на Managed C++ или C++/CLI.
Пусть поделятся впечатлениями, насколько им пришлось (и пришлось ли) пересмотреть подход к ООП под влиянием изменений в языке.

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

AVC>Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

AVC>Возможно, чтобы ответить на этот вопрос, стоит начать с модификации Си++ для дотнета:
AVC>C++ --> Managed C++ --> C++/CLI.
AVC>http://en.wikipedia.org/wiki/Managed_C%2B%2B
AVC>http://en.wikipedia.org/wiki/C%2B%2B/CLI
AVC>Насколько я понимаю, среди RSDN-щиков достаточно программистов, пишущих на Managed C++ или C++/CLI.
AVC>Пусть поделятся впечатлениями, насколько им пришлось (и пришлось ли) пересмотреть подход к ООП под влиянием изменений в языке.

Я не думаю, что это хороший пример. C++/CLI это все же сильно измененный язык, и изменений требовала не только объектная модель, но и работа с памятью, например. Плюс к тому, насколько я понимаю, MS вообще не ставила задачу полностью сохранить аутентичность языка. И еще плюс к тому, насколько я могу судить, объектные модель дот-нета и плюсов ничем радикально не отличаются (хотя это, может быть, и слишком сильное утверждение).

Здравствуйте, Зверёк Харьковский, Вы писали:

AVC>>Насколько я понимаю, среди RSDN-щиков достаточно программистов, пишущих на Managed C++ или C++/CLI.
AVC>>Пусть поделятся впечатлениями, насколько им пришлось (и пришлось ли) пересмотреть подход к ООП под влиянием изменений в языке.

ЗХ>Я не думаю, что это хороший пример. C++/CLI это все же сильно измененный язык, и изменений требовала не только объектная модель, но и работа с памятью, например. Плюс к тому, насколько я понимаю, MS вообще не ставила задачу полностью сохранить аутентичность языка. И еще плюс к тому, насколько я могу судить, объектные модель дот-нета и плюсов ничем радикально не отличаются (хотя это, может быть, и слишком сильное утверждение).

Собственно, я потому и предложил начать с Си++, что объектная модель у него родственная (поэтому казалось, что проще найти и понять различия между "чистым Си++" и "Си++ для дотнета" -- ограничения на множественное наследование и т.п.).
Но может быть, и правда лучше начать, наоборот, с языка, объектная модель которого принципиально отличается от дотнетовской.

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

AVC>Но может быть, и правда лучше начать...

Только чтой-то желающих "начать" не видать.

Эх

Все самому, все самому. Ничего мировому разуму доверить нельзя

Чуваки! Ну реально же интересный вопрос

Неужто никто в рамках .Net не писал на нескольких разных языках?
Или я вопрос плохо сформулировал?

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Господа, просветите пожалуйста на такую тему:
ЗХ>У многих ОО-языков разные ОО-модели (то есть, понятия о том что есть объект, класс, метод/сообщение, наследование и т.п. — и следующие из этого возможности)

ЗХ>При этом, насколько я понимаю, платформа Java, платформа .Net имеют более-менее конкретную объектную модель, и предполагают, что все языки, работающие поверх этих платформ, должны исповедовать именно ее.

Не совсем так, все что там есть сначала компилируется в СIL/Java bytecode, это соответствует assembler'у (правда типизированному и объектно-ориентированному) в обычном (нативном) случае.
Все что они (СIL/Java bytecode) позволяют (а это довольно много) то можно сделать и в языке. С другой стороны для взаимодействия с другими языками в .NET надо соблюдать CLS (см. ниже).

ЗХ>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

Возможно стоит посмотреть на Common Language Specification для .NET, чтобы понять в каких рамках надо оставаться чтобы обеспечивать прозрачное взаимодействие с другими языками.

А так .NET достаточно гибкая платформа и механизмы рефлексии (System.Reflection и System.Reflection.Emit) позволяют делать динамические вызовы и динамически создавать классы, что нужно для Python,Ruby,Smalltalk...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Андрей Хропов, Вы писали:

ЗХ>>Господа, просветите пожалуйста на такую тему:
ЗХ>>У многих ОО-языков разные ОО-модели (то есть, понятия о том что есть объект, класс, метод/сообщение, наследование и т.п. — и следующие из этого возможности)

ЗХ>>При этом, насколько я понимаю, платформа Java, платформа .Net имеют более-менее конкретную объектную модель, и предполагают, что все языки, работающие поверх этих платформ, должны исповедовать именно ее.

АХ>Не совсем так, все что там есть сначала компилируется в СIL/Java bytecode, это соответствует assembler'у (правда типизированному и объектно-ориентированному) в обычном (нативном) случае.
АХ>Все что они (СIL/Java bytecode) позволяют (а это довольно много) то можно сделать и в языке. С другой стороны для взаимодействия с другими языками в .NET надо соблюдать CLS (см. ниже).

Угу, имелся в виду именно этот аспект.

ЗХ>>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

АХ>Возможно стоит посмотреть на Common Language Specification для .NET, чтобы понять в каких рамках надо оставаться чтобы обеспечивать прозрачное взаимодействие с другими языками.

АХ>А так .NET достаточно гибкая платформа и механизмы рефлексии (System.Reflection и System.Reflection.Emit) позволяют делать динамические вызовы и динамически создавать классы, что нужно для Python,Ruby,Smalltalk...

Во! То, что надо было. Огромное спасибо.

А у тебя нет опыта/сведений, во что это выливается на практике? (то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности")

Например, насколько я понимаю, динамические вызовы/динамическое изменение кода через границы языков должно быть сильно ограничено (если Руби в объекте полученном из C#, динамически добавит метод, C# этого "не поймет"). Кроме того, видимо, должны возникать проблемы с языками, которые "приходят на платформу" со своей стандартной библиотекой (даже, точнее, не стандартной библиотекой, а своим пониманием core objects вроде Object, String, Integer и проч.)

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>А у тебя нет опыта/сведений, во что это выливается на практике?
Из .NET-языков я пишу только на C# и Nemerle, а они изначально создавались под эту платформу. На IronPython насколько я знаю запускается практически любой обычный Питоновский код (правда Psyco нет, что неудивительно). Про остальное не знаю.

ЗХ>(то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности")
Ну больше всего проблем как я понимаю с C++, поэтому и пришлось создавать такого совершенно убийственного монстра как C++/CLI

.

Ну вообще зависит от дизайна языка. Понятно что низкоуровневые языки с небезопасными фичами типа указателей (C/C++) практически невозможно сделать полностью managed. Также не слишком хорошо сочетаются с .NET не ОО-языки.

Зато хорошо портируются ОО-языки с GC

.

ЗХ>Например, насколько я понимаю, динамические вызовы/динамическое изменение кода через границы языков должно быть сильно ограничено (если Руби в объекте полученном из C#, динамически добавит метод, C# этого "не поймет").
Ну как сказать... Если мы в C# пишем программу мы должны знать имена всех методов наперед, а эти имена берутся из метаданных уже скомпилированных сборок. Или же пользоваться Reflection, тогда да, мы можем вызывать произвольные методы по именам через InvokeMethod.
Впрочем я подробно не изучал этот вопрос, обратись лучше к разработчику RubyCLR (здесь). В частности я читал что для реализации Ruby используются dynamic methods.

ЗХ> Кроме того, видимо, должны возникать проблемы с языками, которые "приходят на платформу" со своей стандартной библиотекой (даже, точнее, не стандартной библиотекой, а своим пониманием core objects вроде Object, String, Integer и проч.)
Наверное да. Впрочем внутри Integer вроде везде одинаковый (ну методы для него можно внутри языка иметь свои), а для String наверное можно cделать методы преобразовывающие его в стандартный. А вообще тебе наверное лучше напрямую посмотреть в исходниках/спросить у разработчиков IronPython или RubyCLR, например. IronPython вроде любой обычный питоновский код без изменений запускает.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Андрей Хропов, Вы писали:

ЗХ>>(то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности")
АХ>Ну больше всего проблем как я понимаю с C++, поэтому и пришлось создавать такого совершенно убийственного монстра как C++/CLI

.

АХ>Ну вообще зависит от дизайна языка. Понятно что низкоуровневые языки с небезопасными фичами типа указателей (C/C++) практически невозможно сделать полностью managed. Также не слишком хорошо сочетаются с .NET не ОО-языки.

АХ>Зато хорошо портируются ОО-языки с GC

.

Есть мнение, что ОО бывает разное (см., например, Self/Io)

То есть слова "ОО-язык" не исчерпывают всех вариаций которые могут быть. Объект моего интереса сейчас — операции с объектами, которые допустимы в одном .Net языке и недопустимы в другом, и как это работает на передаче через границы языков.

ЗХ>>Например, насколько я понимаю, динамические вызовы/динамическое изменение кода через границы языков должно быть сильно ограничено (если Руби в объекте полученном из C#, динамически добавит метод, C# этого "не поймет").
АХ>Ну как сказать... Если мы в C# пишем программу мы должны знать имена всех методов наперед, а эти имена берутся из метаданных уже скомпилированных сборок. Или же пользоваться Reflection, тогда да, мы можем вызывать произвольные методы по именам через InvokeMethod.
АХ>Впрочем я подробно не изучал этот вопрос, обратись лучше к разработчику RubyCLR (здесь). В частности я читал что для реализации Ruby используются dynamic methods.

Спасибо. Это крайне полезная информация.

ЗХ>> Кроме того, видимо, должны возникать проблемы с языками, которые "приходят на платформу" со своей стандартной библиотекой (даже, точнее, не стандартной библиотекой, а своим пониманием core objects вроде Object, String, Integer и проч.)
АХ>Наверное да. Впрочем внутри Integer вроде везде одинаковый (ну методы для него можно внутри языка иметь свои), а для String наверное можно cделать методы преобразовывающие его в стандартный. А вообще тебе наверное лучше напрямую посмотреть в исходниках/спросить у разработчиков IronPython или RubyCLR, например. IronPython вроде любой обычный питоновский код без изменений запускает.

Ну, понятно что я провожу параллельные исследования в инете и в документации соответствующих проектов. Но обращение к коллективному разуму РСДН тоже приносит свои плоды.
Например, до даденных тобой в этом и предыдущем сообщении ссылок я бы сам докопался нескоро.

В общем, спасибо за помощь!

Зверёк,

ЗХ>Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

Скажу про JVM. JVM заточена под безопасные объектно-ориентированные языки. Заточка заключается в том, что JIT надрессирован на распознавание типичных паттернов кода, которые появляются в типичной программе на Java и GC, который тоже ориентирован на типичные сценарии работы с объектами. И если новый язык чуть-чуть вылазит за эти рамки, то будут проблемы (прежде всего с перфомансом).

1. Семантика передачи объектов по ссылке (за исключением примитивов) не позволяет написать подобие обобщённых функций, работающих со значениями, (типа функции swap в C++).
2. JVM не позволяет взять адрес локальной переменной, отсюда имеем невозможность передачи параметра по ссылке. (~ ref параметр в C#).
3. Недостаточный контроль над стеком в JVM не позволяет реализовать продолжения достаточно эффективным образом (нужно в определённый момент сделать снимок стека и графа объектов, чтобы потом загрузить обратно).
4. Операция "найти всех потомков" пока не может быть реализована достаточно эффективным образом.
5. Операция "найти все инстансы класса" пока не может быть реализована достаточно эффективным образом.
6. Не поддерживается перегрузка по типу возвращаемого значения.
7. Не поддерживается горячая замена класса, затрагивающая метаданные.
8. Не поддерживается хвостовая рекурсия.
9. Тяжёлые потоки.
10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок).
11. Нет быстрых замыканий.
12. Не умеет вышивать крестиком.

Ты это хотел услышать?

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

ЗХ>>Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?

LCR>Скажу про JVM. JVM заточена под безопасные объектно-ориентированные языки. Заточка заключается в том, что JIT надрессирован на распознавание типичных паттернов кода, которые появляются в типичной программе на Java и GC, который тоже ориентирован на типичные сценарии работы с объектами. И если новый язык чуть-чуть вылазит за эти рамки, то будут проблемы (прежде всего с перфомансом).

LCR>1. Семантика передачи объектов по ссылке (за исключением примитивов) не позволяет написать подобие обобщённых функций, работающих со значениями, (типа функции swap в C++).
LCR>2. JVM не позволяет взять адрес локальной переменной, отсюда имеем невозможность передачи параметра по ссылке. (~ ref параметр в C#).
LCR>3. Недостаточный контроль над стеком в JVM не позволяет реализовать продолжения достаточно эффективным образом (нужно в определённый момент сделать снимок стека и графа объектов, чтобы потом загрузить обратно).
LCR>4. Операция "найти всех потомков" пока не может быть реализована достаточно эффективным образом.
LCR>5. Операция "найти все инстансы класса" пока не может быть реализована достаточно эффективным образом.
LCR>6. Не поддерживается перегрузка по типу возвращаемого значения.
LCR>7. Не поддерживается горячая замена класса, затрагивающая метаданные.
LCR>8. Не поддерживается хвостовая рекурсия.
LCR>9. Тяжёлые потоки.
LCR>10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок).
LCR>11. Нет быстрых замыканий.
LCR>12. Не умеет вышивать крестиком.

LCR>Ты это хотел услышать?

Честно говоря, не совсем. Это причины (т.е. свойства JVM), а мне в данный момент более интересны следствия (проблемы, возникающие при портировании других языков и взаимодействии с ними; методы решения этих проблем).

Зверёк

LCR>>Ты это хотел услышать?

ЗХ>Честно говоря, не совсем. Это причины (т.е. свойства JVM), а мне в данный момент более интересны следствия (проблемы, возникающие при портировании других языков и взаимодействии с ними; методы решения этих проблем).

Ну вот следствие (ща гадость скажу

): JRuby имеет проблемы из-за пунктов 3, 4, 5, 8, 9, 10, 11 и 12. И на данный момент, в JRuby невозможно наследовать от абстрактных классов, и производные в JRuby классы не видны в Яве (это уже из-за rt.jar).

http://jruby.codehaus.org/Limitations

PS: Я думаю эта тема интересна многим, но просто у всех отходняк после веток "MIT переходит ...", и "Пиши в Немерле".

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

LCR>Зверёк

LCR>>>Ты это хотел услышать?

ЗХ>>Честно говоря, не совсем. Это причины (т.е. свойства JVM), а мне в данный момент более интересны следствия (проблемы, возникающие при портировании других языков и взаимодействии с ними; методы решения этих проблем).

LCR>Ну вот следствие (ща гадость скажу

):
А чего "гадость"-то? Как объективная информация может быть гадостью?

LCR>JRuby имеет проблемы из-за пунктов 3, 4, 5, 8, 9, 10, 11 и 12. И на данный момент, в JRuby невозможно наследовать от абстрактных классов, и производные в JRuby классы не видны в Яве (это уже из-за rt.jar).

LCR>http://jruby.codehaus.org/Limitations

Угу, я уже покопался в факах JRuby и Jython и сделал для себя некоторые предварительные выводы. Таки в текущем состоянии это не "еще один язык для платформы" (более-менее органично интегрирующийся с прочими), а "интерпретатор, реализованный на платформе...", и взаимодействие со стандартными библиотеками происходит через "специальные" точки соприкосновения. Похоже, что для IronPython/RubyCLR ситуация должна быть близкая.
Вообще, в целом эта ситуация очень похожа на "до-платформенное" взаимодействие разных языков (через C-образный API, функции с простыми прототипами, типы данных — только "фундаментальные" вроде "целое" и "массив"), только к "фундаментальным" типам данных добавились ОО-интерфейсы. То есть получить через границы непохожих языков "нечто с методами, которые я могу вызвать" — несложно; а вот работать с этим "нечто", как с полноценным объектом (скажем, для Руби — возможность доопределить методы этого объекта) — уже увы.

LCR>PS: Я думаю эта тема интересна многим, но просто у всех отходняк после веток "MIT переходит ...", и "Пиши в Немерле".

Зверёк

LCR>>Ну вот следствие (ща гадость скажу

):
ЗХ>А чего "гадость"-то? Как объективная информация может быть гадостью?
Морально подготовить хотел

ЗХ>Вообще, в целом эта ситуация очень похожа на "до-платформенное" взаимодействие разных языков (через C-образный API, функции с простыми прототипами, типы данных — только "фундаментальные" вроде "целое" и "массив"), только к "фундаментальным" типам данных добавились ОО-интерфейсы. То есть получить через границы непохожих языков "нечто с методами, которые я могу вызвать" — несложно; а вот работать с этим "нечто", как с полноценным объектом (скажем, для Руби — возможность доопределить методы этого объекта) — уже увы.

+1, Хотя в одну сторону (Java -> X, то есть когда в X нужно заюзать Java-класс) ситуация заметно лучше, чем в другую (Java <- X, для достаточно фичастых X).

ЗХ>А у тебя нет опыта/сведений, во что это выливается на практике? (то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности")

Я бы рекомендовал глянуть на статьи вот в этом блоге:

http://blogs.msdn.com/ericlippert/

Человек занимался созданием JScript.Net, там по-моему были статьи о проблемах перевода JS под .Net.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Зверёк Харьковский, Вы писали:

АХ>>Зато хорошо портируются ОО-языки с GC

.

ЗХ>Есть мнение, что ОО бывает разное (см., например, Self/Io)

Ага — CLOS посмотри. Практически _никак_ (полностью) не ложится на ОО систему NET.

ЗХ>То есть слова "ОО-язык" не исчерпывают всех вариаций которые могут быть. Объект моего интереса сейчас — операции с объектами, которые допустимы в одном .Net языке и недопустимы в другом, и как это работает на передаче через границы языков.

Опять же, если начать _полностью_ реализовывать CLOS, то ОО система получится напрочь несовместима с NET. Ибо помимо того, что сплошь динамическое создание методов/объектов/классов/метаклассов, так ещё и вызов метода превратиться в вызов "вызывающего" метода метакласса (или "прометакласса"

) Работа с такими классами в других языках превратиться в кошмар

ЗХ>Спасибо. Это крайне полезная информация.

Здравствуйте, Андрей Хропов, Вы писали:

АХ> dynamic methods.

Кстати, интересно, что приводятся примеры, когда кодогенерация в ран-тайм приводит к увеличению скорости. А Влад до сих пор уверен в том, что таких случаев нет

http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LCR>2. JVM не позволяет взять адрес локальной переменной, отсюда имеем невозможность передачи параметра по ссылке. (~ ref параметр в C#).
Да, это серьезный -.

LCR>6. Не поддерживается перегрузка по типу возвращаемого значения.
А где она поддерживается

?

LCR>8. Не поддерживается хвостовая рекурсия.
Что значит не поддерживается? Ведь компилятор-то ее может развернуть (как делает компилятор Scala, например).

LCR>9. Тяжёлые потоки.
По-моему это зависит от реализации. Раньше в JVM вроде были green threads, но потом от них отказались.

LCR>10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок).
В смысле? Он вообще вылетит с исключением или будет интерпретировать

.

LCR>11. Нет быстрых замыканий.
А что такое быстрое замыкание? Без аллокации снимка локальных переменных для делегата в куче?

LCR>12. Не умеет вышивать крестиком.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Андрей Хропов,

LCR>>6. Не поддерживается перегрузка по типу возвращаемого значения.
АХ>А где она поддерживается

?
AndrewVK утверждает, что в CLR. Представь себе, да?

LCR>>8. Не поддерживается хвостовая рекурсия.
АХ>Что значит не поддерживается? Ведь компилятор-то ее может развернуть (как делает компилятор Scala, например).
В Эрланге поддержка хвостовой рекурсии прямо в виртуальной машине. Есть специальная инструкция: enterlocal. Так несколько эффективнее, чем если это будет делать байткод.

LCR>>9. Тяжёлые потоки.
АХ>По-моему это зависит от реализации. Раньше в JVM вроде были green threads, но потом от них отказались.
Подозреваю, что crossplatform issues.

LCR>>10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок).
АХ>В смысле? Он вообще вылетит с исключением или будет интерпретировать

.
По умолчанию, если метод превышает что-то порядка 250 инструкций, то будет интерпретироваться. К счастью, в последних версиях hotspot настраивается:

-XX:MaxInlineSize=<size>

Integer specifying maximum number of bytecode instructions in a method which gets inlined.

-XX:FreqInlineSize=<size>

Integer specifying maximum number of bytecode instructions in a frequently executed method which gets inlined.

LCR>>11. Нет быстрых замыканий.
АХ>А что такое быстрое замыкание? Без аллокации снимка локальных переменных для делегата в куче?
Да. Эмуляция замыкания в виде объекта — не очень дёшево. И если захочешь сделать ленивые вычисления — отгребёшь по полной программе.

LCR>>12. Не умеет вышивать крестиком.
АХ>

Хе-хе.

Это я к тому, что перечислять, чего машина не может, можно бесконечно. Даже возможности процессоров ограничены, а виртуальных машин — и подавно.

Lazy Cjow Rhrr wrote:
> По умолчанию, если метод превышает что-то порядка 250 инструкций, то
> будет интерпретироваться. К счастью, в последних версиях hotspot
> настраивается:
> -XX:MaxInlineSize=<size> Integer specifying maximum number of bytecode
> instructions in a method which gets inlined. -XX:FreqInlineSize=<size>
> Integer specifying maximum number of bytecode instructions in a
> frequently executed method which gets inlined.
А прочитать????

Тут говорится про inlining, а не HotSpot-компиляцию!

Posted via RSDN NNTP Server 2.1 beta

LCR>В Эрланге поддержка хвостовой рекурсии прямо в виртуальной машине. Есть специальная инструкция: enterlocal.

Поправочка. enterlocal — это вызов функции внутри того-же самого модуля (в противоположность вызову из другого модуля). Если это последняя инструкция в функции, то VM переиспользует фрейм. А компилятор Эрланга если может, оптимизирует функции к хвостовым. Вроде так.

Cyberax,

C>Тут говорится про inlining, а не HotSpot-компиляцию!

http://java.sun.com/docs/hotspot/VMOptions.html

Теперь смотрю очень внимательно. Вижу только
[code]
-XX:CompileThreshold=10000
number of method invocations/branches before
(re-)compiling [10,000 -server, 1,500 -client]
[code]
Больше ничего такого про компиляцию — параметр ненастраиваемый.

Lazy Cjow Rhrr wrote:
> C>Тут говорится про inlining, а не HotSpot-компиляцию!
> http://java.sun.com/docs/hotspot/VMOptions.html
Еще раз: ты путаешь inlining (непосредственное включение метода в код
вызываемой функции для избежания расходов на вызов функции) и
HotSpot-компиляцию (перевод байт-кодов в машинные по результатам
профилирования).

Проверить, что функции больше 256 байт-кодовых операций вполне нормально
JIT-компилируются, я думаю, ты сможешь и сам.

> Теперь смотрю очень внимательно. Вижу только
> [code]
> -XX:CompileThreshold=10000
> number of method invocations/branches before
> (re-)compiling [10,000 -server, 1,500 -client]
> [code]
> Больше ничего такого про компиляцию — параметр ненастраиваемый.
Ну еще бы — в .NET ты JITтер тоже особо много непонастраиваешь.

Posted via RSDN NNTP Server 2.1 beta

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

LCR>Андрей Хропов,

LCR>>>6. Не поддерживается перегрузка по типу возвращаемого значения.
АХ>>А где она поддерживается

?
LCR>AndrewVK утверждает, что в CLR. Представь себе, да?

В MSDN пишут, что нет:

Changing the return type of a method does not make the method unique as stated in the common language runtime specification. You cannot define overloads that vary only by return type.

LCR>>>11. Нет быстрых замыканий.
АХ>>А что такое быстрое замыкание? Без аллокации снимка локальных переменных для делегата в куче?
LCR>Да. Эмуляция замыкания в виде объекта — не очень дёшево. И если захочешь сделать ленивые вычисления — отгребёшь по полной программе.
Да, вроде компилятор OCaml славится тем что он как раз умеет вычислять когда не надо делать отдельную аллокацию.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Cyberax,

C>Проверить, что функции больше 256 байт-кодовых операций вполне нормально
C> JIT-компилируются, я думаю, ты сможешь и сам.

Что-то я последний день смотрю в книгу, вижу фигу. Предел не 250 инструкций, а 8000. Но предел есть.

Думаю, тебе стоит взглянуть на это: Compiling Scheme to JVM bytecode: a performance study

We have noticed that the current JIT compilers use a
compilation threshold. In particular, we have experimen-
tally found out that Sun's HotSpot stops compiling func-
tions for which the body is larger than 8000 JVM bytecode
instructions.

Каменты?

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

LCR>Поправочка. enterlocal — это вызов функции внутри того-же самого модуля (в противоположность вызову из другого модуля). Если это последняя инструкция в функции, то VM переиспользует фрейм.

В MSIL похожий префикс .tail есть для call-instructions:

Tail calls are similar to method jumps (jmp) in the sense that both lead to abandoning the current method, discarding its stack frame, and passing the arguments to the tail-called (jumped-at) method. However, because the arguments of a tail call have to be loaded on the evaluation stack explicitly, a tail call—unlike a jump—does not require the entire signature of the called method to match the signature of the calling method; only the return types must be the same or compatible. In short, a jump is the equivalent of loading all the current method’s arguments on the stack and invoking a tail call.

...

tail. (0xFE 0x14) Mark the following call instruction as a tail call. This instruction has no parameters and does not work with the stack. In ILAsm, this instruction—like the other prefix instructions unaligned. and volatile., discussed earlier—must be separated from the call instruction that follows it by at least a space symbol.

The difference between a jump and a tail call is that the tail call instruction pair is verifiable in principle, subject to the verifiability of the call arguments, as long as it is immediately followed by the ret instruction. As is the case with other prefix instructions, it is illegal to bypass the prefix and branch directly to the prefixed instruction, in this case, call, callvirt, or calli.

Здесь еще описание.

... << RSDN@Home 1.2.0 alpha rev. 651>>

VladGalkin,

VG>В MSIL похожий префикс .tail есть для call-instructions:

Некоторые утверждают, что он медленный.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98236

Lazy Cjow Rhrr wrote:
> Думаю, тебе стоит взглянуть на это: Compiling Scheme to JVM bytecode: a
> performance study
> <http://citeseer.ist.psu.edu/rd/30990308%2C721560%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs2/440/http:zSzzSzwww-sop.inria.frzSzoasiszSzBernard.SerpettezSzbibzSzicfp02.pdf/serpette02compiling.pdf>
> We have noticed that the current JIT compilers use a
> compilation threshold. In particular, we have experimen-
> tally found out that Sun's HotSpot stops compiling func-
> tions for which the body is larger than 8000 JVM bytecode
> instructions.
> Каменты?
Я бы не назвал это "маленьким методом"

На практике такие монстры
будут встречаться разве что при машииной генерации.

Кстати, вообще предел JVM для метода — это 65536 инструкций.
Единственный раз мне это доставило проблем, когда скомпилированый в
Java-код XSLT-преобразователь получился слишком большим.

Posted via RSDN NNTP Server 2.1 beta

Lazy Cjow Rhrr wrote:
> Думаю, тебе стоит взглянуть на это: Compiling Scheme to JVM bytecode: a
> performance study
> <http://citeseer.ist.psu.edu/rd/30990308%2C721560%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs2/440/http:zSzzSzwww-sop.inria.frzSzoasiszSzBernard.SerpettezSzbibzSzicfp02.pdf/serpette02compiling.pdf>
Кстати, сам Performance Study тоже весьма древний. Современные JVM
оптимизирую значительно лучше (switch точно стал константное время
работать — как-то тестировал).

Posted via RSDN NNTP Server 2.1 beta

Cyberax,

>> Каменты?
C>Я бы не назвал это "маленьким методом"

На практике такие монстры
C>будут встречаться разве что при машииной генерации.

Ага, компиляторы этим и занимаются. Если используется CPS, то такие мегаметоды будут появляться за нефиг делать...

C>Кстати, вообще предел JVM для метода — это 65536 инструкций.
C>Единственный раз мне это доставило проблем, когда скомпилированый в
C>Java-код XSLT-преобразователь получился слишком большим.

А что выдаёт? Ошибку при компиляции — типа "метод ххх слишком большой, разбейте на несколько"?

Lazy Cjow Rhrr wrote:
>> > Каменты?
> C>Я бы не назвал это "маленьким методом" На практике такие монстры
> C>будут встречаться разве что при машииной генерации.
> Ага, компиляторы этим и занимаются. Если используется CPS, то такие
> мегаметоды будут появляться за нефиг делать...
Ну так компилятор — он железный, может и на несколько методов разбить.

> C>Кстати, вообще предел JVM для метода — это 65536 инструкций.
> C>Единственный раз мне это доставило проблем, когда скомпилированый в
> C>Java-код XSLT-преобразователь получился слишком большим.
> А что выдаёт? Ошибку при компиляции — типа "метод ххх слишком большой,
> разбейте на несколько"?
Там хуже было — сразу формировался байт-код, который при загрузке
выдавал Error. Долго тогда разбирался из-за чего — решилось апгрейдом на
более новую версию компилятора XSLT.

Posted via RSDN NNTP Server 2.1 beta

Cyberax,

>> Думаю, тебе стоит взглянуть на это: Compiling Scheme to JVM bytecode: a
>> performance study
>> <http://citeseer.ist.psu.edu/rd/30990308%2C721560%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs2/440/http:zSzzSzwww-sop.inria.frzSzoasiszSzBernard.SerpettezSzbibzSzicfp02.pdf/serpette02compiling.pdf>
C>Кстати, сам Performance Study тоже весьма древний. Современные JVM
C>оптимизирую значительно лучше (switch точно стал константное время
C>работать — как-то тестировал).
Там не говорилось, что тормозит именно та, которую ты гонял (sun jvm?)

However, we found that some JITs are unable to produce code with a
constant complexity for the tableswitch instruction

На мой взгляд, 2002-й год, вполне современная статья. Тем более учитывая черепашью скорость развития JVM.

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

VG>>В MSIL похожий префикс .tail есть для call-instructions:

LCR>Некоторые утверждают, что он медленный.
LCR>http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98236

Поискал здесь на форуме, может кто и пробовал использовать эту инструкцию, как оказалось, действительно скорость падает

здесь

... << RSDN@Home 1.2.0 alpha rev. 668>>

Андрей,

LCR>>AndrewVK утверждает, что в CLR. Представь себе, да?

АХ>В MSDN пишут, что нет:

АХ>

АХ>Changing the return type of a method does not make the method unique as stated in the common language runtime specification. You cannot define overloads that vary only by return type.

Возможно MSDN имело ввиду требования к языкам, чтобы быть CLR-совместимыми?

Lazy Cjow Rhrr wrote:
> C>Кстати, сам Performance Study тоже весьма древний. Современные JVM
> C>оптимизирую значительно лучше (switch точно стал константное время
> C>работать — как-то тестировал).
> Там не говорилось, что тормозит именно та, которую ты гонял (sun jvm?)
> However, we found that *some JITs* are unable to produce code with a
> constant complexity for the tableswitch instruction
Ну... После того, как Sun выпустил JDK под GPL, можно считать, что особо
другие JVM и не нужны (кроме встроеных устройств, разве что).

> На мой взгляд, 2002-й год, вполне современная статья. Тем более учитывая
> черепашью скорость развития JVM.
5 лет и 3 версии JDK прошло, однако.

Posted via RSDN NNTP Server 2.1 beta

Cyberax,

C>Ну... После того, как Sun выпустил JDK под GPL, можно считать, что особо
C>другие JVM и не нужны (кроме встроеных устройств, разве что).

Да. И там будет применяться LLVM

>> На мой взгляд, 2002-й год, вполне современная статья. Тем более учитывая
>> черепашью скорость развития JVM.
C>5 лет и 3 версии JDK прошло, однако.
А ты считаешь с 1-го января 2002-го года, или с 31-го декабря?

Ладно, пусть будет статья старовата. Ок. Но я ничего лучше пока не видел. Есть варианты?

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

LCR>Возможно MSDN имело ввиду требования к языкам, чтобы быть CLR-совместимыми?
Да, естественно. В своем языке можешь что угодно делать. Но я что-то не встречал языков где это можно. Может кто более образованный знает

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

LCR>Некоторые утверждают, что он медленный.

У компилятора Немерле есть такая опция:

-Ot, -general-tail-call-opt Enable general tail call optimization (programs
are slower on MS.NET, but faster on Mono)

Это видимо как раз про эту инструкцию. Так что это зависит от реализации.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Тем не менее, на обе платформы более-менее успешно портируются разные языки, изначально для этих платформ не предназначенные

Не успешно, а с оверхедом.

Например, все языки, в которых есть массивы не могут быть безоверхедно отображены на JVM и .NET потому, что тамошние так сказать "массивы" — ссылочные.

Сколько раз здесь можно было бы избежать динамического создания массивовых-объектов, если бы .NET поддерживал настоящие (value-типовые) массивы:

public static void WriteInt32 (Writer wr, System.Int32 x)
{
    byte[] le;
    if (System.BitConverter.IsLittleEndian)
    {
        le = System.BitConverter.GetBytes(x);
    }
    else
    {
        byte[] be = System.BitConverter.GetBytes(x);
        le = new byte[4];
        le[0] = be[3]; le[1] = be[2]; le[2] = be[1]; le[3] = be[0];
    }
    wr.WriteBytes(le, 0, 4);
}

public static void ReadInt32 (Reader rd, out System.Int32 x)
{
    byte[] le = new byte[4];
    rd.ReadBytes(le, 0, 4);
    if (System.BitConverter.IsLittleEndian)
    {
        x = System.BitConverter.ToInt32(le, 0);
    }
    else
    {
        byte[] be = new byte[4];
        be[0] = le[3]; be[1] = le[2]; be[2] = le[1]; be[3] = le[0];
        x = System.BitConverter.ToInt32(be, 0);
    }
}

Что такого страшного разместить массив byte[4] на стеке? Почему .Net и JVM размещают его только динамически?..

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Что такого страшного разместить массив byte[4] на стеке? Почему .Net и JVM размещают его только динамически?..

Про region inference расказать? Или сам прочитаешь?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

СГ>>Что такого страшного разместить массив byte[4] на стеке? Почему .Net и JVM размещают его только динамически?..

WH>Про region inference расказать? Или сам прочитаешь?

Видимо, это ответ на второй вопрос — "почему только динамически".
Но первый из двух вопросов так и остался без ответа.
Все-таки: "Что такого страшного разместить массив byte[4] на стеке?"
Просто интересно.

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

AVC>Все-таки: "Что такого страшного разместить массив byte[4] на стеке?"
AVC>Просто интересно.

А зачем?
В .NET стоимость выделения памяти на стэке или в GEN0-куче — одинакова. Просто подвинуть указатель.
При этом у выделения в куче есть куча плюсов, а от выделения на стэке — только куча минусов.

Например, если кончилась GEN0 куча — запускается GC. Если кончился стэк (по дефолту — 1.5 метра — маловато) — то крах приложения. Или нет проблем с временем жизни.

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

AVC>>Все-таки: "Что такого страшного разместить массив byte[4] на стеке?"
AVC>>Просто интересно.

X>А зачем?
X>В .NET стоимость выделения памяти на стэке или в GEN0-куче — одинакова. Просто подвинуть указатель.
X>При этом у выделения в куче есть куча плюсов, а от выделения на стэке — только куча минусов.

Совсем одинакова?
Возьмем все тот же несчастый byte[4].
В одном случае мы обращаемся к его элементам через const[%sp], в другом — через дополнительный указатель.

X>Например, если кончилась GEN0 куча — запускается GC. Если кончился стэк (по дефолту — 1.5 метра — маловато) — то крах приложения. Или нет проблем с временем жизни.

А почему обязательно крах? Почему не "расширить" стек в случае его переполнения?
Например, отвести под стек большую память и скопировать в его верхнюю часть прежний стек.
Если же "нет проблем с временем жизни", то наверное это стоит все-таки побольше, чем стек. (Возможно, я не понял эту мысль?)

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

AVC>Совсем одинакова?

Да. С точностью до разницы, незаметной в микроскоп

AVC>Возьмем все тот же несчастый byte[4].
AVC>В одном случае мы обращаемся к его элементам через const[%sp], в другом — через дополнительный указатель.

Если разыменование указателя — разовая операция, то разницу никто никогда не увидит. Если сильно не разовая — то я несколько не в курсе как устроено в нутрях. Возможно, адрес массива ляжет в регистр (коих у современного процессора хватает). Или, может быть, GEN0.BASE и так лежит в регистре. Тут я не знаю

AVC>А почему обязательно крах? Почему не "расширить" стек в случае его переполнения?

Из-за <censored> рационализаторов, которые используют unsafe код, и запоминают физические адреса stackalloc массивов. В таком разрезе стэк на другое место уже не передвинуть

AVC>Если же "нет проблем с временем жизни", то наверное это стоит все-таки побольше, чем стек. (Возможно, я не понял эту мысль?)

Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame

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

AVC>>Если же "нет проблем с временем жизни", то наверное это стоит все-таки побольше, чем стек. (Возможно, я не понял эту мысль?)

X>Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame

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

AVC wrote:
> В таком случае, эта часть кучи функционирует не просто как (второй)
> стек, а каким-то более сложным путем.
> Одним перемещением указателя здесь не обойдешься.
Почему? У нас есть нулевое поколение — это сплошной непрерывный блок
памяти с guard-страницей на конце.

Когда нам нужен объект — просто отхватываем кусок от кучи. Если
наткнулись на giard-страницу, то запускается GC, который почистит
нулевое поколение, уплотнит его и даст нам указатель на его новое начало.

> Следовательно, и эффективность должна быть существенно ниже, чем у
> "простого" стека.
> (Или не так?)
Эффективность, естественно, ниже.

Posted via RSDN NNTP Server 2.1 beta

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

>> В таком случае, эта часть кучи функционирует не просто как (второй)
>> стек, а каким-то более сложным путем.
>> Одним перемещением указателя здесь не обойдешься.
C>Почему? У нас есть нулевое поколение — это сплошной непрерывный блок
C>памяти с guard-страницей на конце.

C>Когда нам нужен объект — просто отхватываем кусок от кучи. Если
C>наткнулись на giard-страницу, то запускается GC, который почистит
C>нулевое поколение, уплотнит его и даст нам указатель на его новое начало.

Механизм запуска GC теперь достаточно понятен, спасибо.
Но основной вопрос вот в чем.
Если я верно понял xvost, то он сказал следующее:
в .NET используется (в частности) механизм выделения памяти для (автоматических?) объектов
1) близкий по эффективности к стеку (хотя и не "традиционный" стек);
2) при этом обладающий некоторыми свойствами кучи, например локальный объект может "пережить" вызов метода:
X>Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame
что немного напоминает функциональные "штучки".
Меня интересует, как пункт 1 совмещается с пунктом 2.
На первый взгляд, они друг друг противоречат.
Т.е. меня интересует механизм (в общих чертах).

В свое время для одной программы реального времени я как бы "совмещал" стек и кучу: указатели на однотипные объекты складывал в стек, оттуда распределял и туда возвращал.
Но при этом:
1) объекты (для каждого стека) были одного размера;
2) не использовался сборщик мусора.

Меня просто интересует механизм выделения памяти для локальных объектов в .NET: как ему удается (и удается ли) совмещать использование кучи и эффективность.

AVC wrote:
> Но основной вопрос вот в чем.
> Если я верно понял xvost, то он сказал следующее:
> в .NET используется (в частности) механизм выделения памяти для
> (автоматических?) объектов
> 1) близкий по эффективности к стеку (хотя и не "традиционный" стек);
> 2) при этом обладающий некоторыми свойствами кучи, например локальный
> объект может "пережить" вызов метода:
Нет. В .NET есть value-типы, которые могут располагаться на стеке. Он
точно так же не может пережить возврат из стека, как и автоматический
объект.

Но в .NET добавили хитрую фичу — как только мы делаем действие, которое
может привести к тому, что у нас value-type переживет стековый фрейм —
сразу же создается boxed-копия этого value-type'а. То есть, по сути, в
куче распределяется объектная "обертка" для этого VT.

> Меня просто интересует механизм выделения памяти для локальных объектов
> в .NET: как ему удается (и удается ли) совмещать использование кучи и
> эффективность.
Как сказать...

Ручное управление памятью в сложных задачах часто может быть намного
эффективнее. А value-type'ы скорее подходят для организации больших
массивов, так как мы не расходуем зря место на заголовки объектов.

Posted via RSDN NNTP Server 2.1 beta

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

ANS>

Привоидт. По сравнению с интерпретацией и приемущественно языком.
Спроси у IT кой ценой дается эта кодогенерация в рантайме.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

X>В .NET стоимость выделения памяти на стэке или в GEN0-куче — одинакова. Просто подвинуть указатель.

Нет. Не одинакова конечно. Но разница действительно не велика. Примерно на один интерлокет-инкремент.

X>При этом у выделения в куче есть куча плюсов, а от выделения на стэке — только куча минусов.

X>Например, если кончилась GEN0 куча — запускается GC. Если кончился стэк (по дефолту — 1.5 метра — маловато) — то крах приложения. Или нет проблем с временем жизни.

Очистка стэка все же более дешевое занятие. К тому же объекты в стэке могут не иметь обязательного префикса в 12 байт. Ну, а стэк тоже можно сделать расширяемым.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

AVC>Например, отвести под стек большую память и скопировать в его верхнюю часть прежний стек.

Дотнет подразумевает, что в стэкфрэйме могут быть участки созданные нэйти-методами. Так что перенос стэка невозможен. Но можно вставлять спициальные фэйк-фрэймы и продолжать кучу в другом месте.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

X>Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame

В яве хотили сделать экскеп-анализ для выявления живущих только в рамках стэкфрэйма объектов и перемещать небольшие объекты в стек. Но что-то больше об этом слышно не было.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

AVC>Меня просто интересует механизм выделения памяти для локальных объектов в .NET: как ему удается (и удается ли) совмещать использование кучи и эффективность.

http://rsdn.ru/article/dotnet/GC.xml

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Андрей Хропов, Вы писали:

АХ>У компилятора Немерле есть такая опция:
АХ>

АХ> -Ot, -general-tail-call-opt Enable general tail call optimization (programs
АХ> are slower on MS.NET, but faster on Mono)

АХ>Это видимо как раз про эту инструкцию. Так что это зависит от реализации.

Да. Говорят на Моно tail-call работает быстро.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

AVC>>Например, отвести под стек большую память и скопировать в его верхнюю часть прежний стек.

VD>Дотнет подразумевает, что в стэкфрэйме могут быть участки созданные нэйти-методами. Так что перенос стэка невозможен. Но можно вставлять спициальные фэйк-фрэймы и продолжать кучу в другом месте.

Ага:

Alternative Stack during Overflows

By default Mono will detect whether your operating system/architecture supports an alternate stack when a stack overflow happens. If supported, Mono will run a small piece of code that will trigger a StackOverflowException in your program instead of aborting your application with a Segmentation Fault.

You can overwrite the auto detection by using the --enable-sigaltstack flag.

We only support this feature if it is auto-detected, not if you manually forced it.

(здесь)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

	От:	Зверёк Харьковский
	Дата:	05.12.06 03:22
	Оценка:

	От:	vladserge
	Дата:	05.12.06 06:07
	Оценка:

	От:	Зверёк Харьковский
	Дата:	05.12.06 06:34
	Оценка:

	От:	AVC
	Дата:	05.12.06 09:16
	Оценка:

	От:	Зверёк Харьковский
	Дата:	05.12.06 09:22
	Оценка:

	От:	Андрей Хропов
	Дата:	05.12.06 17:39
	Оценка:	42 (1)

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	06.12.06 07:49
Оценка:	36 (4)

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	06.12.06 10:23
Оценка:

	От:	Cyberax
	Дата:	06.12.06 17:16
	Оценка:	14 (1) +2

От:	rameel	https://github.com/rsdn/CodeJam
Дата:	07.12.06 13:27
Оценка:	+1

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	11.12.06 13:49
Оценка:

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	11.12.06 20:48
Оценка:

От:	VladD2	www.nemerle.org
Дата:	14.12.06 11:53
Оценка: