On Mon, Aug 5, 2013 at 12:35 AM, Bennie Kloosteman <[email protected]>wrote:
> You can put reference types in a stack like region and pass around the
> pointer..
> eg
>
> windowSetSize( )
>
> var size = new Size() {...
> var point = new Point() { ...
> var window = new Window() { Size = size , Point = pint ...
> CallMethodUpdateWindows( new List<Window>() {window})
> {
> // do something with size and point
> } // window is out of scope and region will deallocate all
>
> At no stage is the heap needed and window can be a reference type.
>
Yes. But the reason you know this is that you've done the region analysis
that shows it is true. That's part of what region analysis is for!
> And the objects can live on a stack like data structure., You cant do
> this without resorting to value types and unsafe ( to avoid autoboxing) on
> a stack . Also value types being copied cant be large if you pass them
> around , reference types in a region can be.
>
Neither of these statements is true. This isn't unsafe *because* the region
analysis supports what you are saying (that is: assuming the list doesn't
escape).
Terminology: can we please use the terms "unboxed type" and "boxed type"
here? Value type has other connotations.
What I think you mean to be saying is that there is no way to
*explicitly* stack-allocate
an unboxed type *in the CLR*. If it were designed to do so, the JIT engine
is certainly free to perform the region analysis that is necessary to do
what you are describing.
Curiously, doing that wouldn't require *any* changes to the GC (except
perhaps removing a sanity check), *even* if no borrowed pointer type is
introduced. The objects are stack allocated, but are written with the usual
heap headers. If naive copying GC occurs in a lower stack frame, these
objects will be traced in the usual way and copied into new-space
harmlessly.[*] So what you get, even in a naive implementation is "mostly
non-tracing" low-overhead collection. The only reason I mention this is to
point out that this sort of thing can be implemented very incrementally,
with surprisingly low impact on the existing GC infrastructure.
[*] Well, almost harmlessly. The catch is that the space for these
stack-allocated objects has to be accounted against current-space if GC is
naive in this way. If that doesn't happen, then the sum of (surviving old
space live set + stack-allocated and copied objects) might exceed the size
of new space. The simpler solution is to teach the GC to "trust" that an
on-stack pointer is exempt from both copying and tracing.
> Also a region could be controlled and last a long time .. eg you may have
> 2 threads one allocating very slow and another doing lots of reading but
> slowly allocating. In most shared nursery GC s allocations get mixed and
> you will have many nursery collects ( scavanges) interfering with your
> mainly reading thread ( eg cache flushes etc). WIth a region those
> allocations can happen to a seperate heap and the threads runs along and
> when it finsihes a long time later the whole region is just dropped.
>
I agree that you want separate threads to have separate nurseries. That
said, the nurseries aren't associated with any particular let-region
binding. That means you can't reason about the relationship between effects
and nursery lifetimes, which means that you can't use region/effect
analysis to reason about the behavior of the nursery. In short: the nursery
isn't a region in the sense that region analysis uses the term "region".
Where region analysis *can* come into this is *determining* (automatically)
which objects are thread-local and can therefore be allocated from the
thread-local nursery. Without changing the analysis a bit, you can imagine
a region model in which there are *two* region inductions: one for
thread-local objects and the other for shared objects. Each thread-local GC
heap is a sub-region of the general GC heap. Each on-stack thread-local
region is a descendent of the thread-local GC heap. An object can be
allocated into a thread-local region exactly if region analysis says so,
else it is allocated into a non-thread-local region (which, being globally
shared, is quite likely the GC region).
In practice, nearly all shared objects are going to get pushed into the
main GC heap in any case. The co-stack of shared object regions therefore
isn't useful unless you extend this analysis to understand fork/join
semantics.
Laslly even if the benefit of regions themselves is low the analysis which
> pushes more types automatically onto the stack is a win .. since it makes
> the GC heap smaller and uses the faster stack allocation scheme.
>
Umm. Bennie? How do you push those objects on to the stack without doing
the region analysis necessary to know that it is safe?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
