|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Igor Sysoev 2:5020/400 23 Oct 2003 16:46:47
To : Andrey Sapozhnikov
Subject : Re: ModPerl vs FastPerl vs PHP
--------------------------------------------------------------------------------
Andrey Sapozhnikov <sapa@icb.chel.su> wrote:
> Victor Wagner wrote:
>> Konstantin Tokar <fido7@tokar.ru> wrote:
>>
>> KT> Hаверно он об этом не думает больше того, что даёт операционная система.
>>
>> Операционная система дает весьма много. Она дает честный Copy on Write.
>>
>> И то, что Perl мешает (неизменяемый) байткод с (изменяемыми) данными, не
>> давая операционной системе возможности держать страницы с байткодом
>> общими для всех процессов - проблемы перла, а не операционной системы.
>
> Полагаю, что все же это проблемы, или точнее - следствие проблем
> операционной системы. А именно стандартной функции malloc(3).
> Для того, чтобы разделить изменяемые и неизменяемые данные
> необходимо несколько пулов памяти и аллокаторы позволяющие
> возвращать данные из раздельных пулов. И "умную" free(3),
> которая бы знала к какому пулу принадлежит высвобождаемый
> блок. Можно навернуть собственный аллокатор поверх штатного,
> но это все равно криво, потому как придется запрашивать у
> системы существенно больше памяти чем надо. Во первых за счет
> лишних заголовков лишнего уровня, во вторых потому, что
> malloc(3) возвращает блоки не выровненные по границе страницы.
> Можно самим лепить аллокатор поверх brk/sbrk, но это
> не портабельно и к тому же наверняка вылезет боком при
> линковании с другими библиотеками и бинарниками. Станет
> невозможно передавать указатели на память аллокированную
> в одной части программы в другую, где она может
> быть освобождена. К тому же многие аллокаторы не любят
> сосуществовать с конкурентами (т.е. никто кроме них
> не должен трогать brk/sbrk). Вот такие пироги.
В правильных системах (например, во FreeBSD)
*) malloc() при запросах больше страницы всегда выделяет блок
на границе странице и остаток в последней странице не используется;
*) запросы меньше страницы выделяются из страниц, которые предварительно
разбиты на меньшие куски фиксированного размера, например, 2 по 2K,
4 по 1K, 8 по 512 и так далее, по-моему, до кусочков по 16 байт,
то есть, для одного байта будет выделено 16;
*) служебная информация хранится отдельно от выделенных блоков, то есть,
если просим 32K, то получаем ровно 8 страниц.
Отсюда следует, что аллокатор нескольких пулов поверх malloc()/free()
не создаст существенных расходов памяти, особенно, если он тоже будет
хранить служебную информацию отдельно от самих блоков.
--
Игорь Сысоев
http://sysoev.ru
--- ifmail v.2.15dev5
* Origin: Rambler Office news site (2:5020/400)
Вернуться к списку тем, сортированных по:
|
