Re: [hybi] Background info: Properties of sendfile()

[Greg Wilkins <[e-mail]>]

On 6 August 2010 12:43, Jamie Lokier <[e-mail]> wrote:
> Greg Wilkins wrote:
>> On 6 August 2010 11:28, Jamie Lokier <[e-mail]> wrote:

>> For jetty using java's file mapped buffers, we've encountered 2 key
>> problems that cause us to turn it off.
>
> Little note: Mapped buffers aren't sendfile (unless they aren't what
> they sound like; I don't know Java too well).  Assuming they're mmap()
> plus send(), they are a different technique that achieves _some_ of
> the same benefits.  Mapped buffers reduce memory use and some copying,
> but don't result in sockets sharing the same memory, nor eliminate
> copying, nor are they affected in the same way by NIC hardware
> acceleration constraints - unless mapped buffers can combine forces with AIO
> (which certainly isn't possible on Linux, at least).

this is a little off topic, but...

The JVM API allows for memory map buffers to be sent to a channel and
it is meant to use sendfile like mechanisms so that the file content
is sent directly to the interface device.

I think the need to memory map to a buffer is a side effect of the
java API, which is all about channels and buffers and totally hides
file descriptors.  It may be that in this case java uses the memory
mapped buffer only as a holder of a file descriptor plus offset and
length.

> For a different perspective, see Roberto Peon's message which has the
> same thread parent as yours - he says there's no gain from sendfile.

Probably the biggest benefit from the java point of view is not being
able to drive the network interface at maximum speed, but rather
avoiding using user memory and the garbage collects that result.

cheers