[M3devel] RTMachine.PointerAlignment = 1 on NT?

Tony Hosking hosking at cs.purdue.edu
Tue Apr 6 03:21:03 CEST 2010 

Fair enough.  That says it should be ADRSIZE(ADDRESS).  ;-)


On 5 Apr 2010, at 20:20, Jay K wrote:

> Isn't this kind of "architectural"?
> Like, assumed in a bunch of code, too hard to change, better to adhere to than change?
>   Can continue to write code assuming it.
>  
>  
> Consider AMD64_NT.
> I assume INTEGER there should be 64bits, even though int and long are both 32.
>   Corralary: long shouldn't be used for anything, ever.
>   int is 32 bits, always; ignoring old systems  
>   INTEGER is pointer size, always (the question here) 
>   long is sometimes 32 bits, sometimes pointer size, but neither is always true, on modern systems
>      If you consider Win64. If you ignore Win64, then, yes, I realize, long is always a pointer.
>   The types to use in C for pointer sized integers are size_t and ptrdiff_t.
>  
>  
> For that matter..BYTESIZE and ADRSIZE, they are always the same and will always be, right?
> "All machines are byte-addressable", these days and forever more?
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 5 Apr 2010 19:44:02 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT?
> 
> Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS).  But that's all of ours.
> 
> On 5 Apr 2010, at 18:03, Jay K wrote:
> 
> Yes. Same thing.
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Mon, 5 Apr 2010 13:31:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT?
> 
> More accurately, BYTESIZE(ADDRESS)?
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 5 Apr 2010, at 10:40, Jay K wrote:
> 
> I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER).
> NT386 is the only current exception.
> Even though it isn't required, of any x86 target, it seems the overwhelming practice.
>  
>  - Jay
>  
> Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT?
> From: hosking at cs.purdue.edu
> Date: Mon, 5 Apr 2010 10:25:20 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters.  So, the pointer values from the stack themselves need not be aligned.  The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack.  Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations.
> 
> 
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 5 Apr 2010, at 08:03, Jay K wrote:
> 
> 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/1dff2d21/attachment-0002.html>

More information about the M3devel mailing list