Не знаю, а че падает то?

На стеке пытается выделить?

ну там динамический в статический пытаются положить же?

ulong[] b = new ulong[](1024*1024); вот так правильнее кажется

ну там динамический в статический пытаются положить же?

Не, а какая разница.

ну да, компилиться не должно

На стеке пытается выделить?

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

ulong[1024] buf = new ulong[1024]; вот так тоже работает, думаю тут все дело в размере. Походу при фиксированном размере это выделяется на стеке где-то

и стека не хватает

ulong[1024] buf = new ulong[1024]; вот так тоже работает, думаю тут все дело в размере. Походу при фиксированном размере это выделяется на стеке где-то

Хуже. В сегменте специальном

Сегмент данных? Чето помню смутно

Из 1 курса универа :D

ulong[1024] buf = new ulong[1024]; вот так тоже работает, думаю тут все дело в размере. Походу при фиксированном размере это выделяется на стеке где-то

важно понимать, что ulong[1024] - это статический массив, а ulong[] - это динамический массив. И это в D разные типы с существенно разной семантикой.

Сегмент данных? Чето помню смутно

Нет, другой тип. Который выделяется при загрузке в память

Нет, другой тип. Который выделяется при загрузке в память

https://en.wikipedia.org/wiki/Data_segment да вроде оно

При объявлении локальной переменной с типом статического массива, вся память под этот массив выделяется на стеке

Ладно какая блин разница. Я то совсем другое хотел проверить

Ладно какая блин разница. Я то совсем другое хотел проверить

Нет это большая разница, советую почитать про разницу между статическим и динамическим, если не знаешь. Это реально важно в D.

когда стек рекурсивно выедается тоже -11 код ошибки, кстати

Нет это большая разница, советую почитать про разницу между статическим и динамическим, если не знаешь. Это реально важно в D.

ulong[1024] buf = new ulong[1024]; тогда как работает такое? Получается ссылка на память в стеке теряется и замещается ссылкой на динамически выделенную?

а ты компилишь с @safe?

нет

ага, проверил - не влияет

судя по выводу асма - копирование

то есть како-то вариант присваивания срабатывает

ulong[1024] buf = new ulong[1024]; тогда как работает такое? Получается ссылка на память в стеке теряется и замещается ссылкой на динамически выделенную?

1 килобайт влезает в стек, а 1 мегабайт не влезает. Что тут непонятного?

копирует просто массив походу

А вообще это бессмыслица. Ты создаешь динамический массив в куче, копируешь его содержимое (нули) в статический массив на стеке, а потом GC приберет ставший ненужным выделенный на куче динамический массив

попробуй ulong[1024 * 1024] buf; скорее всего тоже упадет

А где предупреждения компилятора?

попробуй ulong[1024 * 1024] buf; скорее всего тоже упадет

А если глобально?

А где предупреждения компилятора?

о бессмысленном коде? видимо, ума у него не хватает на подобное.

А если глобально?

глобально проблем быть не должно, теоретически

попробуй ulong[1024 * 1024] buf; скорее всего тоже упадет

падает

падает

ЧТД

Вот что интересное я натворил

Шо? Опять?

Если создать буфер размером 128мб и потом создать 8 тредов, то в htop показывается в RES что процесс тратит примерно 135мб памяти. И при этом около 700-800мб VIRT. Если не создавать тредов то VIRT будет 250мб

Как-то странно он копирует в thread local storage

По идее, у тредов только стек разный

Нет в D же весь контекст из переменных копируется в каждый тред

Автоматически все становится TLS, кроме того что объявлено как shared

Автоматически все становится TLS, кроме того что объявлено как shared

COW похоже

попробуй в тредах что-нибудь изменить в массиве, RES должен приблизиться к VIRT

Насколько помню, обращение к переменным не своего треда выдавало нули.

что такое "переменные не своего треда"?

Глобалки

Да

То есть память тредов изолирована и не инициализирована.

глобалки shared или обычные?

обычные

Ну, или инициализирована дефолтом - не уточнял.

обычные у каждого треда свои

с шаред-ом запарился и ляпнул __gshared

обычные у каждого треда свои

Ну да, они же на стеке

да не

https://tour.dlang.org/tour/en/multithreading/thread-local-storage

там адресное пространство мапится на разную физ память

Ну, или второе стоит на первом)

Ну, или инициализирована дефолтом - не уточнял.

инициализируется дефолтом

но можно статическим конструктором инициализировать как угодно.

Кроме структур

Нет в D же весь контекст из переменных копируется в каждый тред

Я просто вот этого не понял.

полагаю, что изначально TLS переменные смаплены на страницу с дефолтным значением, а в случае записи в них, ремапятся на свободные. Но это не точно.

Я просто вот этого не понял.

См мою ссылку выше

В общем чето я непонял пока. Выходит что все треды обращаются к этому выделенному буферу, у них нет своего.

В общем чето я непонял пока. Выходит что все треды обращаются к этому выделенному буферу, у них нет своего.

а как именно ты создал буфер в 128мб?

ERROR: S client not available

Внутри main как писал выше

Через new

Внутри main как писал выше

где писал?

ubyte[] buf = new ubyte[1024*1024*128]

не я про main

впрочем пофиг

ты создал один раз или в каждом треде?

Один раз

мде, действительно странно, но я тут дело явно не в TLS

скорее это как-то связано с тем, что GC у всех тредов общий

Да покопаю еще

Нет, GC тут не причем. Больше похоже на какую-то особенность ОС. Я попробовал создавать массив обычным сишным маллоком core.stdc.stdlib.malloc, такая же фигня.

import core.thread; import core.time; import core.stdc.stdlib; void main() { auto var = (cast(ubyte*) malloc(128 * 1024 * 1024))[0..128 * 1024 * 1024]; foreach(size_t i, ref a; var) a = i % 256; // заполняем хламом foreach(i; 0..4) new Thread({ Thread.sleep(100.seconds); }).start(); }

А может только static переменные реально в tls? Тогда непонятно что с shared

а причем тут TLS? в моем примере TLS не используется никак

Если создать буфер размером 128мб и потом создать 8 тредов, то в htop показывается в RES что процесс тратит примерно 135мб памяти. И при этом около 700-800мб VIRT. Если не создавать тредов то VIRT будет 250мб

если дело происходит под линухом то есть pmap который покажет как используется память с точки зрения ОС

А просто вывести адрес переменной годится?

Он везде один выводится

А просто вывести адрес переменной годится?

годится для чего? для анализа заспределения памяти? нет

man pmap

man pmap

прикольная штука

короче судя по всему на каждый вновь созданный тред GC резервирует около 64 Мб памяти, которая числится виртуальной, так как не используется

Так что тайна виртуальной памяти раскрыта

import core.thread; import core.time; void main() { foreach(i; 0..4) new Thread({ Thread.sleep(100.seconds); }).start(); }

Это кушает примерно 300Мб виртуальной

А я вот походу совсем неправильно думал про TLS. Я думал что любая переменная если она объявлена как не shared будет своя собственная в каждом треде.

А я вот походу совсем неправильно думал про TLS. Я думал что любая переменная если она объявлена как не shared будет своя собственная в каждом треде.

ОМФГ

Но тогда я еще меньше понимаю чем int a; отличается от shared int a;

shared int воспринимается компилятором как тип, для него существуют ограничения

Но тогда я еще меньше понимаю чем int a; отличается от shared int a;

Смотря в каком контексте.

ты не можешь например сказать a++

в глобальном и статическом shared переменные попадают не в TLS, а вобщую память процесса