818855 - sizeof(nsLineBuffer<char>) is 4108, should be 4096?

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[[e-mail]]

So as I understand it jemalloc ends up allocating us 8192 bytes and we therefore have 49.85% clownshoes...

Comment 1

[[e-mail]]

It looks as if idea is that the stream should read in blocks of 4096 bytes. Is this an ideal buffer size? We would need to split this allocation from the tracking pointers, and fix NS_ReadLine not to require a trailing null.

Comment 2

[Nicholas Nethercote [inactive]]

How many of these do we have?

Comment 3

[Eric Rahm [:erahm]]

Looked into the usage, in a simple browsing test I saw zero instances created/destroyed. 

It looks like the main user, nsFileInputStream::ReadLine (which creates a nsLineBuffer), is rarely used.
The main locations I found were in nsCertOverrideService, nsCookieService (importing cookies), webrtc/LoadMonitor (reading system stats on Linux/Android). It is also exposed to add-ons which may use it more gratuitously. 

MediaResourceServer also uses an instance to parse http input (seems to be android only).

There's a unicode conversion utility using nsLineBuffer<uint16_t> implementing a readline, but AFAICT it's never referenced.