6

Unlike other languages, there seems no allocate or new syntax in Chapel for allocating arrays on the heap, but rather use the usual "declaration"-like syntax. For example, in the following code, I "declare" two arrays A and B in a function based on formal (dummy) arguments:

proc test( n, D )
{
    var A: [1..n] real;  // local array
    var B: [D] real;     // local array

    writeln( "A.domain = ", A.domain );
    writeln( "B.domain = ", B.domain );
}

test( 3, {2..5} );               // request small arrays
test( 10**7, {-10**7..10**7} );  // request large arrays

This gives the following result:

A.domain = {1..3}
B.domain = {2..5}
A.domain = {1..10000000}
B.domain = {-10000000..10000000}

Because no stack overflow occurs (despite the large size of B), is it OK to assume that the above syntax always allocates A and B on the heap regardless of their size?

Also, assignment (or re-assignment) of a domain variable seems to play the role of allocation (or re-allocation) of an array. For example, the following code works as expected. In this case, does the allocation always occur on the heap (again)?

var domC: domain(1);
var C: [domC] real;
writeln( "C = ", C );

domC = { 1..3 };       // assign a domain
C = 7.0;               // assign some value to the array
writeln( "C = ", C );

domC = { -1..5 };      // re-assign a domain
writeln( "C = ", C );

Result:

C = 
C = 7.0 7.0 7.0
C = 0.0 0.0 7.0 7.0 7.0 0.0 0.0

Finally, is it not necessary for the user to deallocate or delete these arrays manually, but rather the system automatically deallocates them as needed?

roygvib
  • 7,218
  • 2
  • 19
  • 36

1 Answers1

4

is it OK to assume that the above syntax always allocates A and B on the heap regardless of their size?

At of Chapel 1.15.0, Chapel array elements are always allocated on the heap. We've discussed adding mechanisms (e.g., custom domain maps) or possibly optimizations that might be used to store arrays' elements on the stack when appropriate, but have not pursued such features yet. Note that while the array's elements are allocated on the heap, arrays also are implemented using a runtime descriptor which is allocated "in-place" (e.g., on the stack in your examples)---this descriptor refers to the heap-allocated elements.

Also, assignment (or re-assignment) of a domain variable seems to play the role of allocation (or re-allocation) of an array.

That's correct, and it's worth emphasizing that this is a logically rather than physically oriented notion of reallocation. Specifically, when an array's domain is reassigned, A[i] will continue to store the same value if i was in both the index sets of the old domain and the new one. This is why when you changed domC from {1..3} to {-1..5} in your code above, A[1..3] was preserved, since it represents the intersection of the two sets.

does the allocation always occur on the heap (again)?

Yes, as with an initial array allocation.

is it not necessary for the user to deallocate or delete these arrays manually, but rather the system automatically deallocates them as needed?

That's correct, array memory management is generally handled by the implementation. A way to manually manage array memory would be to have a class variable with an array field (since classes are manually memory managed).

Brad
  • 3,839
  • 7
  • 25
  • 2
    Thanks very much for your explanations. I think it is interesting that assignment of a domain variable means "resize" of the array (or all arrays associated with the domain), and also the necessary allocation/reallocation is automatically done. Thanks :) – roygvib Jun 06 '17 at 15:12
  • [By the way, the following sentence in the first paragraph "Note that while the array's elements are allocated on the _stack_" might be a typo of "Note that while the array's elements are allocated on the _heap_" ... ? (though it may depend on the context of the explanation)] – roygvib Jun 06 '17 at 15:13
  • Thanks for pointing out the typo which I've fixed. Once domains are in a language, they seem to be the most natural / obvious way to resize an array even though there's a bit of a learning curve to get used to it. – Brad Jun 06 '17 at 15:54