Следует ли использовать Disruptor только для типов данных POD?
я имею в виду, следует ли использовать Disruptor<T> только для T, принимая такие значения, как byte[], int[], etc?
я сомневаюсь, что если мы используем T, который имеет Object ссылок в качестве переменных-членов, нам нужно new тех переменных-членов, которые будут лежать в куче. что снова приведет к промахам кеша, поскольку переменная-член может находиться в совершенно отдельной части кучи.
Итак, правильно ли я думаю, что Disruptor<T> следует использовать только для T, принадлежащих набору простых старых типов данных (POD)?
С уважением, Вимал.
ОБНОВЛЕНИЕ: Может ли кто-нибудь еще взглянуть на этот вопрос?
ОБНОВЛЕНИЕ2:
Ответить на @Триша
Привет Триша,
Привет.
я видел ссылку, которую вы упомянули.
com.lmax.ticketing.api.Message наследуется от javolution.io.Struct и состоит из элементов из javolution.io.Struct и javolution.io.Union, что делает Message совместимым между C/C++. Для любого класса, наследуемого от javolution.io.Struct/Union, структура памяти определяется порядком инициализации элементов Struct/Union и следует тем же правилам wordSize, что и структуры C/C++.
Таким образом, по сути, вы можете контролировать размещение в памяти элементов, которые вы помещаете в файл Disruptor. И все члены и подчлены Message имеют фиксированный размер, т.е. не имеют динамической памяти (java.lang.Object)
Я также считаю, что мы должны использовать такие элементы, расположение памяти которых мы можем контролировать, и у которых нет динамической памяти. И сделано это для минимизации кэш-промахов.
Предположим, если бы часть сообщения была, скажем, java.lang.String, мы не знаем, куда компилятор JIT поместил бы эту строку. и если я обращаюсь к Message.String в EventHandler, это могло привести к промаху кеша, поскольку строка может присутствовать в совершенно другом фрагменте памяти.
Я прав?
