Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Тем не менее, на обе платформы более-менее успешно портируются разные языки, изначально для этих платформ не предназначенные
Не успешно, а с оверхедом.
Например, все языки, в которых есть массивы не могут быть безоверхедно отображены на 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 размещают его только динамически?..
Re[2]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Что такого страшного разместить массив byte[4] на стеке? Почему .Net и JVM размещают его только динамически?..
Про region inference расказать? Или сам прочитаешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, WolfHound, Вы писали:
СГ>>Что такого страшного разместить массив byte[4] на стеке? Почему .Net и JVM размещают его только динамически?.. WH>Про region inference расказать? Или сам прочитаешь?
Видимо, это ответ на второй вопрос — "почему только динамически".
Но первый из двух вопросов так и остался без ответа.
Все-таки: "Что такого страшного разместить массив byte[4] на стеке?"
Просто интересно.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[4]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, AVC, Вы писали:
AVC>Все-таки: "Что такого страшного разместить массив byte[4] на стеке?" AVC>Просто интересно.
А зачем?
В .NET стоимость выделения памяти на стэке или в GEN0-куче — одинакова. Просто подвинуть указатель.
При этом у выделения в куче есть куча плюсов, а от выделения на стэке — только куча минусов.
Например, если кончилась GEN0 куча — запускается GC. Если кончился стэк (по дефолту — 1.5 метра — маловато) — то крах приложения. Или нет проблем с временем жизни.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[5]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, xvost, Вы писали:
AVC>>Все-таки: "Что такого страшного разместить массив byte[4] на стеке?" AVC>>Просто интересно.
X>А зачем? X>В .NET стоимость выделения памяти на стэке или в GEN0-куче — одинакова. Просто подвинуть указатель. X>При этом у выделения в куче есть куча плюсов, а от выделения на стэке — только куча минусов.
Совсем одинакова?
Возьмем все тот же несчастый byte[4].
В одном случае мы обращаемся к его элементам через const[%sp], в другом — через дополнительный указатель.
X>Например, если кончилась GEN0 куча — запускается GC. Если кончился стэк (по дефолту — 1.5 метра — маловато) — то крах приложения. Или нет проблем с временем жизни.
А почему обязательно крах? Почему не "расширить" стек в случае его переполнения?
Например, отвести под стек большую память и скопировать в его верхнюю часть прежний стек.
Если же "нет проблем с временем жизни", то наверное это стоит все-таки побольше, чем стек. (Возможно, я не понял эту мысль?)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[6]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, AVC, Вы писали:
AVC>Совсем одинакова?
Да. С точностью до разницы, незаметной в микроскоп
AVC>Возьмем все тот же несчастый byte[4]. AVC>В одном случае мы обращаемся к его элементам через const[%sp], в другом — через дополнительный указатель.
Если разыменование указателя — разовая операция, то разницу никто никогда не увидит. Если сильно не разовая — то я несколько не в курсе как устроено в нутрях. Возможно, адрес массива ляжет в регистр (коих у современного процессора хватает). Или, может быть, GEN0.BASE и так лежит в регистре. Тут я не знаю
AVC>А почему обязательно крах? Почему не "расширить" стек в случае его переполнения?
Из-за <censored> рационализаторов, которые используют unsafe код, и запоминают физические адреса stackalloc массивов. В таком разрезе стэк на другое место уже не передвинуть
AVC>Если же "нет проблем с временем жизни", то наверное это стоит все-таки побольше, чем стек. (Возможно, я не понял эту мысль?)
Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[7]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, xvost, Вы писали:
AVC>>Если же "нет проблем с временем жизни", то наверное это стоит все-таки побольше, чем стек. (Возможно, я не понял эту мысль?)
X>Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame
В таком случае, эта часть кучи функционирует не просто как (второй) стек, а каким-то более сложным путем.
Одним перемещением указателя здесь не обойдешься.
Следовательно, и эффективность должна быть существенно ниже, чем у "простого" стека.
(Или не так?)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[8]: Совмещение разных объектных моделей на одном фреймвор
AVC wrote: > В таком случае, эта часть кучи функционирует не просто как (второй) > стек, а каким-то более сложным путем. > Одним перемещением указателя здесь не обойдешься.
Почему? У нас есть нулевое поколение — это сплошной непрерывный блок
памяти с guard-страницей на конце.
Когда нам нужен объект — просто отхватываем кусок от кучи. Если
наткнулись на giard-страницу, то запускается GC, который почистит
нулевое поколение, уплотнит его и даст нам указатель на его новое начало.
> Следовательно, и эффективность должна быть существенно ниже, чем у > "простого" стека. > (Или не так?)
Эффективность, естественно, ниже.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[9]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Cyberax, Вы писали:
>> В таком случае, эта часть кучи функционирует не просто как (второй) >> стек, а каким-то более сложным путем. >> Одним перемещением указателя здесь не обойдешься. C>Почему? У нас есть нулевое поколение — это сплошной непрерывный блок C>памяти с guard-страницей на конце.
C>Когда нам нужен объект — просто отхватываем кусок от кучи. Если C>наткнулись на giard-страницу, то запускается GC, который почистит C>нулевое поколение, уплотнит его и даст нам указатель на его новое начало.
Механизм запуска GC теперь достаточно понятен, спасибо.
Но основной вопрос вот в чем.
Если я верно понял xvost, то он сказал следующее:
в .NET используется (в частности) механизм выделения памяти для (автоматических?) объектов
1) близкий по эффективности к стеку (хотя и не "традиционный" стек);
2) при этом обладающий некоторыми свойствами кучи, например локальный объект может "пережить" вызов метода: X>Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame
что немного напоминает функциональные "штучки".
Меня интересует, как пункт 1 совмещается с пунктом 2.
На первый взгляд, они друг друг противоречат.
Т.е. меня интересует механизм (в общих чертах).
В свое время для одной программы реального времени я как бы "совмещал" стек и кучу: указатели на однотипные объекты складывал в стек, оттуда распределял и туда возвращал.
Но при этом:
1) объекты (для каждого стека) были одного размера;
2) не использовался сборщик мусора.
Меня просто интересует механизм выделения памяти для локальных объектов в .NET: как ему удается (и удается ли) совмещать использование кучи и эффективность.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[10]: Совмещение разных объектных моделей на одном фреймво
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
Sapienti sat!
Re[5]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS> Кстати, интересно, что приводятся примеры, когда кодогенерация в ран-тайм приводит к увеличению скорости. А Влад до сих пор уверен в том, что таких случаев нет
Привоидт. По сравнению с интерпретацией и приемущественно языком.
Спроси у IT кой ценой дается эта кодогенерация в рантайме.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, xvost, Вы писали:
X>В .NET стоимость выделения памяти на стэке или в GEN0-куче — одинакова. Просто подвинуть указатель.
Нет. Не одинакова конечно. Но разница действительно не велика. Примерно на один интерлокет-инкремент.
X>При этом у выделения в куче есть куча плюсов, а от выделения на стэке — только куча минусов.
X>Например, если кончилась GEN0 куча — запускается GC. Если кончился стэк (по дефолту — 1.5 метра — маловато) — то крах приложения. Или нет проблем с временем жизни.
Очистка стэка все же более дешевое занятие. К тому же объекты в стэке могут не иметь обязательного префикса в 12 байт. Ну, а стэк тоже можно сделать расширяемым.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, AVC, Вы писали:
AVC>Например, отвести под стек большую память и скопировать в его верхнюю часть прежний стек.
Дотнет подразумевает, что в стэкфрэйме могут быть участки созданные нэйти-методами. Так что перенос стэка невозможен. Но можно вставлять спициальные фэйк-фрэймы и продолжать кучу в другом месте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, xvost, Вы писали:
X>Я имел в виду что объект в куче (любой) может жить и после выхода из метода, а массив на стэке жив пока жив соответствующий stack frame
В яве хотили сделать экскеп-анализ для выявления живущих только в рамках стэкфрэйма объектов и перемещать небольшие объекты в стек. Но что-то больше об этом слышно не было.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Совмещение разных объектных моделей на одном фреймво
Здравствуйте, AVC, Вы писали:
AVC>Меня просто интересует механизм выделения памяти для локальных объектов в .NET: как ему удается (и удается ли) совмещать использование кучи и эффективность.
Здравствуйте, 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.
