Bug 237110

Summary: Web Inspector: [Cocoa] Split remote inspector message data into smaller chunks for large messages
Product: WebKit Reporter: Patrick Angle <pangle>
Component: Web InspectorAssignee: Patrick Angle <pangle>
Status: RESOLVED FIXED    
Severity: Normal CC: ews-watchlist, hi, inspector-bugzilla-changes, joepeck, keith_miller, mark.lam, msaboff, saam, tzagallo, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch v1.0
none
Patch v1.1 - Address review notes none

Patrick Angle
Reported 2022-02-23 14:06:01 PST
Attachments
Patch v1.0 (6.87 KB, patch)
2022-02-23 16:48 PST, Patrick Angle
no flags
Patch v1.1 - Address review notes (6.92 KB, patch)
2022-02-24 15:23 PST, Patrick Angle
no flags
Patrick Angle
Comment 1 2022-02-23 16:48:10 PST
Created attachment 453054 [details] Patch v1.0
Devin Rousso
Comment 2 2022-02-23 17:30:18 PST
Comment on attachment 453054 [details] Patch v1.0 View in context: https://bugs.webkit.org/attachment.cgi?id=453054&action=review > Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:209 > + NSUInteger const chunkSize = 2 * 1024 * 1024; // 2 Mebibytes Style: `const NSUInteger` NIT: How about `maxChunkSize`? > Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:222 > + NSUInteger currentChunkSize = (messageLength - offset > chunkSize) ? chunkSize : messageLength - offset; How about this? ``` NSUInteger currentChunkSize = std::min(messageLength - offset, maxChunkSize); ``` Or if not `std::min` some other similar method? > Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:548 > + NSNumber *chunkedMessageDataSupportedNumber = userInfo[WIRMessageDataTypeChunkSupportedKey]; NIT: Should we name this (and the member variable) `[m_]messageDataTypeChunkSupported[Number]` instead so that it matches the key? > Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:551 > + m_chunkedMessageDataSupported = !!chunkedMessageDataSupportedNumber && chunkedMessageDataSupportedNumber.boolValue; NIT: Is the `!!` needed? Some of the other `BOOL` seem to just directly consult `.boolValue`, so do we even need the part before the `&&`?
Devin Rousso
Comment 3 2022-02-23 17:46:17 PST
Comment on attachment 453054 [details] Patch v1.0 oops, forgot to r=mews
Joseph Pecoraro
Comment 4 2022-02-24 01:19:22 PST
Comment on attachment 453054 [details] Patch v1.0 View in context: https://bugs.webkit.org/attachment.cgi?id=453054&action=review > Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:208 > + NSUInteger messageLength = [messageData length]; I think we'd generally use the property style here `messageData.length`. > Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:221 > + for (NSUInteger offset = 0; offset < messageLength; offset += chunkSize) { Would it be worth adding an `@autoreleasepool {}` block inside this loop? I don't know if `subdataWithRange` keeps around chunks of data in 2MB sizes or not. I suspect it doesn't though. >> Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:551 >> + m_chunkedMessageDataSupported = !!chunkedMessageDataSupportedNumber && chunkedMessageDataSupportedNumber.boolValue; > > NIT: Is the `!!` needed? Some of the other `BOOL` seem to just directly consult `.boolValue`, so do we even need the part before the `&&`? I believe technically this line could just be like the one above it: m_chunkedMessageDataSupported = chunkedMessageDataSupportedNumber.boolValue; Because `chunkedMessageDataSupportedNumber.boolValue` is `[chunkedMessageDataSupportedNumber boolValue]` and if `chunkedMessageDataSupportedNumber` is `nil` the result would be `0` which is `NO`. But I'm fine if you think being more explicit may be more readable.
Joseph Pecoraro
Comment 5 2022-02-24 01:25:40 PST
Seems some of my comments double posted. Sry about that!
Patrick Angle
Comment 6 2022-02-24 08:56:22 PST
Comment on attachment 453054 [details] Patch v1.0 View in context: https://bugs.webkit.org/attachment.cgi?id=453054&action=review >> Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:221 >> + for (NSUInteger offset = 0; offset < messageLength; offset += chunkSize) { > > Would it be worth adding an `@autoreleasepool {}` block inside this loop? I don't know if `subdataWithRange` keeps around chunks of data in 2MB sizes or not. I suspect it doesn't though. `subdataWithRange` does not appear to guarantee a no-copy operation, so an `autoreleasepool` is probably a good idea here. >> Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:222 >> + NSUInteger currentChunkSize = (messageLength - offset > chunkSize) ? chunkSize : messageLength - offset; > > How about this? > ``` > NSUInteger currentChunkSize = std::min(messageLength - offset, maxChunkSize); > ``` > Or if not `std::min` some other similar method? 🤦 >>> Source/JavaScriptCore/inspector/remote/cocoa/RemoteInspectorCocoa.mm:551 >>> + m_chunkedMessageDataSupported = !!chunkedMessageDataSupportedNumber && chunkedMessageDataSupportedNumber.boolValue; >> >> NIT: Is the `!!` needed? Some of the other `BOOL` seem to just directly consult `.boolValue`, so do we even need the part before the `&&`? > > I believe technically this line could just be like the one above it: > > m_chunkedMessageDataSupported = chunkedMessageDataSupportedNumber.boolValue; > > Because `chunkedMessageDataSupportedNumber.boolValue` is `[chunkedMessageDataSupportedNumber boolValue]` and if `chunkedMessageDataSupportedNumber` is `nil` the result would be `0` which is `NO`. > > But I'm fine if you think being more explicit may be more readable. I kinda forgot about the behavior of sending messages to nil objects in ObjC when I wrote this - it can absolutely be reduced down to your suggestions.
Patrick Angle
Comment 7 2022-02-24 15:23:54 PST
Created attachment 453144 [details] Patch v1.1 - Address review notes
EWS
Comment 8 2022-02-25 08:33:37 PST
Committed r290510 (247795@main): <https://commits.webkit.org/247795@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 453144 [details].
Note You need to log in before you can comment on or make changes to this bug.