710883 - Create js::BufferUnderloaded for use in JS engine

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Chris Leary [:cdleary] (not checking bugmail)]

Nick, per our discussion in bug 708873 comment 6, it would be very helpful to have a function internal to the JS engine that gave a conservative approximation for undesirable buffer slop to avoid triggering the memory reporter assertion. This would give us a central heuristic to tune in order to avoid unnecessary reallocs, but still avoid the memory allocator assertion for all practical purposes.

As we noted in that bug, StringBuffer can create strings from numerous places in the engine with various lengths and load factors (thanks to |Vector::reserve| and the vector space doubling behavior). If you could write a heuristic that we could slot into places like |StringBuffer::extractWellSized| that would be quite useful, so we could just say:

    if (length > CharBuffer::sMaxInlineStorage
        && BufferUnderloaded(length * sizeof(jschar), capacity * sizeof(jschar))) {
        // ... realloc the buffer to size ...
    }

Comment 1

[Nicholas Nethercote [inactive]]

I can't see a way to do this without using moz_malloc_usable_size or equivalent, and that's not doable within the JS engine.  (I tried defining a JS-specific equivalent a while ago and hit all sorts of troubles, I can't remember exactly why now, but they were bad enough that I found a different way to solve the problem.)

The only way forward is can see is to create a JSAPI function that lets you register a moz_malloc_usable_size-like function with the engine, and use that if it's been registered.  The browser would register just after the JS engine starts up.

Comment 2

[Luke Wagner [:luke]]

How fast is moz_malloc_usable_size?

Comment 3

[Nicholas Nethercote [inactive]]

(In reply to Luke Wagner [:luke] from comment #2)
> How fast is moz_malloc_usable_size?

Not that fast... it's similar to realloc() when it shrinks, judging from jemalloc's code.

Do we have evidence that unconditional realloc'ing is too slow?  They'll always be shrinking reallocs, which is the fastest case.

Comment 4

[Luke Wagner [:luke]]

Does realloc() always take a global lock?

Comment 5

[Nicholas Nethercote [inactive]]

It appears not to for non-huge allocations.  You can check for yourself in memory/jemalloc/jemalloc.c.

Comment 6

[Luke Wagner [:luke]]

(In reply to Nicholas Nethercote [:njn] from comment #5)
> You can check for yourself in memory/jemalloc/jemalloc.c.

You can do that ?!! ;-)  The path does look reasonably fast (the non-moving-small-realloc path is surprisingly easy to follow).  Given that extractWellSized() only reallocs when length > sMaxInlineLength and, for large strings, the cost of the the lock should be amortized by the cost of building the actual string, I think you're right that realloc() makes sense.

Comment 7

[Luke Wagner [:luke]]

P3 or just WONTFIX?

Comment 8

[Nicholas Nethercote [inactive]]

We need to do something to create the right-sized strings to avoid the assertion failure in the memory reporters.

Comment 9

[Nicholas Nethercote [inactive]]

There's a simpler option.  If you pass computedSize=0 as the second argument to mallocSizeOf() the size checking isn't performed.  The downside of this is that on platforms where moz_malloc_usable_size always returns 0, the string won't be counted at all.  But such platforms are very unusual.

So we could just pass computedSize=0 into the two calls to mallocSizeOf() in JSString::charsHeapSize().

Comment 10

[Nicholas Nethercote [inactive]]

This assertion was just removed in bug 715453.