Fix memory leak in queue

[ankur22]

What?

Overwrite the empty queue.read with a new slice.

Why?

When we read off the queue.read slice, it essentially pops the first available element by doing this:

case eh.ch <- eh.queue.read[0]:
        eh.queue.read[0] = Event{}
	eh.queue.read = eh.queue.read[1:]

(link to code)

So the entry where the event used to exist has been overwritten with a fresh instance of Event which will help avoid a memory leak (which was recently fixed). However the issue is that the underlying slice keeps growing. During a long running test the slice could grow to an unnecessarily length.

To avoid this issue, when queue.read is empty and is swapped with queue.write, just before swapping them around the existing queue.read is overwritten with a new slice, freeing up the old potentially long slice. This should help avoid further memory leaks.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make tests) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

[inancgumus]

Interesting! 👍 Btw, the older commits from that other PR are still showing up in this PR.

[joanlopez]

However the issue is that the underlying slice keeps growing.

Does that mean that the Go GC isn't able to collect the memory allocations that are no longer pointed by any slice? 🤔

I guess that after:

eh.queue.read = eh.queue.read[1:]

The memory address where eh.queue.read[0] is stored remains, but since after that line there's no slice pointing to that position (eh.queue.read now points to, since the next position eh.queue.read[1] till the end of the underlying array), I'd expect the GC to be smart enough to collect these addresses.

Instead, I guess that (based on the change on this PR), it is only able to collect a range of memory addresses that's not pointed at all by any slice. Is that reasoning right? 🤔

[ankur22]

@joanlopez the GC will only cleanup the element that the 0th entry is pointing to if nothing is referencing it. So the underlying array remains in place i believe.

In grafana/xk6-browser#1488, we found this the hard way when the reference was being kept even though there was no way to get back to the 0th element after performing

eh.queue.read = eh.queue.read[1:]

Therefore by making the change in this PR, we are sure that the underlying array is empty and the previous array is cleaned up by the GC.

The base branch was changed.