<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> > How bad/unportable was it the previous way, the VM-synchronized way?<BR>> <BR>> Not compatible with system threading.<BR><BR>
<BR>
Really? NT386 wasn't VM-synchronized back in 3.6, 4.1, etc.?<BR>
Or only with great cost?<BR>
I have to admit, those old import .libs, kernel32.lib, etc. I didn't realize what was in them when I deleted them. I thought they were just regular import .libs.<BR>
I think I got luckly in that the overlap between me deleting them and you removing VM-synchronized GC was small or zero.<BR>
<BR>
<BR>
> You should *never* access a field in the heap in C code! All <BR>> accesses to traced fields in the heap must take place in Modula-3. <BR>> Otherwise things will break! C wrappers should not do anything other <BR>> than forward calls to C library calls. They should not perform heap <BR>> accesses.<BR><BR>
<BR>
Ok, that makes sense.<BR>
Important "out" is the accessing stack is always ok.<BR>
But this is a requirement I didn't keep in mind.<BR>
Now, luckily, the C wrappers are all relatively thin and not difficult<BR>
to re-review in their entirety.<BR>
<BR>
<BR>
But, take for example "open".<BR>
The first parameter to it is bound to be in the heap.<BR>
<BR>
<BR>
But probably it is untraced or somehow ok, since it does<BR>
come from a module used primarily for C interop.<BR>
<BR>
<BR>
And, the line between C wrappers and the "C library" that they forward to<BR>
does not exist.<BR>
If I, say, pass a VAR to a VAR..no check is made?<BR>
Important to declare extern/C functions as taking UNTRACED REF and not VAR?<BR>
<BR> <BR>
> I think you are confusing incremental and incremental GC.<BR>You assume I understand more than I do (I assume you have a typo. :))<BR>
<BR>
<BR>
"generational" -- the concept that most objects die young.<BR>
(aka most objects could have been allocated on the stack...)<BR>
<BR>
<BR>
But does that imply detailed implementation choices, or is just like a "guiding principle"?<BR>
I guess it implies the heap is split into at least two generations, old and young.<BR>
Though I guess in reality there is a range of young, less young, lesser young, least young, etc.<BR>
<BR>
<BR>
And that has objects age, they should be moved from young to old heaps, and references to them either updated right away, or "caught" upon use and updated then...something like that.<BR>
<BR>
<BR>
"incremental" -- don't pause the world..<BR>
<BR>
<BR>
- Jay<BR></body>
</html>