Note that there are some explanatory texts on larger screens.

plurals
  1. POJava: Disruptor: Should Disruptor be used only for POD datatypes?
    text
    copied!<p>Should Disruptor be used only for POD datatypes? </p> <p>i mean should <code>Disruptor&lt;T&gt;</code> be used only for <code>T</code> taking values like <code>byte[], int[], etc</code> ?</p> <p>my doubt is that if we use <code>T</code> which has <code>Object</code> references as its member variables, we need to <code>new</code> those member variables, which will lie on heap. which will again lead to cache misses as the member variable may lie on a totally separate part of heap.</p> <p>So is my thinking correct that <code>Disruptor&lt;T&gt;</code> should be used only for <code>T</code> belonging to the set of Plain Old Datatypes (PODs)?</p> <p>Regards, VImal</p> <p>UPDATE: Can someone else please take a look at this question?</p> <p>UPDATE2:</p> <p>Reply to @Trisha</p> <p>Hi Trisha,</p> <p>Greetings.</p> <p>i saw the link you mentioned.</p> <p><code>com.lmax.ticketing.api.Message</code> is inherited from <code>javolution.io.Struct</code> and composed of elements from <code>javolution.io.Struct</code> and <code>javolution.io.Union</code> which makes <code>Message</code> to be interoperable between <code>C/C++</code> For any class inheriting from <code>javolution.io.Struct/Union</code> the memory layout is defined by the initialization order of the <code>Struct/Union</code>'s members and follows the same wordSize rules as <code>C/C++</code> structs.</p> <p>So, in essence, you have control over the memory layout of the elements you put in the <code>Disruptor</code>. And all members and sub-members of <code>Message</code> are fix sized, i.e. dont have any dynamic memory (<code>java.lang.Object</code>)</p> <p>That is exactly my point also, that we should use such elements whose memory layout we can control and dont have any dynamic memory. And this is done to minimise the cache misses. </p> <p>Suppose, if a part of the Message was, say, <code>java.lang.String</code>, we dont know where JIT compiler would have placed that String. and if i am accessing the <code>Message.String</code> in the an <code>EventHandler</code> this could have resulted in a cache miss as the String may be present in a totally different chunk of memory..</p> <p>Am i right?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload