[Mono-devel-list] NET_2_0 attributes

Ben Maurer bmaurer at ximian.com
Wed Sep 22 17:00:13 EDT 2004


On Wed, 2004-09-22 at 15:40, Marek Safar wrote:
> >>>I think we need to implement this stuff in the C part of the runtime.
> >>>The icalls need to be changed, too, to match the MS CLR implementation
> >>>wrt attribute creation. Last time I checked:
> >>>*) IsDefined() didn't cause the attributes to be created
> >>OK, but that is different story. This is all valid for normal attributes 
> >>not for pseudo.
> >It needs to be done for all kinds and we want to have the logic in one
> >place.
> It will be slower a out of context. I don't understand why do you want 
> to test whether type is Serializable somewhere in deep runtime, when we 
> have had this code in corlib already.
> I think it will be a lot of useless casts instead of simplicity of 
> virtual methods in my patch.

If we do it in managed code, we will have to do the following:

1) get normal attrs from native code
2) search for the pseudo atts
3) create them
4) create a new array with all of them.

That is a total of 2 arrays created by the GC. Anyways, you are going to
have to do icalls for many of the pseudo attrs. So you are going to
waste some managed->unmanaged transitions.

IsDefined should have *NO* managed allocations (idealy, no unmanaged
ones either). It is going to be hard to do that unless we do most of the
logic in native code.

> >It's not. Parameterless attributes may have state that can be changed as
> >any other and the constructor can have any arbitrary side effect.
> >  
> >
> OK, I thought attributes with parameterless constructor and no property 
> e.g. SerializableAttribute, ComImportAttribute, InAttribute,....

Nobody should be using GetAttributes for those. If you want to check if
a class has ComImportAttribute, you should use IsDefined. It will do
fewer memory allocations, and should be faster.

Anyways, think about it like this: if you want to have all
parameterless, ctorless attributes be saved, you are going to need a
lock and a hashtable lookup to save the cost of allocation. Even today,
it is probably faster just to do the gcmalloc. Once we have generational
collection, it should be much faster to do the gc allocation.

-- Ben




More information about the Mono-devel-list mailing list