941792 - Make sure decommitting actually works on B2G

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Andrew McCreight [:mccr8]]

I'd think we'd have seen more problems if it didn't, but it isn't clear anybody has actually explicitly tested this.

Comment 1

[Nicholas Nethercote [inactive]]

This is kinda important.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Ting-Yuan, is this something you could investigate?

Comment 3

[Ting-Yuan Huang]

May I know if we are talking about making sure that the allocator/collector properly calls madvise()/..., or to check if the kernel works correctly?

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The kernel, I believe.  Can you confirm njn?

Comment 5

[Nicholas Nethercote [inactive]]

Well, both parts need to work :)  But I think the doubt was more about the kernel side, because we're pretty confident decommitting works on desktop, and the SpiderMonkey side of things is shared between desktop Firefox and Firefox OS.

Comment 6

[Ting-Yuan Huang]

I see. I'll try to write some tests in the userland to make sure that decommitted memory can be allocated (to other processes) again.

By the way, I'm considering to create a repository for compatibility and stress tests for platforms; We have been suffering from many platform issues, especially on new platforms of new partners. It would be great to filter out platform problems in early stages. Do we have something similar already?

Comment 7

[Ting-Yuan Huang]

Attachment: decommit.patch

I tested by spawning N threads/processes and allowing M of them to run concurrently. Each of M repeatedly writes K bytes, where M * K is close to available system memory, and then decommit. If the decommit, namely MADV_DONTNEED, doesn't work, it will be killed immediately.

On Inari(ZTE Open) and emulator it passed the test. Are there any additional targets of interest?

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Thanks Ting-Yuan.

Is there anything else we want to check here?

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Ting-Yuan Huang from comment #6)
> By the way, I'm considering to create a repository for compatibility and
> stress tests for platforms; We have been suffering from many platform
> issues, especially on new platforms of new partners. It would be great to
> filter out platform problems in early stages. Do we have something similar
> already?

I think this is a great idea.  I'm not aware of anything similar that exists already.  Maybe check with mwu?

Comment 10

[Nicholas Nethercote [inactive]]

> Is there anything else we want to check here?

Something else I should have thought of earlier:  about:memory has a "decommitted" sub-tree in the "Other Measurements" section.  Are we getting non-zero values there for B2G processes?  Maybe not all the time, but at least some of the time?

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Yes, I've seen b2g memory reports with decommited values.

Comment 12

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Reopen if you disagree.