Message-Id: <200005091512.LAA08290@qnx.com>
Subject: Re: Perfomance of gc-simple
To: djgpp-workers AT delorie DOT com
Date: Tue, 9 May 2000 11:11:54 -0400 (EDT)
From: "Alain Magloire" <alain AT qnx DOT com>
Cc: eliz AT is DOT elta DOT co DOT il
In-Reply-To: <200005091256.IAA24973@envy.delorie.com> from "DJ Delorie" at May 09, 2000 08:56:40 AM
X-Mailer: ELM [version 2.5 PL0b1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Bonjour

> 
> > > Note that ggc-page also uses /dev/zero, which djgpp doesn't have.
> > 
> > This should be easy to provide via an FSEXT.  If the code is private
> > to GCC sources, none of the complications with using FSEXT in the
> > library apply.
> 
> Cygwin has /dev/zero, and it fails anyway.  I suspect there's some
> subtle functionality in /dev/zero that I didn't emulate right.  If we
> add /dev/zero to djgpp, it needs to be tested well, and it needs to
> work *right* or it will cause subtle problems.
> 
> > > Or, it needs to be able to map anonymous pages, which may also be
> > > hard with DJGPP.
> > 
> > Does that "Or" mean that if /dev/zero is available, mapping anonymous
> > pages is not required?  Or does gcc-page require mapping in any case?
> 
> It means I don't know.  I just saw separate conditionals for those
> cases.


Many ways to provide anonymous mapping :

#ifdef MAP_ANON
        cp = mmap(0, nbytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
#else
        {
        int fd = open("/dev/zero", O_RDWR);
        cp = mmap(0, nbytes, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
        close(fd);
        }
#endif

I beleive MAP_ANON, is more BSDish.  The "/dev/zero" is more SVR4ish.
Both are provided on GNU/Linux ... I think, the
relevant bits are in /usr/include/sys/mman.h
Unix98 does not say anything about MAP_ANON, did not check POSIX.

"/dev/zero" is there to zeroed the new allocated space.  Which
leads to amusing dependencies when doing a chroot().

It should be also possible to have a minimal mmap() for files
by reading the file incore.

mlock() and friends would be noops ? since it is there
to protect against other processes.  Unless there is
a way in DOS to proctect/lock certain parts of the memory.

int    mlock(const void *, size_t);
int    mlockall(int);
void  *mmap(void *, size_t, int, int, int, off_t);
int    mprotect(void *, size_t, int);
int    msync(void *, size_t, int);
int    munlock(const void *, size_t);
int    munlockall(void);
int    munmap(void *, size_t);
int    shm_open(const char *, int, mode_t);
int    shm_unlink(const char *);


At the top of my head, I remember many applications on Un*x
use mmap() to grab some memory and maintain there own pool,
They usually do that for example to provide garbage collection
or they manage the memory more efficiently then the default
allocator.  So they do stuff like :

void *malloc (size_t size)
{
  ....
  mmap (...);
  ....
}

Meaning if the mmap() implementation on DJGPP is
mmap (...)
{
    calloc (...)
}

It can lead to problems, should probably be something like
mmap ( .. )
{
   __djgpp_malloc (..);
}

This is probably too obvious.

Was not there a VFS lib for DJGPP at one point ?
 
-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!