[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 4:03 PM, Kenneth Russell <kbr@google.com> wrote:
There is much historical experience with explicitly forcing garbage
collection in the context of Java and its System.gc() call.
Essentially, all evidence indicates that is not a good idea to expose
this primitive to applications. In basically every situation where a
Java application called this method, performance was increased by
*not* calling it. Forcing a full garbage collection at any point in
time defeats advanced techniques like generational, incremental, and
concurrent garbage collection.

That's a very good counter-example, yeah. 
Work is ongoing in multiple areas to improve performance of typed
arrays, GC, and _javascript_ in general. In the V8 _javascript_ engine,
typed arrays will be allocated out of the _javascript_ heap, instead of
allocating their storage externally. This will both improve the speed
of allocating typed arrays and views (which are slow operations right
now), and improve their behavior under garbage collection. Work is
also underway in V8 to implement a concurrent garbage collector, the
goal of which is to eliminate GC pauses.

That's excellent news! 
Mozilla is also pushing forward asm.js ( http://asmjs.org/ ), a subset
of _javascript_ which, if used as a compilation target, would not need
to do any object allocations and thereby would not need to invoke the
garbage collector.

Yeah, I've read about it, a pretty interesting project. 
To summarize, I don't support adding a dispose() method to typed
arrays at this time. Instead I think the focus should be on further
optimizing current implementations. There are known performance gaps
and those should be addressed before adding more APIs.

If you have real-world examples or benchmarks showing that GC of typed
array instances is the culprit in jankiness of an application, please
make them available somewhere (e.g. on Github).

To be honest, the most problems I've had is with code so old that it probably has the GC issues coming just from generally bad approaches so I doubt it'll be worth people's time to make them analyze the code. But I will do so when I come up with something more recent.

Thanks for your answer, Kenneth. You're right; it's probably best to wait and see how far we can push the GC before giving developers more mental overhead.



On Mon, Feb 25, 2013 at 12:27 PM, Florian Bösch <pyalot@gmail.com> wrote:
> 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?
>> Patrick