Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <boemm...@physik.uni-kl.de>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Sender: boemm...@physik.uni-kl.de
To: Dave Mitchell <da...@fdgroup.com>
Cc: Dan Sugalski <d...@sidhe.org>, perl6-intern...@perl.org
Subject: Re: Bytecode metadata
References: <a05200f01ba5492b60e51@[192.168.2.1]>	<m265sfpqg6.fsf@helium.physik.uni-kl.de>	<20030123203921.B8696@fdgroup.com>
Date: 23 Jan 2003 22:31:55 +0100
In-Reply-To: <20030123203921.B8696@fdgroup.com>
Message-ID: <m2wukvo8ms.fsf@helium.physik.uni-kl.de>
Lines: 24
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: boemm...@physik.uni-kl.de (Juergen Boemmels)

Dave Mitchell <da...@fdgroup.com> writes:

> On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> > My current idea for the in memory format of the bytecode is this:
> 
> I would strongly urge any file-based byte-code format to arranged
> in such a way that it (or most of it) can simply be mmap-ed in (RO),
> analogously to executables.
> 
> This means that a Perl server that relies on a lot of modules, and which
> forks for each connection (imagine a Perl-based web server), doesn't
> consume acres of swap space just to have an in-memory image per Perl
> process, of all the modules.

This might be possible if the byteorder, wordsize, defaultencoding
etc. are the same in the file on disk and the host.

bye
boe
-- 
Juergen Boemmels			boemm...@physik.uni-kl.de
Fachbereich Physik			Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern		Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47