[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-win32-porters
Subject:    Re: Which malloc scheme is best on Win32?
From:       Steve Hay <steve.hay () uk ! radan ! com>
Date:       2004-07-16 8:20:42
Message-ID: 40F78FDA.1050601 () uk ! radan ! com
[Download RAW message or body]

Nick Ing-Simmons wrote:

> Steve Hay <steve.hay@uk.radan.com> writes:
> 
> 
> > (I realise that memory is not actually being used by the 
> > VirtualAlloc() call that reserves a big block, but presumably it still 
> > isn't very friendly -- you wouldn't want too many programs on your 
> > machine all playing that game.)
> > 
> > 
> 
> As each process gets its own address space it doesn't matter how many do.
> 
Oh - I hadn't realised that.  I'm still a little wary of increasing the 
64MB number, though, because even asking for say 128MB would presumably 
be quite likely to fail on a low-end machine which only has, say, 128MB 
RAM (plus maybe as much again disk-based VM)?

Perhaps a scheme to try for some large amount first and then fallback, 
trying successively smaller amounts until it succeeds, could be worked 
out, but I'll leave that for now.

> 
> 
> 
> > Looking at some of the comments in malloc.c, it looks like Perl's malloc 
> > may well no longer require contiguous memory, so I've had a go at 
> > tweaking Win32's sbrk() to make use of that fact.
> > 
> > The attached patch (against blead) makes sbrk() initially try to extend 
> > the existing block of memory exactly as it currently does, but to not 
> > fail immediately if it can't -- it now frees up that part of whatever it 
> > had previously reserved+committed which hadn't actually been used yet, 
> > resets all its static variables and basically starts anew.
> > 
> > 
> FWIW your changes look fine, and as they only apply to perl's malloc
> (which isn't used by ActivePerl at present) IMO this patch could 
> be committed to blead. Do you have rights to do that or should I ?
> 
I do not have rights, so go ahead!

(I did post a question to p5p (as you've probably seen) enquiring 
whether Perl's malloc really is safe with non-contiguous address space.  
It seems to be working so far, but I could just be striking lucky.  It 
might be worth waiting to see if anyone replies to that first?)

> 
> For this approach to go mainstream then some way of handling 
> multiple threads needs to happen.
> 
Yeah, I saw some comments in win32.c against the file-statics that 
sbrk() uses.  Do you know if that's the only reason that Perl-malloc 
can't be used with ithreads on Win32, or are there other problems too?  
You mentioned each process gets its own address space; does each thread 
within a process, or do they have to share space?  Is Perl's malloc 
itself thread-safe?

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are \
confidential and intended for the addressee(s) only.  If you have received this \
message in error or there are any problems, please notify the sender immediately.  \
The unauthorized use, disclosure, copying or alteration of this message is strictly \
forbidden.  Note that any views or opinions presented in this email are solely those \
of the author and do not necessarily represent those of Radan Computational Ltd.  The \
recipient(s) of this message should check it and any attached files for viruses: \
Radan Computational will accept no liability for any damage caused by any virus \
transmitted by this email.

_______________________________________________
Perl-Win32-Porters mailing list
Perl-Win32-Porters@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs


[prev in list] [next in list] [prev in thread] [next in thread]