[llvm-dev] RFC: alloca -- specify address space for allocation

[Swaroop Sridhar via llvm-dev]

>> On 08/28/2015 09:30 PM, Swaroop Sridhar wrote:
> > Yes, eventually we'll need to differentiate between:
> > (i) Pointers to unmanaged memory -- which will never be reported to
> > the runtime
> > (ii) Pointers to GC-heap objects -- which will always be reported to
> > the runtime
> > (iii) Generic managed pointer -- which may need to be reported if we
>>  cannot establish that it points outside the GC heap.
> >
> > Currently we report all pointers to the runtime as managed pointers.
> > This is inefficient because the GC then needs to do extra work to figure out
> > what kind of pointer it is:
> > Pointer to a heap object, pointer within a heap object, or outside the heap.
>
> Side note: One of the things that's really bugging me is that you seem to be
> optimizing for work performed by the collector at safepoints.  My mental
> model is that safepoints are infrequent and that a minor amount of
> additional work at the safepoint doesn't really matter.  What am I missing
> here?  Polling for a safepoint has to happen pretty frequently, but we don't
> need to parse the stack unless we actually call into the collector right?

Wrt the impact of the GC-time on performance , just wanted to add that 
this really depends on the workload. We've seen some workloads 
(ex: compiling large projects using a compiler written in managed code) where 
the GC-time was a significant portion of the overall execution time. 
In some benchmarks, the particular issue of precisely reporting 
(iii) managed pointer vs (ii) object pointer in the GCTables did impact performance.

Anyway, we'll use the conservatively correct method of reporting all Gc-pointers 
as (iii) generic managed pointers for bring-up. We can come back to 
the distinction between (ii) and (iii) while tuning the performance.

Thanks,
Swaroop.
.