Bug 231938 – Try to make all fastMalloc isoheaped

• Status: NEW
• Component: Web Template Framework

[Filip Pizlo]

I'm holding my thumbs.

[Filip Pizlo]

Created attachment 441688 [details]
it begins

[Filip Pizlo]

Created attachment 441751 [details]
so many WTF files compile

[Filip Pizlo]

Created attachment 441827 [details]
WTF compiles now

[Filip Pizlo]

Created attachment 441842 [details]
LLIntOffsetExtractor now compiles

[Filip Pizlo]

Created attachment 441925 [details]
made it up to unified source 55 or so

[Filip Pizlo]

Created attachment 441989 [details]
up to unified source 85 or so

[Filip Pizlo]

Created attachment 442187 [details]
up to unified source 112 or so

[Filip Pizlo]

Created attachment 442239 [details]
JavaScriptCore.framework builds

Of course, jsc binary fails to build.  I'll get back to that...

[Filip Pizlo]

Created attachment 442266 [details]
jsc shell builds

I haven't dared testing it

[Filip Pizlo]

Created attachment 442276 [details]
all of jsc builds

Haven't tested it yet

[Filip Pizlo]

And of course it crashes in a super subtle way.

I think that somewhere, this patch messes up the size of something.

[Filip Pizlo]

Comment on attachment 442276 [details]
all of jsc builds

View in context: https://bugs.webkit.org/attachment.cgi?id=442276&action=review

> Source/WTF/wtf/FastMalloc.h:276
> +template<typename T>
> +T* fastMallocArrayWithLength(size_t arrayLength)
> +{
> +    size_t size;
> +    if (__builtin_mul_overflow(arrayLength, sizeof(T), &size))
> +        CRASH();
> +    return fastMallocArrayWithByteSize<T>(arrayLength);
> +}

Compute the size, pass the arrayLength as the size anyway.

That's what I call quality!

[Filip Pizlo]

Created attachment 442281 [details]
it runs "hello world" successfully

SHIP IT!!

[Filip Pizlo]

The ghost of bad decisions past returns:

pas panic: /Volumes/Data/primary/OpenSource/Source/bmalloc/libpas/src/libpas/pas_thread_local_cache_layout.c:73: pas_allocator_index pas_thread_local_cache_layout_add_node(pas_thread_local_cache_layout_node): assertion !did_overflow failed.

Seems like I'll have to:

- Make pas_allocator_index be 32-bit again. Or at least 24-bit.
- Do something to control blow-up of the size of thread_local_caches and size class lookup tables.

Not easy, but doable.  I guess first thing is to test pas_allocator_index being 32-bit again, and make sure that this makes tests pass.

[Filip Pizlo]

(In reply to Filip Pizlo from comment #14)
> The ghost of bad decisions past returns:
> 
> pas panic:
> /Volumes/Data/primary/OpenSource/Source/bmalloc/libpas/src/libpas/
> pas_thread_local_cache_layout.c:73: pas_allocator_index
> pas_thread_local_cache_layout_add_node(pas_thread_local_cache_layout_node):
> assertion !did_overflow failed.
> 
> Seems like I'll have to:
> 
> - Make pas_allocator_index be 32-bit again. Or at least 24-bit.

Can't be 24-bit since we need to be able to set and get it atomically.

> - Do something to control blow-up of the size of thread_local_caches and
> size class lookup tables.

Easy: need to have decommit of unused parts of the thread local caches, and decommit of unused size class lookup tables.

[Filip Pizlo]

LOL 17% RAMification overhead, is what it's looking like, right now.

[Radar WebKit Bug Importer]

<rdar://problem/84646022>

[Filip Pizlo]

Created attachment 442552 [details]
it passes all the tests and uses way too much memory and runs way too slow

it's a start

[Filip Pizlo]

Created attachment 442553 [details]
status report after running typescript,acorn-wtb,Air,pdfjs,crypto-aes-SP from RAMification

This shows the pas_status_reporter dump after running typescript,acorn-wtb,Air,pdfjs,crypto-aes-SP.  In this test, using all these isoheaps increases memory footprint a lot - by maybe 20MB or so.  It also runs slower.  This libpas status report shows the 1097 heaps that we create and what they look like.

Lots of dumb stuff in there, like types that are really primitive, but we didn't detect them to be primitive.