630154 - Annotations for VTable and ExceptionHandlerTable should be hinting about small tables

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect)

Description

[Lars T Hansen]

It's exceedingly likely that these tables will never be "large".  A simple pointer table needs 500 elements (250 on 64-bit) to be "large"; that many methods is probably almost unheard of.   The exception handler table has three words per entry but still needs to be 167 entries on a 32-bit system, ie, 167 exception handlers in a signle function; also unlikely.

Both might might happen in generated code, I suppose, but even if they do, the penalty of scanning the objects atomically would be small.

Comment 1

[Lars T Hansen]

Actually an ExceptionHandlerTable entry is two pointers and three int32's so 20 bytes on 32-bit systems and 28 (probably 32) on 64-bit systems.  With 2000 bytes as the cutoff that yields 100 elements on 32-bit systems and 62 on 64-bit systems.  Still quite high.

Not that that matters.  The generated scanner code uses 2000/sizeof(void*) as the measure on all platforms, it does not take the size of the substructure into account at all.  So the cutoff is uniformly 500 elements on 32-bit systems and 250 on 64-bit systems.

Comment 2

[Lars T Hansen]

Attachment: Output of a Brightspot run (May 2009)

Data were gathered by inserting 

  printf("METHODCOUNT %u\n", (unsigned)methodCount);

just before the end of TraitsBindings::TraitsBindings and then running -Dverifyonly on all ABC-containing swfs in the data set, capturing, sorting, and counting the resulting output.

The counts are probably approximate at best; it looks like TraitsBindings can be constructed multiple times for the same vtable during a run.  So divide by 2 mentally, at least.

Most popular sizes (count on the left, number of methods on the right):

102611 METHODCOUNT 173
105118 METHODCOUNT 33
107171 METHODCOUNT 31
142350 METHODCOUNT 22
164822 METHODCOUNT 13
171190 METHODCOUNT 26
173281 METHODCOUNT 15
176398 METHODCOUNT 11
181769 METHODCOUNT 19
188060 METHODCOUNT 20
194439 METHODCOUNT 27
214343 METHODCOUNT 14
214592 METHODCOUNT 23
222340 METHODCOUNT 28
241789 METHODCOUNT 8
248410 METHODCOUNT 25
255681 METHODCOUNT 29
327850 METHODCOUNT 10
331032 METHODCOUNT 35
342880 METHODCOUNT 4
490867 METHODCOUNT 9
585229 METHODCOUNT 7
930069 METHODCOUNT 6
1306178 METHODCOUNT 0
8606160 METHODCOUNT 5
13415958 METHODCOUNT 3

Biggest:

  11 METHODCOUNT 818
   5 METHODCOUNT 824
   5 METHODCOUNT 826
   2 METHODCOUNT 844
   2 METHODCOUNT 866
   2 METHODCOUNT 876
   2 METHODCOUNT 878
   2 METHODCOUNT 879
   2 METHODCOUNT 889
   2 METHODCOUNT 907
   2 METHODCOUNT 912
   2 METHODCOUNT 968
   2 METHODCOUNT 1032
   2 METHODCOUNT 1060
   2 METHODCOUNT 1082
   2 METHODCOUNT 1138
   2 METHODCOUNT 1262
   2 METHODCOUNT 1284
   2 METHODCOUNT 2488

That's a whopper of a vtable.  I hope it's used for something good.

Comment 3

[Lars T Hansen]

Based on this, vtables larger than 250 elements constitute 0.06% of the vtable population.  Still, when they get big they get big.  I think keeping the large-object scanning logic for vtable makes sense, we should create a test case that gives us the necessary code coverage (as would many runs of flash content, clearly).

Comment 4

[Steven Johnson]

I'd like to decompile that 2488-element swf to see what's what...

Comment 5

[Lars T Hansen]

