[gclist] Finalization, again

Manoj Plakal plakal@cs.wisc.edu
Thu, 4 Oct 2001 15:38:25 -0500

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?

	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.

	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).