I'm talking about allocating a large array of some particular object type
> and then doling out interior pointers as the objects are allocated. It's an
> array of objects, not an array of allocators.
>
>

I just see large array and allocator as normal reference objects (Or a
container with struct allocator and a reference to the array) , what do you
get by using value types and non boxed array  ?. I agree with your earlier
point that large embedded arrays serve little purpose.



> ... Linux kernel is whole program and very few apps will reach that scale.
>>
>
> Linux is not compiled whole program. It is compiled one source unit at a
> time.
>
>

Pretty sure you could in theory compile all those files to LLVM IR  ( if
not for some not c compliant code) . Combine all the bc files ( with
llvm-link) and do whole program  optomization / passes like the Bartok
stack checks.   ( im excluding modules as the kernel alone is big enough
IMHO to qualify as scale ) .  It wouldnt change anything about Linux if
this was done..

It is an issue with more advanced type systems which create a dependency
chains but you can still do a pass on the IR  provided the code is  loaded
at  startup   ( Including shared code available as IR/CIL). What you cant
do is parse any already compiled as binary.  .NET has no concept of a DLL -
an assembly is ( normally) loaded at start  and shared only within the same
.NET domain ( which means in practice its not shared in memory at all  ,
however it is "shared" between developers and apps)  .

For whole program passes like this  it doesnt matter if its compiled with a
JIT or whole program  only that there is some intermediate form which can
express components. And in some cases  ( like stack )  you need to identify
the entry points ( syscalls for a kernel)

Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to