[Vm-dev] About CompactClasses and their future [WAS] how many
free bits we have in Object Header?
Eliot Miranda
eliot.miranda at gmail.com
Thu May 6 16:37:48 UTC 2010
Hi Marian,
I intend to eliminate compact classes this year. See
<goog_1053221753>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-March/134461.html
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-March/134465.html
HTH
Eliot
On Thu, May 6, 2010 at 2:24 AM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:
>
> Hi folks. I was just trying to understand this optimization of the Compact
> Classes. If I understood correctly, most objects needs a second word there
> they have 30 bits of OOP of their class and 2 for the header type.
>
> There are classes that have a LOT of instances. For those cases we have
> compact classes where their instances have a number using those 5 bits in
> the first word of the header, and thus, they don't need a second header.
> Then, less memory is used.
>
> So...I understood ok ?
>
> Now, if that is the situation. I have evaluated Smalltalk
> compactClassesArray and I see that in the array there are a lot of nils. 16
> classes in Squeak and 15 in Pharo. The rest of the 31, are just nil.
>
> Now I wonder if it is worth to do anything with that :
>
> a) Use 4 bits instead of 5 and free one more bit in the OH
> b) remove completely CompactClasses as Adrian said
> c) Let 5 bits but then add more classes (up to 31) so that we can get
> benefits of that. Do you know if there are side effects of becomingCompact a
> class ?
>
> If I evaluate SpaceTally new printSpaceAnalysis I get something like this:
>
> Class code space # instances inst space percent
> ByteString 2217 71317 3621735
> 19.3
> CompiledMethod 21064 56057 3517772
> 18.7
> Bitmap 3893 2256 3424604
> 18.2
> Array 2478 71108 2198420
> 11.7
> ByteSymbol 959 37896 962465
> 5.1
> ByteArray 2778 317 778297
> 4.1
> MethodDictionary 1819 5964 449252
> 2.4
> MCVersionInfo 1313 10369 414760
> 2.2
> DateAndTime 6974 13793 331032
> 1.8
> WeakArray 827 286 326900
> 1.7
> Association 749 26784 321408
> 1.7
> UUID 1528 10370 248880
> 1.3
> Float 11442 16450 197400
> 1.1
> ClassOrganizer 1398 5964 190848
> 1.0
> ODatedEntry 263 7049 169176
> 0.9
> Time 5530 10369 165904
> 0.9
> Duration 3025 10290 164640
> 0.9
> Date 3167 10289 164624
> 0.9
> LargePositiveInteger 2515 14340 118169
> 0.6
> Metaclass 4250 2876 115040
> 0.6
> Point 6404 8476 101712
> 0.5
> GlyphForm 307 2030 73080
> 0.4
> FreeTypeCacheEntry 536 2238 71616
> 0.4
> SpaceTallyItem 651 2509 60216
> 0.3
> OrderedCollection 5351 2831 56620
> 0.3
> FreeTypeFileInfo 797 321 30816
> 0.2
> FreeTypeFontFamilyMember 1274 537 25776
> 0.1
> Color 21202 1255 25100
> 0.1
> TraitComposition 2651 2013 24156
> 0.1
> Set 3510 1358 21728
> 0.1
> Dictionary 5742 1344 21504
> 0.1
> RemoteString 1533 1236 19776
> 0.1
> SparseLargeTable 2376 2 18708
> 0.1
> WordArray 1821 30 18608
> 0.1
> SoundBuffer 3299 3 18508
> 0.1
> Pragma 1558 862 17240
> 0.1
> Preference 1534 379 16676
> 0.1
> EventHandler 3216 125 14500
> 0.1
> MorphExtension 3249 277 14404
> 0.1
> Character 6428 939 11268
> 0.1
> SortedCollection 1496 462 11088
> 0.1
> AdditionalMethodState 2576 859 10304
> 0.1
> ISOLanguageDefinition 18114 402 9648
> 0.1
> TimeStamp 861 392 9408
> 0.1
>
>
> So...for this quick evaluation, maybe we can become compact also the
> following classes for example:
>
> Smalltalk compactClassesArray
>
> #( ByteSymbol ByteArray MethodDictionary "Association" "WeakArray"
> "Metaclass" DateAndTime UUID Time Duration Date "MethodDictionary"
> ClassOrganizer Metaclass Pragma OrderedCollection RemoteString WordArray
> Color Character )
> do: [:each | (Smalltalk at: each) becomeCompact]
>
> Do this make sense ? How could I measure this? I took a Pharo image and
> compare the memory used by the VM running all test before and after those
> new compact classes. From the "Activity monitor" I noticed between 3 and 5
> MB less used with these new compact classes.
>
> Thanks in advance
>
> Mariano
>
>
> On Tue, May 4, 2010 at 2:12 PM, Adrian Lienhard <adi at netstyle.ch> wrote:
>
>>
>> Hi Mariano,
>>
>> I see two solutions
>> - make the identityHash (even) smaller
>> - remove compact classes
>>
>> The former would probably not be hard to implement (just change some bit
>> masks and then rehash all sets). I've brought up the idea about the latter
>> some time ago on this mailing list. The idea is to remove compact classes to
>> get a larger identityHash (trading memory against speed). After the removal,
>> only two header types are left and hence you gain a spare bit. I think this
>> shouldn't be too much work either, but I haven't come around to implementing
>> it (yet).
>>
>> Good luck ;)
>> Adrian
>>
>> On May 4, 2010, at 13:13 , Mariano Martinez Peck wrote:
>>
>> >>>
>> >>> Now...the question is, is there another free bit in the object header
>> ? I
>> >>> need another one :(
>> >>
>> >> Based on the comment at the bottom of Interpreter>>internalIsImmutable:
>> >> I suspect that somebody else has their eye on that last available bit
>> >> also ;-)
>> >>
>> >>
>> > Yes, I know :( But for the moment I don't care to "integrate" my
>> stuff. I
>> > just want to play and experiment. And even for that, I need 2 bits :(
>> > Of course, if I once make something good to integrate, I will have
>> double
>> > problem :(
>> >
>> > So...no solution ?
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100506/ce622b95/attachment.htm
More information about the Vm-dev
mailing list