Подскажите, где почитать, — какие накладные расходы связаны с адресацией данных в памяти, связанные с тем, что данные могут перемещаться сборщиком мусора? В представлении С память является линейным массивом без разделов и данные не могут внезапно переместиться. Поэтому адресация данных происходит в один этап — получаем адрес и лезем по адресу. В джаве надо как-то каждый раз вычислять этот адрес, прежде, чем по нему сбегать за данными. Вот интересно — какие расходы связаны с этим?
Слышал, что сборщик мусора может переделать все адреса в памяти, но что-то с трудом верится, что он будет перемалывать всю кучу. По крайней мере это ведет к тому, что надо как-то четко отделять простые данные и ссылки или даже хранить их раздельно, что тоже ведет к доп.расходам.
Подскажите, как настроить onvif-доступ к камере, если она находится за домашним маршрутизатором во внутренней сети? Внешний адрес маршрутизатора может смениться, так как он подсоединяется по PPPoE.
В самом языке нет, но в конечном счете все работает через ассемблер. Вот и интересно какова стоимость хозяйства по сравнению с прямым доступом к памяти.
тема интересная, но надо разбираться.
у меня тоже бродили мысли, что устройство виртуальной памяти очень подходит для сбора мусора, если мусорщику дать возможность манипулировать такими вещами, как dirty bit, page fault, tlb и тп
Вот как раз тут у меня куча вопросов — неужели вся куча перемалывается? Я могу создать 100500 объектов, которые друг на друга ссылаются.
Все адреса хранятся в куче. Если просто пройтись по памяти и заменить байты на новые, то можно зацепить простые данные. Отсюда следует
, что надо как-то разделять простые данные и адреса объектов. Вот интересно, как это сделано и как происходит адресация данных.
PS Все больше ощущаю, что джава программисты не понимают вопросов, которые исходят от программистов С/С++. В понимании С виртуальная память представляет собой простой большой линейный массив и в нем нет регионов, которые декларируются в джаве. А любое разделение сопровождается доп расходами и необходимостью хранить адреса разделов и как-то постоянно складывать базу и смещение чтобы вычислить реальный адрес
Если выбираете язык для мат расчетов, то обратите внимание на то, как работает арифметика. Например, что будет при переполнии MAX_INT+1? В большинстве языков числа идут по кругу, хотя должно выдаваться исключение. Без исключений очень трудно некоторые расчеты отлаживать, так как они тихо работают неправильно. Checked arithmetics я встречаю редко — видел только в Delphi и С#. Все остальное меня разочаровывает ибо уже 2019 год на дворе, а элементарные проблемы не решены.
Вот и вопрос — как адресуются данные при таком раскладе. Что происходит, когда надо достать object.field? В С++ просто лезет по адресу в память и получает данные. А как в джаве, если адрес плавает?
Сборщик мусора может перемещать объекты. Там есть несколько областей памяти, которые соответствуют короткоживущим и долгоживущим объектам. Если данные переместились, то адрес сменился. То есть логически поразмыслив понятно, что — адрес или надо вычислять каждый раз или менять все ссылки на этот блок после каждой сборки мусора. Вот хотел бы понять, как это происходит
Проясните пожалуйста вопрос — как происходит адресация. В С++ например ссылка на данные прямая — тупо хранится адрес и по нему программа ходит за данными. А в джаве, данные объекта перемещаются в памяти, и значит нужно каждый раз вычислять этот адрес при каждом обращении к объекту.
Без априорных знаний, наверное считать невозможно. Но откуда они берутся? — довольно тонкий вопрос. Идеальные модели берутся из математики, которая оперирует предельными приближениями, которых в природе не существует, так как в природе всегда конечное число событий. А когда вы исследуете что-то абсолютно новое, когда мало данных? — все зависит от везения — насколько вы угадали априорную модель, стоящую за процессом. Потом, со временем модель получает больше или меньше подтверждений благодаря большому количеству данных. В описанном подходе модель еще имеет свободный параметр, то есть описана сразу непрерывная пачка моделей. И получаемые данные уточняют свободный параметр. Вот насколько удачно эта пачка моделей покрывает реальный процесс и зависит её качество.
Оно самое! Умножение или накопление ошибки из-за дискретизации. На большом количестве объектов вообще очень трудно это все отладить, так как надо поднимать историю и пытаться понять, какая цепочка событий к этому привела. Спецэффекты довольно редкие и проявляются при большом количестве объектов. И когда взаимодействует сотни или миллионы объектов, то надо еще вообразить, как это могло быть в пространстве. В общем я забросил этот проект изза сложностей диагностики ошибок.
Слышал, что сборщик мусора может переделать все адреса в памяти, но что-то с трудом верится, что он будет перемалывать всю кучу. По крайней мере это ведет к тому, что надо как-то четко отделять простые данные и ссылки или даже хранить их раздельно, что тоже ведет к доп.расходам.
checked{
a=b+c;
}
или
javac --checked…
есть необходимость знать моменты порчи чисел, типа
int foo = Integer.MAX_VALUE + 1; --> trow exception
у меня тоже бродили мысли, что устройство виртуальной памяти очень подходит для сбора мусора, если мусорщику дать возможность манипулировать такими вещами, как dirty bit, page fault, tlb и тп
Все адреса хранятся в куче. Если просто пройтись по памяти и заменить байты на новые, то можно зацепить простые данные. Отсюда следует
, что надо как-то разделять простые данные и адреса объектов. Вот интересно, как это сделано и как происходит адресация данных.
PS Все больше ощущаю, что джава программисты не понимают вопросов, которые исходят от программистов С/С++. В понимании С виртуальная память представляет собой простой большой линейный массив и в нем нет регионов, которые декларируются в джаве. А любое разделение сопровождается доп расходами и необходимостью хранить адреса разделов и как-то постоянно складывать базу и смещение чтобы вычислить реальный адрес
checked{
a=b+c;
}
Если выбираете язык для мат расчетов, то обратите внимание на то, как работает арифметика. Например, что будет при переполнии MAX_INT+1? В большинстве языков числа идут по кругу, хотя должно выдаваться исключение. Без исключений очень трудно некоторые расчеты отлаживать, так как они тихо работают неправильно. Checked arithmetics я встречаю редко — видел только в Delphi и С#. Все остальное меня разочаровывает ибо уже 2019 год на дворе, а элементарные проблемы не решены.
Пока осторожно публикую предпросмотр по ссылке.
https://yadi.sk/d/6bV50MRmRypduQ
Если будут вопросы или уточнения, пишите на dim3r@yandex.ru или ответом на этот комент.
Петя Иванов (5руб на карту 12343212121)