[MLton-devel] allocating space for IntInf primitives

[Matthew Fluet]

> Earlier this year, we changed IntInf primitives that return an IntInf
> result so that instead of taking an array in which to store the
> result, they took a number of bytes needed, which the limit check pass
> inspected to ensure that that amount of space was available at the
> frontier.  

Which, by the way, has been completely broken since the Jul. 6 checkin
that eliminated Prim.bytesNeeded function and rewrote limit-check.fun to
only account for array and object allocations.

> * With the generational GC, allocation of arrays (large chunks of
>   memory) is no longer as simple.  Large arrays are allocated in the
>   old generation, not the nursery.  Currently, IntInfs are allocating
>   everything in the nursery -- I think it would be better to mirror
>   the allocation of arrays.

Then I would propose adding to gc.c the following:

typedef enum {...} GC_allocationLoc;
pointer GC_blockAllocate (GC_state s, W32 bytesNeeded, 
                          GC_allocationLoc* loc);
void GC_blockResize (GC_state s, W32 bytesUsed,
                     pointer block,
                     GC_allocationLoc loc);

and implement GC_allocateArray and IntInf allocations in terms of the
above.  In particular, GC_blockAllocate would choose the right generation
for a given sized allocation.  GC_allocateArray wouldn't need to resize
the allocated block. IntInf allocations would resize to adjust the
appropriate frontier.  The GC_allocationLoc is kind of arbitrary.  The way
the GC stands right now, a couple of simple pointer comparisons would
allow you to figure out which generation the block was allocated in and
adjust the right pointers.  But, if we expected more complex GC stuff,
then some abstract bit of information that could be passed back to the
resizing code could help. 

> * The current implementation complicates space profiling, because more
>   pieces of code need to know about how stuff is allocated.

What do you think needs to know about how stuff is allocated?  There is a
question of accuracy.  No matter how we handle IntInf's, if you want to
know exactly how much a given IntInf operation actually used, then you
need to specially handle IntInf's.  If you just care about the maximum
bytes potentially allocated by the operation, then GC_blockAllocate and
Prim.bytesNeeded would give you exactly the same information as just
having array allocations around.

> The only problem with the old scheme, IIRC, was that we had problems
> with rolling back the frontier if allocation had occurred between the
> array allocation and the IntInf primitive.  I propose to solve that
> problem by having the rollback check if allocation has occurred, and
> if so, to fill in the gap at the end of the array with a bogus object
> instead of rolling back.

I don't think a rollback check in IntInf code would be any simpler than
the above.  



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel