Function types versus arrays
Osvaldo Doederlein
opinali at gmail.com
Tue Feb 9 10:35:36 PST 2010
2010/2/9 Doug Lea <dl at cs.oswego.edu>
> Alex Buckley wrote:
> > Neal raises a fair point. I recognize that arrays of function types are
> > as potentially unsafe at runtime as arrays of non-wildcard parameterized
> > types.
> >
>
> Alternatively, the array botch itself could be addressed
> by creating an efficient Array class tightly coupled
> to the compiler and VM.
>
Any chance JSR-83 could be resuscitated? IBM's "Ninja" project seems to have
mostly solved this and other issues, from my (now very vague) recollection
of their papers. In a more modern setting, the MLVM community is pondering
about enhancements like inline allocation of arrays in tail position (not a
solution for mutable collections, but pretty nice boost for immutable ones -
which is now a strong trend).
> Probably the main challenge is for Garbage Collectors,
> that don't know what to do with giant arrays.
>
Metronome's "arraylets" seem to be a good solution, e.g. not support arrays
at all, with the tradeoff of extra cost for indexing and bulk operations
(but I guess both costs can be greately reduced/amortized for large arrays
by optimizations with good integration to unrolling etc; and not paid for
smaller arrays that fit in a single chunk). Huge arrays will always screw up
with attempts to deliver increasingly better incremental GCs, like G1.
A+
Osvaldo
More information about the lambda-dev
mailing list