maytonТаблицы и графики - приветствуются.

Господи, и понаписал же. А теперь смотри - идеальный менеджер памяти.

Универсального идеального не может быть по определению, потому что все универсальное - это сукс.
Пример - таракан - умеет и летать, и плавать и прыгать, но в сравнении с бабочкой, водомеркой и кузнечиком - делает это плохо.


Пример из IT? оок.

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

Как только запрос будет отправлен клиенту - весь этот кусок памяти хрясь и удалется целиком, не нужно заниматься мелким анонированием вприсядку с кучей free() и прочих delete вызовов.

Аллоцирование предельно быстрое, предельно быстрое деаллоцирование.

Работает отлично только с одним типом приложения - веб. Для GUI такое не канает - там сидят долгосрочные, долгоживущие объекты, и нужно придумывать свою идеальную методику.


Базы данных? там вообще отдельно. Там есть 64-е бита в операционках, и такая штука как mmap(). Файл базы данных можно тупо зааллоцировать как readonly в память приложения (т.е. файл базы данных читается как плоский массив байтов), и вместо того, чтоб несчастный client.name по десяткам раз туда-сюда конвертировать при запросе - просто возвращать указатель на кусок памяти, фактически на кусок файла, который отображен в память. Писать в этот кусок нельзя, потому приложение с dangling pointer базу данных не разрушит.

Чтение ускоряется примерно в две-три сотни раз.


И т.д.


В результате типовое приложение веб-база данных можно разогнать в десятки раз.

Но зачем?

Кстати для GUI типов приложений ничего лучше чем ARC (automated reference counting) и Owner-Container еще не придумано (типовые реализации - Delphi, ну и все что в Cocoa/MacOSX/iOS). Там хоть время реакции на действия пользователя предсказуемо.

А использовать GC в GUI, где требуется интерактивность и гарантированное время реации - это вообще финиш.

Как порой радует Netbeans или Eclipse с их типовыми залепухами - сидишь, вбиваешь код, а оно такое жжжжжжж.... бац, на 10 секунд ушло в каматоз. Потом бац, ожило, ништяк, половина того, что ты вбивал пока оно тупило - потеряно. А так - отличные среды, дада.

maytonnojavaГосподи, и понаписал же. А теперь смотри - идеальный менеджер памяти.

Универсального идеального не может быть по определению, потому что все универсальное - это сукс.

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

я новичок? атас....

maytonnojavaПример из IT? оок.

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

Как только запрос будет отправлен клиенту - весь этот кусок памяти хрясь и удалется целиком, не нужно заниматься мелким анонированием вприсядку с кучей free() и прочих delete вызовов.

Аллоцирование предельно быстрое, предельно быстрое деаллоцирование.

Здесь если заменить очередь на stack - то ничего принципиально не меняется для обработки 1 HTTP-реквеста.

Например




это теоретически.
а практически стек сильно ограничен, если говорить про многотредовость - то порой ограничен 512 килобайтами, не разгуляешься
плюс не так секурно.

потому стек проще реализовать самому отдельно, благо это вообще не сложно - просто передвигать указатель.


плюс выделение памяти под стек vs резервирование. если резервировать через mmap(), то
реально память не выделяется, хотя можно зарезервировать хоть два гигабайта - просто операционка выкусит данный диапазон из
адресного пространства приложения, а выделение будет делать сама, по мере того, как ты будешь тыкаться указателем в блоки памяти этого диапазона.

плюс через madvise можно сингализировать операционке, что пусть суетится и выделяет уже следующий кусок

ну и большой кусок памяти имеет шанс быть выделенным через hugetlb, это дает новый класс бенефитов

maytonnojavaБазы данных? там вообще отдельно. Там есть 64-е бита в операционках, и такая штука как mmap(). Файл базы данных можно тупо зааллоцировать как readonly в память приложения (т.е. файл базы данных читается как плоский массив байтов), и вместо того, чтоб несчастный client.name по десяткам раз туда-сюда конвертировать при запросе - просто возвращать указатель на кусок памяти, фактически на кусок файла, который отображен в память. Писать в этот кусок нельзя, потому приложение с dangling pointer базу данных не разрушит.

Чтение ускоряется примерно в две-три сотни раз.

Очень странный подход. Он годный для аналитики, и анализа исторических данных
но вследствие объема (во много раз больше оперативки) я его-бы не советовал
так применять.

Но если у вас есть конкретный юзкейс где мы зачем-то должны в память
приложения (!) прогружать файл (!) баз данных причем в режиме (!) R/O
то прошу привести пример.

Ты опять видать не понял. mmap() - он не загружает файл в память приложения, с чего-бы вдруг?

он просто говорит операционке:

- Слушай, диапазон памяти с 9000 гигабайта по 9230 гигабайт - это отображение файла database.dbf

Если приложение начнет читать что-то с 9101 гигабайта - то оок, берешь подсовываешь ему то, что лежит в 101-м гигабайте файла database.dbf

при этом все эти 230 гигабайт спокойно лежат на диске, и только если приложение начнет чего-то реально читать - то только реальный режим прочитанного (с поправкой на стандартные 4096 байта страницы) и будет подкачано в память.

и выдавлено из физической памяти само, если не будет уже никому не нужно.

итого - все управление кеш памятью в базе данных ложится на операционную систему.
Oracle, к примеру, отключает буферизацию средствами OS и занимается управлением буферным кешем самостоятельно, дублируя OS
А тут ты вообще не паришься - пусть операционка сама думает, как твои данные кешировать.

