Bug 195436 - WebRTC: don't use stack buffer
Summary: WebRTC: don't use stack buffer
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-07 14:43 PST by JF Bastien
Modified: 2022-02-28 03:29 PST (History)
6 users (show)

See Also:


Attachments
Patch (2.48 KB, patch)
2019-03-07 14:43 PST, JF Bastien
no flags Details | Formatted Diff | Diff
Patch (2.73 KB, patch)
2019-03-07 15:27 PST, JF Bastien
no flags Details | Formatted Diff | Diff
Patch (2.73 KB, patch)
2019-03-07 16:13 PST, JF Bastien
no flags Details | Formatted Diff | Diff
Patch (2.74 KB, patch)
2019-03-07 16:40 PST, JF Bastien
no flags Details | Formatted Diff | Diff
Patch (2.81 KB, patch)
2019-03-07 16:51 PST, JF Bastien
youennf: review+
Details | Formatted Diff | Diff
Patch (2.80 KB, patch)
2019-03-07 17:05 PST, JF Bastien
achristensen: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description JF Bastien 2019-03-07 14:43:10 PST
WebRTC: don't use stack buffer
Comment 1 JF Bastien 2019-03-07 14:43:44 PST
Created attachment 363933 [details]
Patch
Comment 2 EWS Watchlist 2019-03-07 14:47:07 PST
Attachment 363933 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 3 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 JF Bastien 2019-03-07 15:27:41 PST
Created attachment 363941 [details]
Patch
Comment 4 EWS Watchlist 2019-03-07 15:30:35 PST
Attachment 363941 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 3 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 5 JF Bastien 2019-03-07 16:13:48 PST
Created attachment 363947 [details]
Patch
Comment 6 EWS Watchlist 2019-03-07 16:16:03 PST
Attachment 363947 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 3 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 7 JF Bastien 2019-03-07 16:40:44 PST
Created attachment 363957 [details]
Patch
Comment 8 EWS Watchlist 2019-03-07 16:43:13 PST
Attachment 363957 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 3 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 9 youenn fablet 2019-03-07 16:46:59 PST
Comment on attachment 363957 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363957&action=review

> Source/WebCore/ChangeLog:3
> +        WebRTC: don't create huge stack buffer in a loop

Probably missing https://bugs.webkit.org/show_bug.cgi?id=195436 here.

> Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCAudioModule.cpp:99
> +        m_data.reset(new char[bytesPerSample * channels * samplesPerFrame]);

Would better read with make_unique?
Comment 10 JF Bastien 2019-03-07 16:51:36 PST
Created attachment 363958 [details]
Patch

Address comments.
Comment 11 youenn fablet 2019-03-07 16:59:20 PST
Comment on attachment 363958 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363958&action=review

> Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCAudioModule.cpp:99
> +        m_data.reset(std::make_unique<char[]>(bytesPerSample * channels * samplesPerFrame));

Would use m_data = std::make_unique.

If we go down that road, we could also allocate m_data in StartPlayoutOnAudioThread and delete it when exiting of StartPlayoutOnAudioThread.
That would remove the if check and deallocate it when no longer needed.
Comment 12 JF Bastien 2019-03-07 17:05:28 PST
Created attachment 363960 [details]
Patch

(In reply to youenn fablet from comment #11)
> Comment on attachment 363958 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=363958&action=review
> 
> > Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCAudioModule.cpp:99
> > +        m_data.reset(std::make_unique<char[]>(bytesPerSample * channels * samplesPerFrame));
> 
> Would use m_data = std::make_unique.

Oops yes. Fixed.


> If we go down that road, we could also allocate m_data in
> StartPlayoutOnAudioThread and delete it when exiting of
> StartPlayoutOnAudioThread.
> That would remove the if check and deallocate it when no longer needed.

I can do that if you want, I didn't dig through the code to convince myself that it was correct :-)
Comment 13 Darin Adler 2019-03-10 15:37:01 PDT
Comment on attachment 363960 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363960&action=review

> Source/WebCore/ChangeLog:7
> +        The 1920 byte buffer is pretty big, and the loop is unrolled 5
> +        times in a regular build.

If the unrolling is the issue, just putting the buffer outside the loop would solve the problem. Not sure allocating on the heap is the right thing.
Comment 14 JF Bastien 2019-03-10 15:45:07 PDT
Comment on attachment 363960 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=363960&action=review

>> Source/WebCore/ChangeLog:7
>> +        times in a regular build.
> 
> If the unrolling is the issue, just putting the buffer outside the loop would solve the problem. Not sure allocating on the heap is the right thing.

My ulterior motive is that, once we automatically initialize this stack buffer, it'll be expensive. Without LTO the compiler won't be able to prove anything about the buffer being initialized somewhere else, so it'll call memset. There's a few other places in WebCore where this happens for somewhat large buffers.
Comment 15 Darin Adler 2019-03-10 15:58:19 PDT
(In reply to JF Bastien from comment #14)
> My ulterior motive is that, once we automatically initialize this stack
> buffer, it'll be expensive.

OK.
Comment 16 youenn fablet 2019-03-10 16:28:52 PDT
(In reply to JF Bastien from comment #12)
> Created attachment 363960 [details]
> Patch
> 
> (In reply to youenn fablet from comment #11)
> > Comment on attachment 363958 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=363958&action=review
> > 
> > > Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCAudioModule.cpp:99
> > > +        m_data.reset(std::make_unique<char[]>(bytesPerSample * channels * samplesPerFrame));
> > 
> > Would use m_data = std::make_unique.
> 
> Oops yes. Fixed.
> 
> 
> > If we go down that road, we could also allocate m_data in
> > StartPlayoutOnAudioThread and delete it when exiting of
> > StartPlayoutOnAudioThread.
> > That would remove the if check and deallocate it when no longer needed.
> 
> I can do that if you want, I didn't dig through the code to convince myself
> that it was correct :-)

I think it is correct and would improve the code a bit.
m_data could be replaced by a local var as well.
Comment 17 Alex Christensen 2019-03-11 14:02:59 PDT
Your earlier version used operator new[] which I believe does not initialize the values to 0, and based on youenn's feedback you now use std::make_unique<char[]>, which I believe does initialize the values to 0.  Is this true?  Is this desired?
Comment 18 Alex Christensen 2019-03-11 20:30:35 PDT
Comment on attachment 363960 [details]
Patch

This also doesn't use fastMalloc/fastFree, but makeUniqueArray does.