[Mono-devel-list] CAS update / feedback

[Paolo Molaro]

On 10/29/04 Sébastien Pouliot wrote:
> Right now I'm thinking about dropping the JIT code generation for stack
> modifiers (Assert, Deny and PermitOnly), i.e. everything that isn't a
> demand.

The last time I had a look at some CAS details was many months ago, so
I swapped them out of my mind: what JIT code generation would you avoid?
These should just set some sort of markers for the stack frame, right?

> (b) if the demand requires a stack walk (e.g. some permissions inherits from
> CodeAccessPermission)
> 	- use the execution stack for retreive all methods;
> 	- check if methods have security attributes
> 		- look if the items are cache for the stack modifiers;
> 			- if not then create (and cache) the PermissionSet;
> 			- keep pointers to the PermissionSet into MonoMethod/MethodInfo;

It could be stored in MonoJitInfo in most cases. We need to deal with the case
when the method is compiled as appdomain-neutral, but the permissing obj is 
appdomain-specifc.

> The extra difficulties are:
> - 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);
> - to be able keep in order the execution stack (used for declarative
> security) with the security stack (to be used for the imperative security);

This may have to do with the code generation issue above. From what I remember,
the security stack could be maintained in two ways:
*) implicitly by having some data in the execution stack and letting the
stack walk code find the data
*) explicitly, by having a pointer in a thread local slot, with each new frame 
doing a push/pop at enter/leave.
The first would be the most efficient, but I don't remember all the details
to judge if it is sufficient to implement the semantics (re the CompressedStack,
for example).

lupus

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