On Tue, Oct 03, 2000 at 05:32:48PM +0100, Nicholas Clark wrote:
> On Mon, Oct 02, 2000 at 07:21:46AM -0500, Jarkko Hietaniemi wrote:
> > Having such bytecodes available is essential for the proposed
> > functionality of dumping the state of a live and running Perl virtual
> > machine and breathing life into that later.
>
> Were you thinking that p6 bytecode has 2 functions
>
> 1: putting a perl virtual machine into suspended animation (or cloning it)
> 2: producing a "precompiled" version of a single file of perl
> (ie .pmc is a drop in replacement for .pm, any use or require in the .pm
> still causes the .pmc to issue a use or require at run time)?
>
> Or just function 1?
Mainly just 1.
> (and bytecompiling a script gives you a single bytecode file which contains
> the exact versions of all libraries you used for it, freezing the virtual
> machine between the last CHECK{} and the first INIT{} ?)
>
> I think function 2 is somewhat tricky to implement, as one would be aiming
> to capture bytecode that represents the changes to the op tree that the file
> made. Without ensnaring changes to the op tree caused by modules it used.
> (problem being that there's not a 1 to 1 correspondence between files and
> packages)
Serializing an optree is rather tricky especially if one wants to
deserialize it on a different platform. Because of icky things like
structure padding one effectively really needs to go the way of
*byte*codes which makes for one ssslllooowww VM.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
