At 02:57 PM 3/28/00 -0500, Jordan Henderson wrote:


> > -----Original Message-----
> > From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 28, 2000 2:43 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PATCH] Perl 5.6.0: VMS piping mods
> >
> >
> > At 01:37 PM 3/28/00 -0600, Craig A. Berry wrote:
> > >At 01:52 PM 3/28/00 -0500, Charles Lane wrote:
> > >
> > > >+    I'm using LIB$(GET|FREE)_VM here so that we can
> > allocate and deallocate
> > > >+    inside an AST routine without worrying about
> > reentrancy and which Perl
> > > >+    memory allocator is being used.
> > >
> > >Mixing these with malloc() used to be a no-no; does the fact
> > that you have
> > >them in an AST routine allow you to dodge that restriction?
> >
> > Should we just switch over to the LIB$ memory management
> > stuff altogether?
> > It'd just require some changes to perl's memory allocator.
>
>When you refer to perl's memory allocator are you talking about
>the Ilya Zakharevich malloc.c (answer Y to the question:
>
>Perl has a built-in memory allocator that's tuned for perl's
>normal memory usage. It's oftentimes better than the standard
>system memory allocator. It also has the advantage of providing
>memory allocation statistics, if you choose to enable them.
>
>Build with perl's memory allocator? [n]
>
>)?

Yup. If the C RTL's malloc was suboptimal we could just use perl's, wedged 
to get more memory with the lib$ stuff instead of sbrk.

I kinda want to do that anyway, so as to be able to give memory back to the 
system. It'd be cool to be able to do:

   $#foo = 1000000;
   $#foo=3;

and see memory usage peak then drop again. We could give the Unix folks a 
big "Nyah!" :)

                                        Dan

----------------------------------------------------------------------------
Dan Sugalski                          General and VMS-specific perl training
[EMAIL PROTECTED]
                                      Mail me for more details

Reply via email to