<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
hm I guess pointers themselves (not where they are stored) need not have any alignemnt?<BR>
We might only have a pointer into an array of bytes to keep the array alive,<BR>
no pointer to the base of the array?<BR>
<BR>
PROCEDURE F1()<BR>
VAR a: ARRAY OF CHAR := NEW(CHAR, 10);<BR>
i: INTEGER;<BR>
BEGIN<BR>
FOR i := FIRST(a) TO LAST(a) DO<BR>
something with a[i];<BR>
END<BR>
END F1;<BR><BR>
might only have pointers to elements in a?<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Mon, 5 Apr 2010 11:55:16 +0000<BR>Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT?<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
Interesting:<BR> <BR>PROCEDURE NoteStackLocations (start, stop: ADDRESS) =<BR> VAR fp : UNTRACED REF ADDRESS := start;<BR> BEGIN<BR> IF NOT (start < stop) THEN RETURN END;<BR> stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *)<BR> WHILE fp <= stop DO (* with the memory read on the next line. *)<BR> WITH page = AddressToPage(fp^) DO<BR> IF page # NIL AND page.desc.space = Space.Previous THEN<BR> IF RTMachine.PointerAlignment = 1 THEN<BR> IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN<BR> RTIO.PutText("pointer found on unaligned stack stack=");<BR> RTIO.PutAddr(fp);<BR> RTIO.PutText(" addr=");<BR> RTIO.PutAddr(fp^);<BR> RTIO.PutText("\n");<BR> RTIO.Flush();<BR> END;<BR> END;<BR> IF page.desc.pure<BR> THEN PromotePage(page, PromoteReason.AmbiguousPure);<BR> ELSE PromotePage(page, PromoteReason.AmbiguousImpure);<BR> END;<BR> END;<BR> END;<BR> INC(fp, RTMachine.PointerAlignment);<BR> END;<BR> END NoteStackLocations;<BR><BR> <BR>generates a fair amount of output:<BR><BR><BR>C:\dev2\cm3.2\m3-sys\mklib>cm3<BR>--- building in NT386 ---<BR>ignoring ..\src\m3overrides<BR>pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f11e addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f186 addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f12e addr=0x1780000<BR>pointer found on unaligned stack stack=0x12f1ba addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f442 addr=0x1460147<BR>new source -> compiling Main.m3<BR>pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000<BR> -> linking mklib.exe<BR> <BR> <BR>I need to look a bit more, see what these values are.<BR> We are probably being way over conservative, on NT.<BR> Such unaligned values as 0x1460147 surely shouldn't count as traced pointers.<BR> This example only has one but usually I see many more.<BR> <BR> <BR>C:\dev2\cm3.2\m3-sys\cm3>cm3<BR>--- building in NT386 ---<BR>ignoring ..\src\m3overrides<BR>pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f642 addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f176 addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f11e addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f12a addr=0x1780000<BR>pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f61e addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f6de addr=0x1900069<BR>pointer found on unaligned stack stack=0x12f43e addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f156 addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f66e addr=0x1400000<BR>pointer found on unaligned stack stack=0x12f72e addr=0x1900069<BR>pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000<BR>pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c<BR>pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142<BR><BR> <BR>All this scanning around in memory the garbage collector has to do, doesn't that kill working set?<BR>It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods?<BR> <BR> <BR> - Jay<BR> <BR>
<HR id=ecxstopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Mon, 5 Apr 2010 11:41:10 +0000<BR>Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT?<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
For the vast majority of platforms:<BR> <BR> <BR>RTMachine.PointerAlignment = BYTESIZE(INTEGER).<BR> <BR> <BR>except 1 for NT386, 2 for M68K (dead).<BR> <BR> <BR> PointerAlignment = BYTESIZE(INTEGER);<BR> (* The C compiler allocates all pointers on 'PointerAlignment'-byte<BR> boundaries. The garbage collector scans thread stacks, but only<BR> looks at these possible pointer locations. Setting this value<BR> smaller than is needed will only make your system run slower.<BR> Setting it too large will cause the collector to collect storage<BR> that is not free. *)<BR><BR> <BR>I suggest this is not exactly true.<BR> 1) Of what relevance is the C compiler? vs. the Modula-3 compiler.<BR> 2) We really think the number is 1 for NT386? <BR> <BR>I understand I could say:<BR>void F(void* traced)<BR>{<BR>#pragma pack(1)<BR> struct { char a; void* p} = {0, traced};<BR>}<BR> <BR>but<BR> 1) That seems highly unlikely.<BR> 2) Do we really anticipate the case where C code is the *only* holder of a traced reference?<BR> 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.<BR> 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location?<BR> <BR> <BR>My real goal is to make there only be one RTMachine for systems that don't have stack walkers.<BR>Leave SOLgnu/SOLsun alone.<BR>(Later on implement stack walking for many platforms via libunwind.)<BR> <BR> <BR>There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)).<BR>There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses.<BR>I can test 64K on others.<BR>Historically smaller is probably more efficient.<BR>These days larger but not *too* large is probably more efficient.<BR>64K should work fine on all platforms. Heck, even something larger like 1MB is probably good.<BR>I'll test out 64K.<BR> <BR> <BR>Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)?<BR> <BR> <BR>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?<BR>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.<BR> <BR> <BR> - Jay<BR> <BR><BR> </body>
</html>