| Summary: | Try to make all fastMalloc isoheaped | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Filip Pizlo <fpizlo> |
| Component: | Web Template Framework | Assignee: | Filip Pizlo <fpizlo> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 233094, 235347 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Filip Pizlo
2021-10-18 21:26:23 PDT
Created attachment 441688 [details]
it begins
Created attachment 441751 [details]
so many WTF files compile
Created attachment 441827 [details]
WTF compiles now
Created attachment 441842 [details]
LLIntOffsetExtractor now compiles
Created attachment 441925 [details]
made it up to unified source 55 or so
Created attachment 441989 [details]
up to unified source 85 or so
Created attachment 442187 [details]
up to unified source 112 or so
Created attachment 442239 [details]
JavaScriptCore.framework builds
Of course, jsc binary fails to build. I'll get back to that...
Created attachment 442266 [details]
jsc shell builds
I haven't dared testing it
Created attachment 442276 [details]
all of jsc builds
Haven't tested it yet
And of course it crashes in a super subtle way. I think that somewhere, this patch messes up the size of something. 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! Created attachment 442281 [details]
it runs "hello world" successfully
SHIP IT!!
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. (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. LOL 17% RAMification overhead, is what it's looking like, right now. Created attachment 442552 [details]
it passes all the tests and uses way too much memory and runs way too slow
it's a start
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.
|