А если подумает плохо - ей всегда через madvise() можно подсказать, как нужно думать правильно. Прочитать там следующие 128 килобайт заранее или нет

maytonnojavaпотому стек проще реализовать самому отдельно, благо это вообще не сложно - просто передвигать указатель.

Примерно так и работает Eden-space в Java.

Ну в Java не все сделано дурацким способом, это да. Выделяет память она в принципе разумно. И быстро.
Удаляет хреново.

Java потому и состоялась в web приложениях, что работает примерно так, как я выше описал. Только она не удаляет один большой кусок, она удаляет множество объектов нового поколения, потому не так сильно тупит.

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

maytonschwaУправление памятью на свой страх и риск aka возможность считывания byte/signed/usigned int/float/double/etc с указанной позиции в памяти это конечно хорошо, но толку мало - программы это структуры данных и работа с ними. Поэтому нужна нормальная поддержка указателей на структуры, которые расположены вне хипа с поддержкой на уровне рантайма, языка и его стандартной библиотеки.
Если честно - непонятно. Что за "структуры вне хипа" ? И что за хитрый указатель?

структуры вне java heap.

это и есть тот самый mmap() - нечто внешнее отображается в память.

ты можешь на диапазон памяти отобразить файл, а можешь отобразить туда вообще что угодно, хоть блин видеокамеру.
тебе нужно изображение в виде raw формата? да берешь просто и читаешь память с указателя такого-то по такой-то, как обычный массив байт. копирование в память при этом не происходит - данные читаются с иного устройства, чем линейки памяти.

собственно в мире C так давно уже все и работает.

никаких отдельных языковых средств не требуется - прочто чтение массива байт и вперед.

maytonnojavaТы опять видать не понял. mmap() - он не загружает файл в память приложения, с чего-бы вдруг?

он просто говорит операционке:

- Слушай, диапазон памяти с 9000 гигабайта по 9230 гигабайт - это отображение файла database.dbf

Если приложение начнет читать что-то с 9101 гигабайта - то оок, берешь подсовываешь ему то, что лежит в 101-м гигабайте файла database.dbf

Ну... про работу buffer pool всем известно. Тут вопрос в другом. Что мы получим если заберём у DBMS
ее драгоценную память кеша блоков и отдатим для приложения? Напоминаю на минуточку что мы шарим
и приложение и DBMS на 1 физическом хосте. И если вы где-то потянули одеяло - то с другой стороны
станет холодно. Напоминаю также что DBMS распоряжалась кешем блоков для операций записи.

И нет ли в этом возврата лет на 30 назад когда многопользовательских DBMS еще толком не было
а все задачи решались ПРИЛОЖЕНИЕМ которое читало dbf-файлы?

Декаденс?

чего-то холодно? в базе данных MVCC. т.е. если ты изменяешь запись, то она не перезаписывается, а добавляется в виде нового
экземпляра, и указатель памяти на старое значение client.name остается валидным, ну до тех пор, пока приложения не скажут -
знаешь, друк, а нам уже не нужны данные по состоянию на час назад, все, что час назад было уже типо обновлено, можешь
начать использовать повторно.

это совсем иное, чем .dbf, там запись была в абсолютных координатах, без всякого MVCC, и приложениям нужно было ставить
блокировки на чтение, чтоб не потерять консистентность.

А тут консистентность достигается нулевыми затратами, только по причине MVCC - потому что операция "перезаписать" заменена на операцию "добавить новую версию".

а так да, приложение и база данных должны быть на одном хосте. вернее в одном адресном пространстве, так вообще через mmap() можно и удаленные файлы, которые лежат на NFS томе или на SAN-е шарятся между нодами - никто такое не запрещат.

maytonДруг. Ты что-то путаешь MVCC - это классический набор фич как Oracle и MSSQL.
Какая замшелая безграмотность, госпаде. MVCC это просто принцип https://ru.wikipedia.org/wiki/MVCC
а то, что я описал - это давно доступно в базе данных LightningDB. https://symas.com/products/lightning-memory-mapped-database/
которая работает именно как библиотека к прилоежнию, без всяких там серверов баз данных.

тупо .lib, открываешь файл баз данных, и вперед - полный ACID и MVCC, всё по взрослому.
и да - отображение файла в память через mmap(), возможность возвращать просто указатель на запись, без копирований - она потому и адски быстра, что сделано вот так.

maytonТолько дальше ты ошибаешся:
то она не перезаписывается
Перезаписывается еще как! Это я тебе как бывш. Ораклоид говорю. И как раз для поддержки
снапшотов (курсоров) и используются ROWSCN которые проверяются при каждом чтении строки
и роутятся в UNDO-сегмент если запись была уже модифицирована.

Но ТЫ рассказываешь не этот алгоритм. Ты повествуешь примерно о том как работает Event Store!
https://geteventstore.com/ А это другая тема чувак! Совсем другая!

Oracle реализует MVCC несколько иначе, чем к примеру Firebird или вот упомянутая выше LightningDB.
Oracle перетирает данные на месте, а многоверсионность обеспечивает тем, что старые версии складывает отдельно в UNDO.

Firebird и LMDB работают иначе - они не используют UNDO вообще, а просто добавляют новую запись при каждом изменении, ну и потом отдельно повторно используют старые версии записей, пишет туда новые данные, когда в них, в старых версиях, никто не нуждается.

MVCC и там и там, сделано по-разному, но в итоге многоверсионность обеспечена, чо еще надо-то?