[Mono-devel-list] CAS update / feedback

Paolo Molaro lupus at ximian.com
Tue Nov 2 09:01:36 EST 2004

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 at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list