Re: gcopy_avma() is wasting stack memory compared to gcopy()

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Tue, Jul 04, 2017 at 10:43:44AM +0200, Bill Allombert wrote:
> On Tue, Jul 04, 2017 at 08:11:54AM +0200, Karim Belabas wrote:
> > * Jens Schmidt [2017-07-04 07:47]:
> > > Hello PARI developer.
> > > 
> > > PARI Library Guide (PDF) writes: "GEN gcopy_avma(GEN x, pari_sp *AVMA)
> > > return a copy of x as from gcopy, except that we pretend that initially
> > > avma is *AVMA, and that *AVMA is updated accordingly (so that the total
> > > size of x is the difference between the two successive values of *AVMA)."
> > > I noticed that gcopy_avma() needs more memory (~ 20%-30%) than gcopy()
> > > to create a copy of a GEN object if GEN is of non recursive type, e.g.
> > > t_POL or t_SER. Therefore I've written a shot test function to dissect
> > > the PARI stack.
> > 
> > The difference is due to gen_0: gcopy is allowed to keep (or create) pointers
> > to "universal objects", which need not be copied, whereas gcopy_avma is
> > a low-level function that was used to serialize objects out of a PARI
> > session and thus makes a deep copy of everything. It makes a huge
> > difference for sparse structures.
> > 
> > I am not sure a gcopy_avma with the above semantic [which has never been
> > documented] is useful anymore, it does not seem to be used in the PARI
> > sources any longer; it is present twice: in gclone (where it's
> > definitely not needed) and in the pthread interface (where I *believe*
> > at this point that it's not needed). I'll investigate.
> 
> gcopy_avma is needed for pthread.c, but not with this semantic, since
> the threads share the universal constants, but not the same PARI stack.

I have just found that gcopy_avma in pthread.c was causing problem
because it does not handle stack overflow.

? default(threadsize,"1M")
? my(P=polmodular(101));pareval(vector(10,i,()->P*Mod(1,101)))
  *** polmodular: Warning: increasing stack size to 16000000.
  *** polmodular: Warning: increasing stack size to 32000000.
  ***   Warning: increasing stack size to 64000000.
  ***   at top-level: my(P=polmodular(101));pareval(vector(10,i,()->
  ***                                       ^------------------------
  *** pareval: bug in PARI/GP (Segmentation Fault), please report.

So we need something better.

Cheers,
Bill.