[Mono-devel-list] Performance issues with security permissions

[Paolo Molaro]

On 01/25/05 Sebastien Pouliot wrote:
> * So the only thing creating the permission object does (without
> --security) is more memory allocations, additional garbage collection...
> All bad for Mono's performance. So the pattern was changed to something
> like:
> 
> 	public static string GetEnvironmentVariable (string name)
> 	{
> 		if (SecurityManager.SecurityEnabled) {
> 			new EnvironmentPermission 

Yep, this looks good: it's the reason I insisted we'd use the
--security option.

> * Now the property value for SecurityManager.SecurityEnabled reside in
> unmanaged code (so it can be used over there and so we can't reflect on
> the field to change its value). This means an internal call each time.
> 
> To avoid this the JIT _could_ produce code to replace SystemManager.
> SecurityEnabled by false when --security isn't enabled. In this case the
> permission creation/demand would be treated as dead code (and possibly
> totally removed by optimizations).
> 
> 	??? is it worth it ???

Yes, it is. We'll do two things: if --security is not provided,
the call will be changed to a false boolean value. I committed last week
a change that will enable the code to be removed in this case also
when the default optimization options are used (I needed it to remove
code as well in some experimental code I had written).
The other thing is: if --security is provided, the icall will be
changed to a simple load from the memory location where the flag is stored,
so it will be quite fast to execute. This could be optimized so
that once the value is set to false we always return a false boolean
constant (if we agree that in that case results should be considered 
undefined).

>         * Another example is demanding a permission that is already
>         demanded by something else down the execution stack. This is why
>         Environment.CurrentDirectory doesn't check for PathDiscovery
>         permissions because System.IO.Directory already does the job.

A demand () in a call frame could mark the callframe if it succedes
and an new demand would need to wlak the stack just to that point
(this doesn't get rid of the obj creation ovehead, though...).

lupus

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