[cap-talk] Dan Bernstein's qmail security lessons paper

[Sandro Magi]

Jonathan S. Shapiro wrote:
> This is exactly how the problem arises. Typically, the request-response
> loop will have some local variable somewhere that gets the "answer" from
> all of the processing. This variable must still be in scope at the
> response, and additionally there are many local variables that are out
> of scope or not reachable from the control flow. Unfortunately those
> other local variables usually have non-null values, and the stuff they
> point to therefore cannot be GC'd.
> 
> The results are very application specific, but the degree of retention
> can be very surprising.
> 
> Andrew Appel wrote a nice paper on all of this, but I now forget the
> title.

If anyone has a pointer to this, I'd appreciate it! Was it a paper about
web applications or general client/server apps?

> I have *enormous* respect for Hans, but he has made a number of
> inadequately qualified statements in this regard. The cold truth is that
> the overheads are extremely application dependent, and no general
> conclusion of this sort can be drawn accurately. Our experience with
> conservative GC in OpenCM was DISMAL. In fairness, it may also have been
> atypical. The point is that nobody (including Hans) can say with
> confidence what the cause of the problem was or whether it was typical
> or not.

The suitability of GC in general is somewhat application-specific, so I
can certainly accept that.

>> I'm not sure I follow. Just about every language I know of exposes
>> native integers by default without transparent conversions to big integers.
> 
> Counter-examples: ML, Lisp, Haskell

"int" is not transparent in OCaml or in SML; you have to explicitly open
and use the BigInteger or IntInf modules, respectively. In Haskell, you
use Integer for arbitrary precision, or Int for platform integers. You
only pay for what you use. Lisp falls into that "just about every
language" qualifier, along with E. ;-)

>> I would say that the substantial execution overheads result from boxed
>> representations of simple types like integers and floats, which must
>> then be traced by the GC. OCaml performs substantial analysis to unbox
>> such small values.
> 
> Yes. Unfortunately this unboxing is not supported by .NET, which is
> probably the most widely used runtime implementation of this sort. By
> the time you get the JIT layer you've lost a lot of information here.

.NET carries full type information all the way through to the JIT, and
it has a simple compilation model: if ValueType then stack allocate else
heap allocate. What other information are you referring to?

All the register allocator needs is size information to assign a value
to a register, and it would seem that the JIT would have this information.

Sandro