On 10 January 2014 05:27, Jonathan S. Shapiro <[email protected]> wrote: > On Wed, Jan 8, 2014 at 11:20 PM, William ML Leslie > <[email protected]> wrote: > >> >> I should ask, before I start thinking about the valid 'fixes': a little >> while ago, I was thinking about the class of region problems where we could >> insert the equivalent malloc/free calls and knew that we didn't need a >> collection pass. There's even a class of region problem where we can do >> bump allocation on a gcless heap. Assuming that such cases don't lead to >> additional code paths in the presence of region polymorphism, are those >> techniques you wanted to consider? > > > I'm actually not aware that either of these is possible.
Hmm, I actually thought that MLKit did the former in some cases. Maybe it's something I looked at once and never got around to polishing, or a misunderstanding I had. It does allocate small regions of known-size on the stack, but that's not the situation I was thinking of. > Regions don't really facilitate bump allocation, because regions r1 < r2 can > be simultaneously live and in scope, and allocation can proceed in either. > The regions are nested, but the allocations are not. If you are familiar > with GCC: regions are not obstacks. But you may be able to select, for a given (dynamic) region r1, another region r2: r1 < r2 and nothing is allocated into r1 before r2 dies, which we can know from the effect type. In this case, we can continue the bump allocation used in the allocator backing r2's heap, and simply restore its allocation pointer when we're done with r2. I think this condition becomes quite hard to detect in the certain cases of region polymorphism. > I'm also not familiar with any region analysis that makes it safe to insert > explicit calls to free. Either the region is live, in which case we cannot > free it explicitly, or it is dead, in which case there is no need to free it > at the source code level. I meant that the compiler could insert the call to free. The hope is that most values don't need to live in any managed heap. After a fair bit of reading, I don't think I discovered this in one of the ENS papers at all. Perhaps I imagined it. The appearence of region variables within types in The Effect Typing Discipline /looks/ to give enough information for you to be able to describe this condition, but there are a number of perfectly reasonable cases that suggest otherwise. In fact, it probably requires introducing notions of relavant and parametric affine region qualifiers in order to infer the ability to destructure and destroy such values. Nevertheless, de-allocating entire dynamic regions at once probably gives better overall performance. I'll keep trying to figure out where I got this idea from, and otherwise, probably implement it myself. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
