> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov <a...@webkit.org> wrote:
> 
> 
> 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov <a...@webkit.org 
> <mailto:a...@webkit.org>> написал(а):
> 
>> 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.
> 
> Another way to say this is: we need to deal with large data arrays throughout 
> loading code. We do not really need full size vectors in most other code - 
> it's sort of OK for HTML parser or for image decoder to fail catastrophically 
> when there is too much data fed to it.
> 
> This is somewhat questionable design, but if we are going to stick to it, 
> then magnitude checks should be centralized, not sprinkled throughout the 
> code. We should not make this check explicitly when feeding a network 
> resource to the parser, for example.
> 
> A 64-bit API for Vector solves this nearly flawlessly. We do not perform the 
> checks manually every time we use a Vector, Vector does them for us.
> 
> Other options are:
> 
> - uint64_t everywhere. This way, we'll solve practical problems with large 
> resources once and for all. Also, this may prove to be necessary to solve 
> even YouTube/Google Drive uploads, I do not know that yet.

How does this solve the problem of >4GB data on 32-bit systems?  Are you saying 
that because the code that measures file sizes uses a 64-bit type then 
therefore the code that measures memory object sizes should also use that same 
type?

-Filip


> 
> - size_t everywhere. Same effect on 64-bit platforms, while 32-bit ones will 
> still be limited. I like this option, because it won't make us pay the memory 
> and performance cost on old crippled 32-bit machines, which are unlikely to 
> be used for manipulating huge volumes of data anyway.
> 
> We'll also need to develop some magic for 53-bit JS bindings, which I'm not 
> sure about.
> 
> - Alexey
> 

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to