[Mono-dev] Need help tracking this bug...

[Joe Shaw]

Hi again,

On 3/30/07, Joe Shaw <joe at ximian.com> wrote:
> That huge object array, in turn, is referenced by
> System.Collections.Queue -> System.Net.Socket.Socket, specifically the
> readQ member.  So basically it means that the readQ member in
> System.Net.Socket.Socket is a huge Queue, which internally has an
> object array, which apparently has millions of SocketAsyncResult
> objects inside.  So how those are being allocated?
>
> These objects are created a lot[...]

I got a little ahead of myself here: I'm obviously looking at the code
for System.Net.Sockets.Socket here.

> I don't know much about the Socket class and how the async IO
> works, but it boils down to the fact that BeginReceive() is being
> called probably millions of times, but it doesn't look like Complete()
> is being called enough (or possibly at all) to balance the load.

I actually noticed something else:

The object array in question has an average size of 10.6 megs, but it
only holds 56 references to SocketAsyncResult at the time of this
snapshot.  So this seems to indicate to me that the enqueues and
dequeues do ultimately match up, but that the allocation pattern is
bad and probably not interspersed.  That is,

enqueue, enqueue, dequeue, dequeue, enqueue, enqueue, etc.

would mean that an array could be as small as 2 items and still work
for N items, assuming a 1:1 match..  But if the pattern is instead,

enqueue, enqueue, enqueue, enqueue, dequeue, dequeue, etc.

then it would have to be at least N.  Now pretend N is a million. :)

Joe