[jboss-jira] [JBoss JIRA] (JGRP-809) Copyless stack

[Sanne Grinovero (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084359#comment-13084359 ] 

Sanne Grinovero commented on JGRP-809:
--------------------------------------

Hi Bela,
personally I'm mostly looking forward for the public API changes of JGroups to accept a reference to a buffer rather than having {code}byte[]{code} all over.

In several cases I actually deal with off-heap memory in the application code (sometimes plain old files), and I have to copy things into byte arrays to satisfy the JGroups API; if we could pass these things to you by reference, I suspect you could avoid some copying, chunking, resizing.. even if at wire level you actually end up needing to make some copies to satisfy limitations of latest NIO APIs.

Since you're working on a major release, I'd focus on shaping the JGroups API. Allow applications interacting with JGroups to define what they want transmitted without actually allocating memory: postpone buffer massaging as much as possible, you'll then be able to evolve the low level details in the near future without imposing disruptive changes to client code.

I guess that even with Socker limitations, there might still be cases in which you could avoid the copies? In some other cases, maybe the whole operation has to be aborted.. such cases would be an implementation detail, and we could refine that iteratively ; hopefully having the basic stuff put in place, we should all be able to start empirical iterations and help making the "details" evolve in smaller steps.

> Copyless stack
> --------------
>
>                 Key: JGRP-809
>                 URL: https://issues.jboss.org/browse/JGRP-809
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can
> - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to)
> - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return
> - each thread in the pool has its own buffer into which the buffer is read from the socket
> Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)