1998179 - Testcase calling async.iterator N times shows over-recursion error. Chrome appears to run it fine.

Status: RESOLVED FIXED

(Core :: JavaScript Engine, task, P3)

Description

[Mayank Bansal]

Attachment: async iteration.html

Open testcase and click on run.

chrome: https://share.firefox.dev/47UtB73
firefox: Uncaught (in promise) InternalError: too much recursion

Comment 1

[Mayank Bansal]

shows error with/without the new js-utask.

Comment 2

[Tooru Fujisawa [:arai]]

there's a recursion with the following:
AsyncGeneratorResume -> AsyncGeneratorYield -> AsyncGeneratorUnwrapYieldResumption -> AsyncGeneratorResume

We should instead make it a loop inside AsyncGeneratorResume, with letting AsyncGeneratorYield and AsyncGeneratorUnwrapYieldResumption return a special value for the case.

Comment 3

[Mayank Bansal]

N=5000000: https://share.firefox.dev/4oGLHzL

It also sometimes goes into a weird state: https://share.firefox.dev/4ovQFPK

Comment 4

[Tooru Fujisawa [:arai]]

Attachment: Bug 1998179 - Part 1: Add a dummy loop in AsyncGeneratorResume as a preparation . r?mgaudet!

Comment 5

[Tooru Fujisawa [:arai]]

Attachment: Bug 1998179 - Part 2: Use loop instead of recursion for the continuation after yield in async generator. r?mgaudet!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/93b533769665
https://hg.mozilla.org/integration/autoland/rev/6eb4df605cca
Part 1: Add a dummy loop in AsyncGeneratorResume as a preparation . r=mgaudet
https://github.com/mozilla-firefox/firefox/commit/937372ef80f6
https://hg.mozilla.org/integration/autoland/rev/641448b8955e
Part 2: Use loop instead of recursion for the continuation after yield in async generator. r=mgaudet

Comment 7

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/6eb4df605cca
https://hg.mozilla.org/mozilla-central/rev/641448b8955e

Comment 8

[Mayank Bansal]

50000: https://share.firefox.dev/3WSfFnY (43ms)
5000000: https://share.firefox.dev/47OC1vH (15s)

Edit: seems heavy on js::NativeObject::elementsRangePostWriteBarrier

Comment 9

[Matthew Gaudet (he/him) [:mgaudet]]

So taking a quick peek at that profile, it seems like part of the issue here is that we run into a gently awkward cliff; basically once a ListObject exceeds 2047 elements, we start having to actually -move- elements, triggering heaps of barrier cost.

Now, what we're manipulating is the generator object queue, so. I suspect this is rare outside of test cases. I hope.