Activator.CreateInstance fails to call constructor for value types

[gafter]

See dotnet/roslyn#1029 and http://roslyn.codeplex.com/workitem/465 for some context.

The issue is basically an optimization introduced in Activator.CreateInstance around CLR 4.0 and present ever since. The optimization assumes that parameterless instantiation of generic T type does not cause sideeffects if T is found to be a struct and therefore instances can be cached. Parameterless struct constructors (which are permitted by spec) violate such assumptions and make optimization observable.

[jkotas]

This code makes incorrect assumption that value types have no default constructor.

[jkotas]

@gkhanna79 Could you please reassign it as appropriate?

[gkhanna79]

@ramarag PTAL

[andrewjsaid]

I read an article earlier today about Wire Serialiser where one of the optimisations was able to determine whether the constructor of a type had any side effects by counting the number of IL instructions. The author intelligently determined that any constructor with fewer than 8 IL bytes, accessed through GetILAsByteArray(), must have no side effects.

I am not familiar with the coreclr code based but I presume that the same optimisation can be used such that instead of

if (!ace.m_type.IsValueType)

we can have

// Pseudocode
if (defaultConstructor.GetILAsByteArray().Count > 8)

For reference:
See the section titled "Fast creation of empty objects" in the first link
https://rogeralsing.com/2016/08/16/wire-writing-one-of-the-fastest-net-serializers/
http://mattwarren.org/2016/08/23/Analysing-Optimisations-in-the-Wire-Serialiser/

This would then also provide a benefit to reference types which do not override the default constructor, although I am not sure whether you would also need to check all base types and whether that would be more expensive. Maybe it could be an optimisation only for those types inheriting from Object or ValueType?

[gkhanna79]

@ramarag Did you take a look at this?

[gkhanna79]

@kouvel Can you PTAL?