On Mon, Oct 28, 2013 at 2:55 AM, Jonathan S. Shapiro <[email protected]>wrote:
> On Sat, Oct 26, 2013 at 11:12 PM, Ben Kloosterman <[email protected]>wrote: > >> On Sun, Oct 27, 2013 at 1:41 AM, Jonathan S. Shapiro <[email protected]>wrote: >> >>> The more complex case is when arrays appear within heap objects, and the >>> array element type contains references. In that case you're going to need >>> to generate a /this/pointer into the array interior, which is an inner >>> reference. There are a variety of ways to handle this particular case >>> without going to fat pointers, but it's a nuisance. Also, you can't always >>> rely on a dominant live reference unless the compiler is really careful. >>> Consider: >>> >> >>> for(int i = 0; i < ar.Size(); i++) { >>> >>> > 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. > > The second is "concurrency safety assist", in which the programmer is > enabled and required to state their intent. The intent may still be wrong, > but at least we can confirm that the intent was implemented. So, for > example, I don't know how to test in the general case that a program is > deadlock free from a static compiler. I *may* know how to provide > language-level annotations that say things like "that lock needs to be held > before this field can be touched" and check that they are honored. > > That doesn't come close to solving the whole problem, but I think it would > be a step forward. And then we can build higher-level library constructs on > that base. > Im not talking about what can be done but what exists now so i dont think im wrong . This is a very hard problem for a compiler to solve you can reduce it but not resolve it. If your language / compiler can reduce it i have no issues .. I do have an issue in making a promise , bearing a signficant cost of it at runtime , and then it failing requiring a lock and your paying a cost for what is single threaded. Extending immutable support obviously helps and I like foreach and other such constructs ( eg i specifically mention when to lock is an area that we can do a lot better at ) . Maybe even something like private concurrent Node rootnode; // only valid on private and cant create a property can use in for loop must use foreach etc. concurent numeric types are accessed via interlock etc. I was going to say there is less multi threading in user application ( few statics in web server user code , nodejs , actor/Disruptor etc etc ) but this is not true for the systems and lower level libs themselves just the user code . It does mean our constructs should focus on tools for system progammers not line programmers . > > > >> There are a bunch of DPF-like mechanisms we can use for this. The >>> general idea is that the bitmap becomes an instruction stream in a "marker >>> language". The opcodes are: >>> >>> MARK-WORDS N <bitmap> >>> ITERATE N <instructions> CONTINUE >>> MARK-OBJECT // mark object pointed to by the GC cursor using its >>> marking program >>> >>> That ought to be about all you need. >>> >> >> Dont you need recursion to handle a tree of diffirent sized value types >> some of which have references ? >> > > 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 ) so may have consequences and i dont think its worth it for a rare case. ( Use a ref object if you really want to do this an embedded array of ref types is very usefull ) Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
