[webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Oliver Hunt]

We almost always perform bounds checking in our use of Vector — the default behaviour bounds checks every access, it is a negligible cost, and in most cases the remaining non-checked instances of Vector<> can probably actually be made checked.

The current bounds checked iterator on bugs.webkit.org also has no performance impact, and it is having to do bounds and overflow checking. We really need to be careful about saying release checking is expensive, if even in our core vector type bounds checking is fine it’s unlikely most other simple tests will be fine. For example JSC has been steadily moving towards RELEASE_ASSERT for everything.

—Oliver


> On Nov 19, 2014, at 5:06 PM, Alex Christensen <alex.christensen at flexsim.com> wrote:
> 
> Has anybody done any performance benchmarking on this?  I imagine the changes would be significant based on how hot the vector code is.  There are 8 cases I see that would be worth looking into: unsigned and size_t, with and without bounds checking, 32-bit and 64-bit architectures.  The performance gains of not doing bounds checking would be worth being extra careful in some cases.
> 
> Alex
> 
> On Wed, Nov 19, 2014 at 4:13 PM, Chris Dumez <cdumez at apple.com <mailto:cdumez at apple.com>> wrote:
> If we don’t want to crash on overflow, the callers can use the try*() API I believe (e.g. tryAppend()). This returns false (and does not resize the vector) instead of crashing, when we reach the size limit.
> 
> Kr,
> --
> Chris Dumez - Apple Inc.
> Cupertino, CA
> 
> 
> 
> 
>> On Nov 19, 2014, at 2:58 PM, Alexey Proskuryakov <ap at webkit.org <mailto:ap at webkit.org>> wrote:
>> 
>> 
>> 19 нояб. 2014 г., в 13:58, Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> написал(а):
>> 
>>>> With Vector though, I don't know how we would differentiate code paths that need large allocations from ones that don't. Nearly anything that is exposed as a JS API or deals with external world can hit sizes over 4Gb. That's not out of reach in most scenarios, not even for resources loaded from network.
>>> 
>>> Can you provide an example?
>> 
>> Yes. XMLHttpRequest::m_binaryResponseBuilder keeps the downloaded data in a Vector, so any time there is much data, something bad will happen. This is a case that we should support, and not just crash as we would when we think that only exploits would try to use as much memory.
>> 
>> All code that is Blob related also uses Vectors, and of course Blobs can legitimately be large.
>> 
>> Crypto code uses Vectors internally for the data.
>> 
>> These and related uses are all over the place - see also Vectors in FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, plug-in code that loads from network, SharedBuffer etc.
>> 
>> - Alexey
>> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> 
> 
> -- 
>  
> Alex Christensen
> 
> FlexSim Software Products, Inc.
> 
> 1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097
> 
> Voice: 801-224-6914 <> | Fax: 801-224-6984 <>
> Email: alexc at flexsim.com <mailto:kimw at flexsim.com>
> URL: www.flexsim.com <http://www.flexsim.com/>
>  
> ---------------------------------------------------------------------------------------- 
> This message may contain confidential information, and is intended
> 
> only for the use of the individual(s) to whom it is addressed. 
> ----------------------------------------------------------------------------------------
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141119/6a76120b/attachment.html>