On Sun, Oct 27, 2013 at 11:00 PM, Ben Kloosterman <[email protected]>wrote:
> On Mon, Oct 28, 2013 at 2:55 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> >> The first might be termed "concurrency safety up to memory safety". That >> is: making sure that you don't compile stupidly in such a way that >> concurrency errors lead to memory safety errors. The changing vector base >> pointer example above is an example of this. >> > > On Arm something is needed but im not convinced on x86 except for a few > corner cases. > If I can move a vector reference out from under a bounds check, the problem isn't processor specific, and it *needs* to be done. What I'm saying is: I think we can preserve memory safety, and I think we can give the programmer's management of concurrency some useful assist, but I don't think we can ensure concurrency safety in general. > Yes. That's what MARK-OBJECT is for. It assumes that given a *pointer* to >> an object (remember, we're the GC here), we can locate the marking program. >> Though come to think of it we probably want MARK-TYPE <ty> instead. The >> idea is that we are incorporating the marking program of the other type by >> reference (recursively). So we get programs like: >> >> MARK-WORDS N <bitmap> >> ITERATE N >> >> MARK-TYPE <some-inner-type> >> >> CONTINUE >> >> >> > It will work , it just a bit fragile to me ( pointers in structs > embedded in an non boxed array ) > I'm lost. Where is the pointer-in-struct here? And do you mean pointer or obref? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
