[gclist] Finalization, again

[David Chase]

At 03:38 PM 10/4/2001 -0500, Manoj Plakal wrote:
>David Chase wrote (Thu, Oct 04, 2001 at 04:26:41PM -0400) :
>> At 03:38 PM 10/4/2001 -0400, David F. Bacon wrote:
>> >the other sensible alternative would be to statically require that 
>> >finalizer methods execute no unbounded loops or blocking operations.
>> 
>> It would also make sense in exception handlers; it would
>> be lovely to be able to assert that a thread would, when
>> told to go away, actually go away.  The fact that this isn't
>> possible (for, say, Java) limits the contexts in which
>> you'd actually be willing to download and run code from
>> strangers.
>
>        What about method calls made in a finalizer
>        or exception handler? Don't you then have
>        to extend the analysis to the rest of
>        the program?

Yes.

>        I'm not sure that there is any program 
>        analysis or verification that would prevent
>        denial-of-CPU attacks by hostile code
>        (whether downloaded or in finalizers).
>        Not unless you significantly restrict
>        what the code can contain.

That is the intent.  What is worth considering is whether
the resulting (sub)language is usable for its intended
purpose.  The aim is to support some sort of a contract
between the loaded code and the host -- the host can be
sure that if told to go away, the loaded code will in
fact go away, and the loaded code can be sure that if it
is told to go away, it will be given enough time/resources
to clean up after itself.  And, in particular, the host
can see (verify) that the loaded code will both conform
to its contract, *and* that it will be able to cleanly
terminate.  The "if you didn't ask for enough time to
clean up, you deserve abnormal termination" model is
simple, but it means that any promises made by the loaded
code are conditional on "and there is no abnormal
termination".

At least, that's the goal.  The termination is also
qualified in a certain sense; if the loaded code is
fed endless requests (e.g., termination exceptions)
by the runtime, then it is allowed to spend an endless
amount of time to service those endless requests.

>        It might be better to handle these
>        in the VM/OS scheduler using threads
>        (as David suggested) or some CPU usage
>        restrictions (for downloaded code).

These restrictions come with their own costs,
and I'm not at all sure that actually provide any
worthwhile guarantees.  How many endlessly spinning
finalizer threads would you like me to create?  Would
my "light-weight" threads still be light-weight?
Are method calls still cheap?  The advantage of
attacking the problem with verification is that
things generally stay cheap.



David Chase
chase@naturalbridge.com
drchase@alumni.rice.edu
chase@world.std.com