[MLton-devel] allocating space for IntInf primitives

[Stephen Weeks]

> > 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.

I disagree that it is broken and that the limit check pass does this.
An IntInf primitive is turned into a CCall by SsaToRssa, and the
Transfer.caseBytes function (line 96) of limit-check.fun handles
those.  So, I don't see any problems with what is currently done.

> I don't have any strong disagreement to changing the IntInf stuff
> back to the old style, but I claim that unless it is hard, it is
> probably better to initially allocate all IntInf's in the nursery.
...
> Still, I really think that even big bignums are short lived, usually
> they are intermediate results which are going to go dead almost
> instantly.

Makes sense.  Bignums stay in the nursery.  This might cause us to do
a little bit of rethinking someday with *really* big bignums >100M,
since anything allocated in the nursery requires double the space (for
the gc copy).  But I'm willing to punt on that for now.

> 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);

This seems like a good approach to me.  I'm not sure if it's worth
changing from the current approach since I've no been convinced to
keep bignum allocation in the nursery.  Following "if it ain't broke,
don't fix it", I think probably not.


-------------------------------------------------------
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