On Sun, Feb 6, 2011 at 9:44 AM, Patrick R. Michaud <[email protected]> wrote: > Bacek++ fixed TT #1994 so that .INTERPINFO_ACTIVE_PMCS works again > (thanks!); while playing with it I noticed that creating the first > instance of a PMC type such as Integer or Float results in the > creation of 38 extra PMCs somewhere. (Creating the second and > subsequent instances doesn't seem to result in this extra allocation.) > > pmichaud@orange:~/parrot$ cat activepmc-2.pir > .sub 'main' > .include 'interpinfo.pasm' > > sweep 1 > collect > > $I0 = interpinfo .INTERPINFO_ACTIVE_PMCS > say $I0 > > .local pmc a, b > a = new ['Integer'] > $I0 = interpinfo .INTERPINFO_ACTIVE_PMCS > say $I0 > > b = new ['Integer'] > $I0 = interpinfo .INTERPINFO_ACTIVE_PMCS > say $I0 > .end > > pmichaud@orange:~/parrot$ ./parrot activepmc-2.pir > 1173 > 1212 > 1213 > pmichaud@orange:~/parrot$ > > I'm sure that some of the PMCs are being created to support the PMCProxy > instances.... but *38*? That number seems surprisingly high, so I > thought I'd bring it up to the list and see if anyone has any ideas > about why and where so many extra PMCs are being created.
Confirmed, PMCProxy objects are being created. It is interesting to note that of those 38, only 12 persist after a GC run (add the sweep/collect code before the interpinfo query). Of those 12, 8 can be directly accounted for in Class.init() (parent of PMCProxy). That leaves only 4 persisting PMCs unaccounted for. So which of these are we concerned about the most? The 26 contributing to GC churn? The 8 caused by Class being fat? Or the 4 I haven't bothered to track down? > The 38 extra PMCs seems to be per-type; for example, if after > creating the two Integers above I then create a new Float object, > another 38 PMCs get created somewhere. > > Thanks, > > Pm > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
