|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Sergey Skvortsov 2:5020/400 23 Oct 2003 14:44:38
To : Victor Wagner
Subject : Re: ModPerl vs FastPerl vs PHP
--------------------------------------------------------------------------------
SS>> щас. а кто сказал, что байткод неизменяемый?
> Кто сказал, кто сказал. Я сказал. Как автор
приложения. Я знаю, что код
> вот этого, этого и этого модулей не будет
изменяться до перезапуска
> приложения.
> А код вот этих функций - будет.
и? после этих предложений опять можно говорить,
что в общем случае байткод не изменется?
если это возражение - то силлогизма не вижу.
SS>> это вам не java какая-нить.
SS>> добавить метод к классу, загружить класс и даже
> Добавить метод к классу - поменять только
таблицу поиска методов.
> А сам код никуда не денется.
ах если бы. но нет.
например я добавляю метод как специально созданное
closure.
1. создается новая CV
2. удаляется (SvREFCNT_dec) старая CV, если была.
кода как такового нет - есть последовательной
OP-codes.
и т.о. он очень даже изменяется.
к графу OP'ов сложно применить понятие
изменится/неизменится в обычном C-смысле.
SS>> просто изменить opcod'ы на лету (хотя именно это
SS>> непросто :)) в runtime - это все делается
легко. и
SS>> соответственно меняются страницы памяти, где
SS>> выделен, скажем кусок под package stash.
SS>> и поэтому в общем случае рассчитывать на shared
SS>> code нельзя.
> Hо следует стремиться к максимизации количества
shared code и shared
> данных.
но следует отметить, что основная мысль моего
предыдущего письма была в том, что эту
максимизацию нельзя совершить каким-то
гарантируемым и работающим способом.
запретить closures, манипуляцию символьными
таблицами, не трогать B::, не пользовать "no
strict" и т.п.. короче "диета для shared code".
повторюсь, это не лечит, поскольку в пуле
свободных SV легко может быть несколько кусков
памяти, выделенных в тех страницах, в которых
лежит код.
и все вышепредложенные шаманско-аскетские способы
не сработают.
в страницу будет записано, и процессор их често
"раздвоит".
ограничивать себя в использовании возможностей
языка - это может быть частью внутренного стиля
кодирования, но с точки зрения разработчика языка
- это всего лишь частный случай.
движение к расшариванию кода есть.
напр. в iperlsys.h определена функция
PerlMemShared_malloc и иже с ней.
и во многих кусках кода где она релевантна -
используется, в надежде в child'ах/thread'ах.
и даже для структур типа AV, HV, CV и т.д. память
выделяется так, чтобы попасть в размеры страницы.
весь magic видно в malloc.c, в sv.c есть
поясниловка "Allocation and deallocation of SVs".
но вот к примеру на тривиальной struct STRUCT_SV
все затыкается - она используется для любого объекта.
и разумеется это поведение меняется в зависимости
от платформы/ключей компиляции perl'а и его версии.
если очень-очень интересно - можно задать вопрос
(поискать) в p5-porters. там 100% авторизованно и
аутентично ответят.
как резюме - методики максимизации shared code в
общем случае нет.
--
Sergey Skvortsov
mailto: skv@protey.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.ru (2:5020/400)
Вернуться к списку тем, сортированных по:
|
