Java: Disruptor: should Disruptor be used only for POD data types?

Question

Should Disruptor be used only for POD data types?

i means that Disruptor<T> is only used for T with values ​​such as byte[], int[], etc ?

I doubt that if we use T , which has Object references as its member variables, we need new member variables that will be on the heap. which again leads to cache misses, since a member variable can lie on a completely separate part of the heap.

So, do I believe that Disruptor<T> should only be used for T , which belongs to many simple static data types (PODs)?

Regards, Vimal

UPDATE: Can anyone else take a look at this question?

UPDATE2:

Reply to @Trisha

Hi Trisha,

Hey.

I saw the link you mentioned.

com.lmax.ticketing.api.Message inherits from javolution.io.Struct and consists of elements from javolution.io.Struct and javolution.io.Union , which allows Message interact between C/C++ for any class that inherits from javolution.io.Struct/Union , the memory layout is determined by the initialization order of the Struct/Union members and follows the same wordSize rules as C/C++ structs.

So, in essence, you have control over the memory layout of the elements that you put in Disruptor . And all members and subgroups of Message have a fixed size, that is, they do not have dynamic memory ( java.lang.Object )

In the same way, I want to say that we should use elements whose memory format we can control and not have any dynamic memory. And this is done to minimize cache misses.

Suppose if the message part was, say, java.lang.String , we don’t know where the JIT compiler would place this String. and if I access Message.String in EventHandler , this could lead to a cache miss, since String may be present in a completely different part of memory.

I'm right?

Answer 1

You can use any type of object as an event, for example, see the code https://github.com/mikeb01/ticketing (for example, com.lmax.ticketing.web.RequestServlet) - this uses Message as an object in RingBuffer .

RingBuffer pre-populated with these events using the EventFactory provided when the Disruptor constructor is called. This way, you only create a new instance of them when creating RingBuffer , and you reuse them throughout your Disruptor . Again, you can see an example of this in the above project.

Answer 2

I would say no, because there is no limit to the code you wrote. If the author intended to use such a thing, the code should apply it.

UPDATE: You have the answer: no. If you get a hundred more no answers, do you still have to wait if a black swan appears? Do you have data indicating that this is a problem?

Do you expect all caching solutions to have the same fate? I do not know such restrictions for any other caching solutions. Is this more evidence worth considering?