I suggest that you are trying to impose “C-like” thinking to this problem, when there might be a much cleaner way to do it...

Fuhgeddabout storage allocation. Fuhgeddabout “fixed contiguous blocks of storage of some certain size.” Instead, imagine that what you call “a multi-dimensional array which will contain a lot of nulls” is simply an opaque storage-container (class) which accepts a list as the key which it uses to look for a particular value within itself.

Such a storage-container can, conceptually, be built using a Perl hash. The list is converted to a key which is used to determine if a matching key in the hash. If so, the value is returned; if not, undef. Null values do not ever need to be stored, and if you know that the container will contain a preponderance of nulls (that is to say, the structure is sparse), you don't waste any storage on them.

Why is this “important?” Why am I advocating using an “inefficient” storage-method like hashing? Answer: because memory is virtual. Large fixed-size arrays have a very large “footprint,” and that means they either acquire large working-sets (as seen by the virtual memory manager) or they start getting penalized buried-in-the-ground by page faults.