[M3devel] RTMachine.PointerAlignment = 1 on NT?

[Jay K]

hm I guess pointers themselves (not where they are stored) need not have any alignemnt?

We might only have a pointer into an array of bytes to keep the array alive,

no pointer to the base of the array?

 

PROCEDURE F1()

VAR a: ARRAY OF CHAR := NEW(CHAR, 10);

  i: INTEGER;

BEGIN

  FOR i := FIRST(a) TO LAST(a) DO

    something with a[i];

 END

END F1;


might only have pointers to elements in a?

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Mon, 5 Apr 2010 11:55:16 +0000
Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT?



Interesting:
 
PROCEDURE NoteStackLocations (start, stop: ADDRESS) =
  VAR fp : UNTRACED REF ADDRESS := start;
  BEGIN
    IF NOT (start < stop) THEN RETURN END;
    stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *)
    WHILE fp <= stop DO               (* with the memory read on the next line.  *)
      WITH page = AddressToPage(fp^) DO
        IF page # NIL AND page.desc.space = Space.Previous THEN
          IF RTMachine.PointerAlignment = 1 THEN
            IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN
              RTIO.PutText("pointer found on unaligned stack stack=");
              RTIO.PutAddr(fp);
              RTIO.PutText(" addr=");
              RTIO.PutAddr(fp^);
              RTIO.PutText("\n");
              RTIO.Flush();
            END;
          END;
          IF page.desc.pure
            THEN PromotePage(page, PromoteReason.AmbiguousPure);
            ELSE PromotePage(page, PromoteReason.AmbiguousImpure);
          END;
        END;
      END;
      INC(fp, RTMachine.PointerAlignment);
    END;
  END NoteStackLocations;

 
generates a fair amount of output:


C:\dev2\cm3.2\m3-sys\mklib>cm3
--- building in NT386 ---
ignoring ..\src\m3overrides
pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000
pointer found on unaligned stack stack=0x12f11e addr=0x1400000
pointer found on unaligned stack stack=0x12f186 addr=0x1400000
pointer found on unaligned stack stack=0x12f12e addr=0x1780000
pointer found on unaligned stack stack=0x12f1ba addr=0x1400000
pointer found on unaligned stack stack=0x12f442 addr=0x1460147
new source -> compiling Main.m3
pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000
 -> linking mklib.exe
 
 
I need to look a bit more, see what these values are.
  We are probably being way over conservative, on NT.
  Such unaligned values as 0x1460147 surely shouldn't count as traced pointers.
  This example only has one but usually I see many more.
 
 
C:\dev2\cm3.2\m3-sys\cm3>cm3
--- building in NT386 ---
ignoring ..\src\m3overrides
pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000
pointer found on unaligned stack stack=0x12f642 addr=0x1400000
pointer found on unaligned stack stack=0x12f176 addr=0x1400000
pointer found on unaligned stack stack=0x12f11e addr=0x1400000
pointer found on unaligned stack stack=0x12f12a addr=0x1780000
pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000
pointer found on unaligned stack stack=0x12f61e addr=0x1400000
pointer found on unaligned stack stack=0x12f6de addr=0x1900069
pointer found on unaligned stack stack=0x12f43e addr=0x1400000
pointer found on unaligned stack stack=0x12f156 addr=0x1400000
pointer found on unaligned stack stack=0x12f66e addr=0x1400000
pointer found on unaligned stack stack=0x12f72e addr=0x1900069
pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000
pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c
pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142

 
All this scanning around in memory the garbage collector has to do, doesn't that kill working set?
It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods?
 
 
 - Jay
 
  

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Mon, 5 Apr 2010 11:41:10 +0000
Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT?



For the vast majority of platforms:
 
 
RTMachine.PointerAlignment = BYTESIZE(INTEGER).
 
 
except 1 for NT386, 2 for M68K (dead).
 
 
  PointerAlignment = BYTESIZE(INTEGER);
  (* The C compiler allocates all pointers on 'PointerAlignment'-byte
     boundaries. The garbage collector scans thread stacks, but only
     looks at these possible pointer locations. Setting this value
     smaller than is needed will only make your system run slower.
     Setting it too large will cause the collector to collect storage
     that is not free. *)

 
I suggest this is not exactly true.
  1) Of what relevance is the C compiler?  vs. the Modula-3 compiler.
  2) We really think the number is 1 for NT386?  
 
I understand I could say:
void F(void* traced)
{
#pragma pack(1)
  struct { char a; void* p} = {0, traced};
}
 
but
 1) That seems highly unlikely.
 2) Do we really anticipate the case where C code is the *only* holder of a traced reference?
   And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack.
 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location?
 
 
My real goal is to make there only be one RTMachine for systems that don't have stack walkers.
Leave SOLgnu/SOLsun alone.
(Later on implement stack walking for many platforms via libunwind.)
 
 
There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)).
There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses.
I can test 64K on others.
Historically smaller is probably more efficient.
These days larger but not *too* large is probably more efficient.
64K should work fine on all platforms. Heck, even something larger like 1MB is probably good.
I'll test out 64K.
 
 
Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)?
 
 
A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value?
If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone.
 
 
 - Jay
 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100405/e665b2a8/attachment-0002.html>