[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] [Typed Array] ArrayBuffer Method Request - Dispose

The issues with the GC are never going to go away. They might improve, but they're not gonna go away. Dispose isn't going to make them go away either. Effectively what people want is to manage their own memory, and we can do that, almost. Array buffers can in fact be used much like a memory pool (in conjunction with views for instance).

As has been noted, the biggest obstacle in that is that there are APIs that produce array buffers instead of taking a "pointer" to fill. However, even if you made XHR fill a buffer rather than produce one, there'd need to be a way to deal with what happens when the XHR would fetch more data than the buffer can hold (in C you solve that simply by copying the data somewhere else progressively as you read them in from a file or a socket).

On Mon, Feb 25, 2013 at 9:02 PM, Patrick Baggett <baggett.patrick@gmail.com> wrote:

On Mon, Feb 25, 2013 at 1:53 PM, Gregg Tavares <gman@google.com> wrote:

On Mon, Feb 25, 2013 at 11:20 AM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:
On Mon, Feb 25, 2013 at 2:16 PM, Gregg Tavares <gman@google.com> wrote:

On Mon, Feb 25, 2013 at 11:00 AM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:
On Mon, Feb 25, 2013 at 1:32 PM, Gregg Tavares <gman@google.com> wrote:
typed arrays are garbage collected just like all JS objects. You can just as easily make large strings or large _javascript_ arrays. _javascript_ will release any unreferenced typed array on it's own just fine. If you have a reproducible case where a typed array is not getting released file a bug for that browser.

The problem isn't that the memory isn't released, quite the contrary, the problem is that the memory is often released at the wrong time, e.g. in the middle of filling a buffer with audio (if you fail at filling the buffer quickly enough, your sounds won't make it to the speakers) or during a drawing operation, causing jitter in the frame rate. Having a manual dispose function to free the buffer would for example let the developer free the memory for example after the buffer is filled with audio, thus reducing the risk of artifacts in the sound.

You're making a huge assumption that calling dispose would some how magically be (a) fast and (b) effect allocation speed later.

What makes you think so?

a) No, I don't expect it to be any faster than garbage collection.
b) What? Where did you get this?

The point is that the deallocation, however slow or fast, happens at a suitable time.

My point is your proposal of dispose assumes that dispose is implemented as you imagine it. It would be just as easy to implement dispose as

ArrayBuffer::dispose() {
   addMemoryThatArrayBufferIsUsingToSomeGarbageCollectionListThatWillBeUsedSometimeInTheFuture(m_data, m_size);
   m_data = NULL;
   m_size = 0;

This neatly explains your fears. Ack. It seems like the only way to solve this is to force the semantic of "collect it now; this is not a hint, this is a command." That is somewhat untestable in the PASS/FAIL sense of course.
Your problem has not been solved by dispose.

I'm guessing that forcing the semantic of "collect it now" is not a viable/good option?