Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of feeder.of.the.bears@gmail.com
 designates 209.85.216.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=QWDh7hbKTeSe+fxg2KID0MP/9/5fb19a6Jij7uA/ju5ustAjg63Zu/o62iEq7Tj64j
         9QLJgJheqBoQ39CC0VUt9Fowa4wbcSVz90zjdOBfCwnHYlhNVAQvxFAM+AhohAp8YoJy
         ZtjMbOo8xijMaeUuh+dA2EnIAgtxHbuwBU9WM=
MIME-Version: 1.0
Date: Fri, 22 May 2009 09:57:14 -0700
Message-ID: <cdbebedf0905220957k7767c05emc0b6fb7812f1f337@mail.gmail.com>
Subject: Elaborating on my Tweet about Actor suboptimality
From: David Pollak <feeder.of.the.bears@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001636e91010ff329c046a832659

--001636e91010ff329c046a832659
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Folks,

I tweeted yesterday that I spent a good part of the day chasing Actor
suboptimality.

Scala Actors have a bunch of memory retention issues.  These issues have
crept into the code over the last year or so.  Since the 2.7.2 release, I've
been identifying these issues and the EPFL folks have been fixing them.
They've gone from pretty gross (Actors always being referenced by the
library) to very subtle (a 16 byte retention per Actor create.)

Anyway, I've built a bunch of code into Lift to work around the memory
retention issues.  Lift uses reflection to periodically "clean house" in one
of the places that the Actors retain memory.  Lift also replaces the
Fork-Join based scheduler (a source of memory retention issues as well as
high CPU usage in multi-core machines) with a simple java.util.concurrent
based scheduler.

I spent yesterday dealing with the fallout of these Lift-related
work-arounds to the memory retention issues in the Actor library.  First, I
discovered that the Actor library synchronizes objects during certain
operations where code outside the library is invoked.  This led to a
deadlock situation.  I had to work around this issue in Lift (and have filed
https://lampsvn.epfl.ch/trac/scala/ticket/2009 in response.)  I spent about
3 hours chasing a "messages not getting dispatched to certain actors"
issue.  It turns out that this was my mistake.  I used Actors based on the
old scheduling code before applying the fix to the scheduler.  Actors
created while the old scheduler was being used could not receive messages.
To fix this, I moved the "fix Actors" code to very early in the boot cycle.

More broadly, there's a discussion going on on scala-internals about what
can be done about Actors for Scala 2.8.  There are a lot of people
addressing the issue.  I have a high degree of confidence that they will get
to a reasonable solution for Scala's Actor library.  However, Scala's Actors
seem to be very heavy weight for what most apps I build (including ESME)
need.  I've been noodling with the idea of writing a very light weight Actor
library so that Lift has more control over this escential part of
interactive apps.

Thanks,

David

-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--001636e91010ff329c046a832659--