OberonCore https://forum.oberoncore.ru/ |
|
Проблемы со прекращением программы... https://forum.oberoncore.ru/viewtopic.php?f=2&t=554 |
Страница 1 из 1 |
Автор: | Wlad [ Воскресенье, 08 Июль, 2007 14:48 ] |
Заголовок сообщения: | Проблемы со прекращением программы... |
Я, конечно, дико извиняюсь... Вот есть код: Код: MODULE WladTest;
IMPORT StdLog, WinApi, Kernel, Services; (**************************************************************************) CONST MAX_COUNT = 10000000; (* <<< 1 <<< *) (*MAX_COUNT = 100000000;*) (* <<< 2 <<< *) (**************************************************************************) TYPE Class = POINTER TO RECORD i : INTEGER; d : REAL; c : Class; END; (**************************************************************************) PROCEDURE Test*; VAR i : INTEGER; ticks : LONGINT; c, c1 : Class; BEGIN (*Kernel.Collect;*) c := NIL; StdLog.Ln; StdLog.String("starting loop..."); StdLog.Ln; ticks := Services.Ticks(); FOR i := 1 TO MAX_COUNT DO NEW(c1); c1.i := 100; c1.d := 1000.0; c1.c := c; c := c1; END; StdLog.String("...finished. time spent(ticks): "); StdLog.Int( Services.Ticks() - ticks ); StdLog.Ln; END Test; END #WladTest.Test #Kernel.Collect С таким значением количества итераций у меня на машине он выполняется (при раскомментированном Kernel.Collect;) где-то в пределах 953 – 1098 миллисекунд. При увеличении верхней границы цикла на порядок машина задумывается, начинает тарахтеть винтом... и с чем я совершенно согласен! Не согласен я с тем, что мне приходится перегружать снимать весь ББ с выполнения. К пресловутому Ctrl-Break ББ холоден... :о) :о( |
Автор: | Илья Ермаков [ Воскресенье, 08 Июль, 2007 16:31 ] |
Заголовок сообщения: | |
Ну да, цикл большую часть времени "просиживает" в ядре, в NewRec. А поток-"прерыватор" перед генерацией исключения в основном потоке приостанавливает его и проверяет, что он находится не в ядре. В противном случае он его возобновляет - и пытается поймать снова. Т.е. делает "пробуксовку" до тех пор, пока не поймает не в ядре. А если за секунду пробуксовок не поймает, то ничего не делает. В .NET применен альтернативный пробуксовке трюк - подмена адреса возврата. Тогда поток сам "прыгает в объятия" на выходе из ядерных процедур... |
Автор: | Wlad [ Воскресенье, 08 Июль, 2007 19:03 ] |
Заголовок сообщения: | |
Так что, "навалиться всем телом" на сочетание Ctrl-Break? В смысле - жать, пока, глядишь - повезёт, "прерыватор" не "поймает" основной поток вне ядра? :о) |
Автор: | Сергей Губанов [ Вторник, 10 Июль, 2007 15:24 ] |
Заголовок сообщения: | |
А тут и Ctrl+Break мало чем поможет. Допустим он сработал и снял выполнение этой команды. Но Блэкбокс к этому времени уже захватил себе от виндоса памяти больше чем установлено физически (имеется в виду оперативной), т.е. "залетел на жёсткий диск". Поскольку Блэкбокс ни за что на свете никогда не возвращает память обратно в виндовс, то один раз "залетев на жёсткий диск" он от туда никогда больше не выберется. Его сборщик мусора при каждом очередном проходе по всей памяти каждый раз будет "залетать на диск". То есть нормально работать Блэкбокс больше не будет - его по любому надо снимать с выполнения. Выхода два: 1) Тщательно следить за количеством установленной в компьютере оперативной памяти и НИКОГДА не пытаться захватить больше чем есть (чтобы не "залететь на диск"). Это можно сделать по "бразильской системе": в виндусе установить размер файла подкачки равным нулю. 2) Переписать сборщик мусора на компактифицирующий - перемещающий объекты в памяти и, таки, возвращающий неиспользуемую память обратно в виндовс. Я об этом писал ещё несколько лет назад в "Королевстве..." когда только познакомился с Блэкбоксом. |
Автор: | Борис Рюмшин [ Вторник, 10 Июль, 2007 15:35 ] |
Заголовок сообщения: | |
Сергей Губанов писал(а): 1) Тщательно следить за количеством установленной в компьютере оперативной памяти и НИКОГДА не пытаться захватить больше чем есть (чтобы не "залететь на диск"). Это можно сделать по "бразильской системе": в виндусе установить размер файла подкачки равным нулю.
А в случае нехватки памяти оперативно ее добавлять. ![]() |
Автор: | Борис Рюмшин [ Вторник, 10 Июль, 2007 15:37 ] |
Заголовок сообщения: | |
Борис Рюмшин писал(а): Сергей Губанов писал(а): 1) Тщательно следить за количеством установленной в компьютере оперативной памяти и НИКОГДА не пытаться захватить больше чем есть (чтобы не "залететь на диск"). Это можно сделать по "бразильской системе": в виндусе установить размер файла подкачки равным нулю. А в случае нехватки памяти оперативно ее добавлять. ![]() Кстати, не первый раз уже слышу от операционщиков (в частности от Таненбаума): А на фиг нам своп? Сейчас физической памяти много.... Сразу намного упрощается менеджер памяти в системе. |
Автор: | Trurl [ Вторник, 10 Июль, 2007 16:19 ] |
Заголовок сообщения: | |
Борис Рюмшин писал(а): А в случае нехватки памяти оперативно ее добавлять. ![]() Ну да, она же так и называется: "оперативная" ![]() Цитата: Кстати, не первый раз уже слышу от операционщиков (в частности от Таненбаума): А на фиг нам своп? Сейчас физической памяти много....
Виртуальную память многие критиковали даже, когда физической было немного. |
Автор: | Trurl [ Вторник, 10 Июль, 2007 16:24 ] |
Заголовок сообщения: | |
Сергей Губанов писал(а): Переписать сборщик мусора на компактифицирующий - перемещающий объекты в памяти и, таки, возвращающий неиспользуемую память обратно в виндовс.
Тут свои проблемы возникают. Копирующему сборщику мусора надо в два раза больше памяти. Он не может быть консервативным даже частично. А значит надо переделывать компилятор, возможны проблемы с вызовом внешних библиотек и т. п. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |