[M3devel] [M3commit] CVS Update: cm3

Fri Jun 8 00:23:11 CEST 2012

Admittedly it's been a while since I looked at this.

I think what's going on is that they used some sort of topological
sorting in SRC M3, which was broken by Critical Mass.

The reason for the slowdowns is clear if you study the following code
for IsSubtype.

PM3:

PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN =
  VAR t := Get (b);
  BEGIN
    IF (a >= RT0u.nTypes) THEN BadType (a) END;
    IF (a = 0)            THEN RETURN TRUE END;
    RETURN (t.typecode <= a AND a <= t.lastSubTypeTC);
  END IsSubtype;

CM3:

PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN =
  VAR t: RT0.TypeDefn;
  BEGIN
    IF (a = RT0.NilTypecode) THEN RETURN TRUE END;
    t := Get (a);
    IF (t = NIL) THEN RETURN FALSE; END;
    IF (t.typecode = b) THEN RETURN TRUE END;
    WHILE (t.kind = ORD (TK.Obj)) DO
      IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END;
      t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent;
      IF (t = NIL) THEN RETURN FALSE; END;
      IF (t.typecode = b) THEN RETURN TRUE; END;
    END;
    IF (t.traced # 0)
      THEN RETURN (b = RT0.RefanyTypecode);
      ELSE RETURN (b = RT0.AddressTypecode);
    END;
  END IsSubtype;

Now let's take a peek at Typecase (it is emitted by the compiler for SRC and P M3!)...

PROCEDURE ScanTypecase (ref: REFANY;
                        x: ADDRESS(*ARRAY [0..] OF Cell*)): INTEGER =
  VAR p: UNTRACED REF TypecaseCell;  i: INTEGER;  tc, xc: Typecode;
  BEGIN
    IF (ref = NIL) THEN RETURN 0; END;
    tc := TYPECODE (ref);
    p := x;  i := 0;
    LOOP
      IF (p.uid = 0) THEN RETURN i; END;
      IF (p.defn = NIL) THEN
        p.defn := FindType (p.uid);
        IF (p.defn = NIL) THEN
          Fail (RTE.MissingType, RTModule.FromDataAddress(x),
                LOOPHOLE (p.uid, ADDRESS), NIL);
        END;
      END;
      xc := LOOPHOLE (p.defn, RT0.TypeDefn).typecode;
      IF (tc = xc) OR IsSubtype (tc, xc) THEN RETURN i; END;
      INC (p, ADRSIZE (p^));  INC (i);
    END;
  END ScanTypecase;

     Mika

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>
>--Apple-Mail=_37D33CA3-82A5-4037-BFBC-40CEE6E0DADD
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=us-ascii
>
>I've worked with both runtimes at this level (but not lately). And I =
>can't think of one reason why this would be correct. (It does not make =
>me right, I know:). Structures are equivalent, IIRC, primary difference =
>being in algorithm. Incremental RTLinker operation results in possible =
>reallocation of type structures (bottom of the world, =
>you-are-the-wizard-if you-read-this), but they are still "static" for =
>the most of (99.999..%) process lifetime.
>
>Question is important and I am sure it is fixable, if only we can =
>identify problem here. There is nothing inherent to ability for dynamic =
>loading demanding bad data structures at the botom of M3 world. Only =
>(not-improbable) sub-optimal decisions made by cmass people at the =
>moment.=20
>
>On Jun 7, 2012, at 10:35 PM, Mika Nystrom wrote:
>
>> Sorry, "static" was (slightly) the wrong word.
>>=20
>> I believe they are malloced as an array during program startup.  There =
>is
>> something significant about the ordering of this array, which is why =
>you
>> can't just add types to the PM3 environment during runtime.  CM3 uses
>> more indirection, so it's much easier to add things while running,
>> but it also makes TYPECASE, ISTYPE, etc., slower.  Possibly NARROW
>> (explicit as well as implicit) as well...
>>=20
>>     Mika
>
>
>--Apple-Mail=_37D33CA3-82A5-4037-BFBC-40CEE6E0DADD
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=us-ascii
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I've =
>worked with both runtimes at this level (but not lately). And I can't =
>think of one reason why this would be correct. (It does not make me =
>right, I know:). Structures are equivalent, IIRC, primary difference =
>being in algorithm. Incremental RTLinker operation results in possible =
>reallocation of type structures (bottom of the world, =
>you-are-the-wizard-if you-read-this), but they are still "static" for =
>the most of (99.999..%) process lifetime.<div><br></div><div>Question is =
>important and I am sure it is fixable, if only we can identify problem =
>here. There is nothing inherent to ability for dynamic loading demanding =
>bad data structures at the botom of M3 world. Only (not-improbable) =
>sub-optimal decisions made by cmass people at the =
>moment. <br><div><br><div><div>On Jun 7, 2012, at 10:35 PM, Mika =
>Nystrom wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
>type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
>separate; font-family: Helvetica; font-style: normal; font-variant: =
>normal; font-weight: normal; letter-spacing: normal; line-height: =
>normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
>text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Sorry, =
>"static" was (slightly) the wrong word.<br><br>I believe they are =
>malloced as an array during program startup.  There is<br>something =
>significant about the ordering of this array, which is why you<br>can't =
>just add types to the PM3 environment during runtime.  CM3 =
>uses<br>more indirection, so it's much easier to add things while =
>running,<br>but it also makes TYPECASE, ISTYPE, etc., slower. =
> Possibly NARROW<br>(explicit as well as implicit) as =
>well...<br><br>    Mika</span></blockquote></div><br><=
>/div></div></body></html>=
>
>--Apple-Mail=_37D33CA3-82A5-4037-BFBC-40CEE6E0DADD--