[Mono-devel-list] CAS update / feedback

[Paolo Molaro]

On 11/01/04 Sébastien Pouliot wrote:
> The point of my last email was that Assert (like Deny and PermitOnly) are
> stack modifiers. Calling them has no impact until a stack walk is triggered
> by any kind of Demand. If this has no impact maybe it could (or should) be
> delayed...
[...]
> However like I said Assert *DOES NOTHING* unless a stack walk is triggered.
> So we're still "loosing" time to mark the stack UInt32.MaxValue -
> (UInt32.MaxValue / 1024) as most calls will never reach a Demand. At this
> time I'm unsure about the performance of stack marking (it depends on the
> type of stack we'll be using/reusing) but anyway it will be > 0.

It should eventually be quite fast: if we use a variable on the call frame
it's like a push on a single list. In this case we need to register the variable
in MonoJitInfo so the stack walk can find it.

> So the idea is that we already have two ways to populate the security stack
> (declarative and imperative) so why not "create" two stack ?
[...]
> Cons
> * We need to add an internal API to get the declarative security data from
> the managed side (right now it's push from the JIT/runtime into the managed
> world);
> * We still need to implement the other half (imperative) to match MS
> implementation (we're not saving development time);
> * We must be able keep in order the execution stack (used for declarative
> security) with the security stack (to be used for the imperative security);

This is the biggest issue. Is the order significant inside the same call frame?
I guess so. What if Assert() is called in a loop? It's easy to optimize
if you assert the same permission, but what if we alternate between two 
different ones? Anyway, this is mostly an issue of the imperative code.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better