Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Next Apocalypse

Newsgroups: perl.perl6.language
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <dsto...@bigpanda.com>
Mailing-List: contact perl6-language-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-langu...@perl.org
Delivered-To: perl6-langu...@perl.org
Date: Tue, 16 Sep 2003 09:00:38 -0700
To: The Perl6 Language List <perl6-langu...@perl.org>
Subject: Re: Next Apocalypse
Message-ID: <20030916160037.GA99115@megazone.bigpanda.com>
Mail-Followup-To: The Perl6 Language List <perl6-langu...@perl.org>
References: <20030915150816.67773.qmail@web12301.mail.yahoo.com> <002b01c37ba1$03a12770$cc54e8c7@domain.ma.iclub.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002b01c37ba1$03a12770$cc54e8c7@domain.ma.iclub.com>
User-Agent: Mutt/1.4.1i
X-Spam-Check-By: one.develooper.com
X-Spam-Status: No, hits=-0.5 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.44
X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: dsto...@dstorrs.com (David Storrs)
Lines: 61

On Mon, Sep 15, 2003 at 11:49:52AM -0400, Gordon Henriksen wrote:
> Austin Hastings wrote:
> 
> > Given that threads are present, and given the continuation based
> > nature of the interpreter, I assume that code blocks can be closured.
> > So why not allocate JITed methods on the heap and manage them as first
> > class closures, so that the stackref will hold them until the stack
> > exits?
> 
> 
> Austin,
> 
> That's a fine and dandy way to do some things, like progressive
> optimization ala HotSpot. (e.g., "Oh! I've been called 10,000 times.
> Maybe you should bother to run a peephole analyzer over me?") But when
> an assumption made by the already-executing routine is actually
> violated, it causes incorrect behavior. Here's an example:
> 
>     class My::PluginBase;
>     
>     method say_hi() {
>         # Default implementation.
>         print "Hello, world.\n";
>     }
> 
> 
>     package main;
>     
>     load_plugin($filepath) { ... }
> 
>     my $plugin is My::PluginBase;
>     $plugin = load_plugin($ARGV[0]);
>     $plugin.SayHi();
> 
> Now, while it would obviously seem a bad idea to you, it would be
> reasonable for perl to initially optimize the method call
> $plugin.say_hi() to the function call My::PluginBase::say_hi($plugin).
> But when load_plugin loads a subclass of My::PluginBase from the file
> specified in $ARGV[0], then that assumption is violated. Now, the
> optimization has to be backed out, or the program will never call the
> subclass's say_hi. Letting the GC clean up the old version of main when
> the notification is received isn't enough--the existing stack frame must
> actually be rewritten to use the newly-compiled version.


This discussion seems to contain two separate problems, and I'm not
always sure which one is being addressed.  The components I see are:

1) Detecting when the assumptions have been violated and the code has
   to be changed; and,

2) Actually making the change after we know that we need to.


I have at least a vague idea of why #1 would be difficult.  As to
#2...assuming that the original source is available (or can be
recovered), then regenerating the expression does not seem difficult.
Or am I missing something?


--Dks