Bug 33896 - FastAllocBase is probably making many of our objects a bit bigger
Summary: FastAllocBase is probably making many of our objects a bit bigger
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Template Framework (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 39414
  Show dependency tree / graph
 
Reported: 2010-01-20 05:45 PST by Zoltan Horvath
Modified: 2010-11-22 01:42 PST (History)
3 users (show)

See Also:

Attachments
List of classes which first member is RefPtr and inherited from FastAllocBase (9.19 KB, text/plain)
2010-02-11 06:14 PST, Zoltan Horvath 		no flags Details
List of classes which are instantiated by new and inherited from FastAllocBase (16.36 KB, text/plain)
2010-02-11 06:53 PST, Zoltan Horvath 		no flags Details
List of classes whose size grows (1.70 KB, text/plain)
2010-03-31 01:02 PDT, Zoltan Horvath 		no flags Details
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Zoltan Horvath 2010-01-20 05:45:48 PST 
Adding FastAllocBase as base class for objects has been making them all larger this is inflating WebKit’s memory use.

I'm going to collect the list of classes and try to measure the overhead.
Comment 1 Zoltan Horvath 2010-02-11 06:14:00 PST 
Created attachment 48558 [details]
List of classes which first member is RefPtr and inherited from FastAllocBase

This list contains almost all classes (142) which are inherited from FastAllocBase and their first member is a RefPtr.
Comment 2 Zoltan Horvath 2010-02-11 06:53:36 PST 
Created attachment 48560 [details]
List of classes which are instantiated by new and inherited from FastAllocBase

I did another analysis . This txt contains the list of classes - 956 pieces - which are instantiated by new and inherited from FastAllocBase somehow.
Comment 3 Zoltan Horvath 2010-02-11 06:54:29 PST 
I made these analysis on r54336.
Comment 4 Zoltan Horvath 2010-03-31 01:02:41 PDT 
Created attachment 52139 [details]
List of classes whose size grows

I've put more effort on this topic, the results:

The problem:
If a FastAllocBase class' first member is a FasAllocBase class then padding is added to the object and this making the object bigger.

The object's size grows by 4 bytes.
e.g. (on my Debian-x86)
FontPlatformDataCacheKey 28 bytes -> 32 bytes
Parser 76 bytes -> 80 bytes
MediaQueryExp 12 bytes -> 16 bytes

This problem stands for only in non-template cases, so aren't valid for the following cases: 
  - if the class is inherited from FastAllocBase through (e.g.) RefCounted<X>, padding are not added; 
  - if the first member is a template instantiation, padding are not added;

Solutions:
1. We can reorder the members (we can do this only a subset of the listed classes)
e.g. struct ScopeNodeData (JavaScriptCore/parser/Nodes.h:1375)
If we place int m_numConstants; to the first member of ScopeNodeData padding wont' be added.

2. Make FastAllocBase a class template and inherit from FastAllocBase<X>, so padding won't be added.
Comment 5 Darin Adler 2010-03-31 10:37:05 PDT 
(In reply to comment #4)
> 2. Make FastAllocBase a class template and inherit from FastAllocBase<X>, so
> padding won't be added.

Lets do that.
Comment 6 Zoltan Horvath 2010-04-07 03:43:46 PDT 
(In reply to comment #5)
> (In reply to comment #4)
> > 2. Make FastAllocBase a class template and inherit from FastAllocBase<X>, so
> > padding won't be added.
> 
> Lets do that.

I tested this solution on a simple instance and unfortunately it didn't work. Padding was added in template case as well.
Comment 7 Zoltan Horvath 2010-11-22 01:42:35 PST 
The solution for the problem is to using macros instead of inheriting.
See: bug #46589 and bug #42998.