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

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



On Mon, Feb 25, 2013 at 2: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;
};

Your problem has not been solved by dispose.

Why would an implementation do that? If we mandate that the memory be freed, then implementations can always decide to violate the specification, but what's the point of standardizing anything at all then? :D Of course problems don't become solved if implementations don't do what they're supposed to.
 
The GC issues are being worked on. For the time being there are sucky points. Make small sample repos and file bugs.
 
What's the point of expecting so much intelligence from the GC? It's not reasonable to expect the GC to handle all kinds of corner cases (performance-critical code often happens to be quite corner-case) well. The developer can be equipped with the tools to help the GC. It's not even like this would be adding something that wasn't already possible to achieve, or changing the whole semantics of the web platform (like for example adding a `free` operator to JS would), it would give you a lot better way to do it.

I made a gist [1] to demonstrate the claim above. The gist basically contains a polyfill for the proposed feature and an example for it. From the application's point of view, the array is disposed of. Of course, it's a crappy hack that has to create a new worker context just to dump unneeded data to, and it doesn't actually free the memory (although if we're lucky, the GC hit will be suffered only in the worker thread). But that's why we need a better way to do this.

Cheers,
Jussi

[1] https://gist.github.com/jussi-kalliokoski/5033123

Note: I hate GC as much as the next guy. I'm a C++ guy. But adding dispose isn't going to help IMO.
 

Cheers,
Jussi
 

Cheers,
Jussi
 

On Mon, Feb 25, 2013 at 5:12 AM, Si Robertson <retromodular@gmail.com> wrote:
Sorry, my mistake. The method obviously shouldn't have a return value.

interface ArrayBuffer {
    void dispose();
}

Si ++


On 25 February 2013 10:44, Kirill Prazdnikov <kirill.prazdnikov@jetbrains.com> wrote:
Hi,

interface ArrayBuffer {
    ArrayBuffer dispose();
}

What is the purpose of return value ?

Thanks

On 2/24/2013 9:39 PM, Si Robertson wrote:
Hi,

I have been studying, and experimenting with, the WebGL API and the Web Audio API recently and have noticed a potential system memory related problem with typed arrays: there is no way to dispose of array buffers when they are no longer needed.

When working with WebGL and/or Web Audio, array buffers can consume large amounts of system memory. Some of these buffers can be treated as permanent/static buffers and reused during the lifetime of an application, but others are temporary and might only be used during a single function call, or might need to be replaced when additional resources are loaded into the application (e.g. game level assets).

It would be extremely useful for programmers if we could explicitly dispose of an array buffer when it is no longer required. Disposing of an array buffer would immediately release any system resources used by the array buffer (e.g. system memory) and reduce the array buffer's length to zero. This would also potentially reduce the amount of work the GC has to do when it eventually decides to clean things up.

I am requesting a single method to be added to the ArrayBuffer type:

interface ArrayBuffer {
    ArrayBuffer dispose();
}

Most of the other programming languages I use allow these types of arrays to be disposed, for good reasons :)

Regards,
Si Robertson