I did another run, logging the file names.  The output, at 56MB uncompressed, is a little too much to include here, but here is the tail:

   2 METHODCOUNT 818 ./B/3/U/j/@/B3uj@TokMYtnsT+ClzdcjfA1gtj2SV8TkedFJkmOdz8=
   2 METHODCOUNT 818 ./H/A/t/G/E/HATGE0ah+jE5o32GDtkmMqoT3s9MF5AzZxQWd6rJZvQ=
   6 METHODCOUNT 818 ./J/Q/z/Q/S/JQzQSDhuQGLmsVpDt@7PWBUdMa7kMiRUAsCqpRsN9bQ=
   2 METHODCOUNT 824 ./R/W/E/0/a/rwe0aQOmxdh6JHJct9UN41KgODwuPNFoG3I0jKaLlkg=
   3 METHODCOUNT 824 ./g/E/Z/U/g/GEZUgYHq6KS7hq@HT9Ah2aD236aM3KrB0NU6XDDozGU=
   2 METHODCOUNT 826 ./B/3/U/j/@/B3uj@TokMYtnsT+ClzdcjfA1gtj2SV8TkedFJkmOdz8=
   2 METHODCOUNT 826 ./H/A/t/G/E/HATGE0ah+jE5o32GDtkmMqoT3s9MF5AzZxQWd6rJZvQ=
   2 METHODCOUNT 844 ./J/J/V/L/U/JjvLUoONTRp59BrjE9jS3wRmlrXCa2bXdiS1@vVEI8g=
   2 METHODCOUNT 866 ./p/+/E/n/I/P+enIDtCm5pKS35CB6+Pe8HKajUmrDUmfW@hqHnMjCo=
   2 METHODCOUNT 876 ./y/3/E/l/0/Y3el056ovXJLb0YBYRVAn29H@QEsftnfycI@jISZOCQ=
   2 METHODCOUNT 878 ./Q/o/7/3/6/qO736uRL20WZfvX+yrzvbqMv48E6GWkqHddowFiI0jw=
   2 METHODCOUNT 879 ./2/g/i/P/@/2giP@bZuW0cFfWXUUoxyIFsgECfCX6sPNo@9Rkvhva0=
   2 METHODCOUNT 889 ./o/@/4/y/X/O@4yXhJgwyp03EFLYhI4GAuHB4c2+5EGNMWPOCtNYNA=
   2 METHODCOUNT 907 ./X/J/n/Q/c/XjnQcJ4MtFXQQ@vNpNbyefbFqVn14efQZu8M5@tIfkM=
   2 METHODCOUNT 912 ./M/c/X/l/l/MCXll1u+YP++PEVcHuhPCDjsaUEmjRpopfzdOCnvJRI=
   2 METHODCOUNT 968 ./9/k/7/T/x/9K7TxOOQw01yE5Y6hX9DlbfBkqM0ic@atrI3SFl52+E=
   2 METHODCOUNT 1032 ./F/B/0/4/S/Fb04SQnRshiOjkM4AsNzB@NO9JGb2xeekMkEL+GAzhA=
   2 METHODCOUNT 1060 ./n/X/x/A/r/NXxArAARRe88S057UnaHaKYNgJ+xAljbWEdGyE@Gr+M=
   2 METHODCOUNT 1082 ./B/X/p/Y/z/BXpYzM+uweEdUr05ARus2P3sHO38B42FBocWkzEkCKA=
   2 METHODCOUNT 1138 ./d/p/n/S/r/DPNSr0Pm9HLxJrx5Sv1KBIb7q7JPEKZW8EGNKZ0vHSE=
   2 METHODCOUNT 1262 ./o/n/c/F/J/OnCFJTT3xTZ+@SsqM5W5tBlw7eFHiBdxub2PRTY+2OQ=
   2 METHODCOUNT 1284 ./S/S/p/P/W/sSPPWAxOAjGW25+gUoK3w1rgMs7oc+vZQIWTjwEjgsM=
   2 METHODCOUNT 2488 ./X/y/y/M/R/XyyMRZRToGwcTptDC7@Myx5zWHB94nA6hIclijUEym8=

Comment 6

[Lars T Hansen]

Attachment: method signatures from abcdump, for "the big one"

Comment 7

[Lars T Hansen]

Attachment: And the next one

The commonality between these two is that many of the methods in question are obviously machine generated, one per frame for some timeline/movie.

Comment 8

[Lars T Hansen]

BTW:

swfcontents% (for i in $(cat abcfiles.txt) ; do ~/work/tamarin-redux-clean/platform/mac/avmshell/build/Release_Debugger/avm -Dverifyonly ~/work/flashruntime/flashruntime-redux/build/mac/int/FlashPlayer/as/avmglue.abc $i | grep METHODCOUNT | awk "{ print \$0, \"$i\" }" ; done ) | sort -k2 -n | uniq -c > methodcounts.txt

Comment 9

[Lars T Hansen]

Attachment: One function body

(In reply to comment #7)
> Created attachment 509723 [details]
> And the next one
> 
> The commonality between these two is that many of the methods in question are
> obviously machine generated, one per frame for some timeline/movie.

And for "the big one" at least some of the methods are far from empty, they're actually fairly large with large namespace sets and RTName lookup, joy.  Attaching a sample.

Comment 10

[Lars T Hansen]

Nobody cares.