| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

wishes_for_the_clr

Page history last edited by layla 9 years, 3 months ago Saved with comment
  • We asked what people would change in the CLR /NetFX
  • Transparency in binding/fusion behavior
  • AppDomain usability (cross-AD communication) is too tricky to figure out
  • Type system changes to allow recognizing class that "look like" others - rather than needing inheritence
    • Sort of like class equivalence
    • Pass as args, etc
    • Anonymous types!
  • Immutable arrays
  • Non-nullable reference types
  • Covariant return types
  • Time-bound GC (collect for no more that 5 seconds)
  • 32-64 reg access
  • Better ETW support/integration
  • Expressions in attribute declarations
  • Mix-ins
  • Access to protected methods for making testing derived types easier
  • Ref.emit for Windows Phone
  • Better reflection: MethodInfo comparison on Windows Phone
  • Vars w/ lambdas
  • Incremental compilation (faster run-edit-run cycles)
    • Like scripting language experience
    • Especially for web development
    • Use compile-as-a-service?
  • Non-blocking GC
  • Console mode improvements
  • WPF stronger typing
  • Extended profile use when targeting client profile leads to craziness
  • Multi-targeting build support (build for Windows Phone, then easily retarget to desktop client, etc)
  • Easy way to host v4/v2 (fallback) - what are best practices? Docs are lacking
    • Example: CorBindToRuntimeEx can't load v4. This isn't mentioned
  • TlbImp improvements to make Iunknown use easier
  • Com objects and QI
  • Struck alignment
  • Make it easier to get assemblies 'just working' in partial trust  (as transparent; even if things fail at runtime)
  • GC - can we affinitize an object with a thread such that its finalizer runs on that thread when GC'd

 

 

More notes captures by Brannon

More Data Structures

- Heap (Binary Heap, Binomial Heap, etc.  See Wikipedia for details..)

- Trees (Red-Black, AVL, etc.)

 

Fixed strings

- Init string over unmanaged memory

- Ok if the string must follow a specific format (i.e. length prefixed, BSTR, etc.), though control over the memory location is key.  

 

Ability to instantiate reference types in custom location (i.e. not on the managed heap).

- Similar to string request.  Consider the scenario where we have a large (multi-GB) file with a specific layout (i.e. an array of records).  I'd love to be able to VirtualAlloc and memory map the file and "instantiate" managed types over each record.  There's a serialization API System.Runtime.Serialization.FormatterServices.GetUninitializedObject().  Imagine a similar API in the Marshal class that allowed me to specify an IntPtr referring to unmanaged memory.  This is different from Marshal.PtrToStructure() which allocates a new object on the managed heap.

 

Ability to call operators through generics

- i.e. for high performance generic algos, using IComparable is not ideal

- Or better JIT support for IComparable over built-in types.  i.e. if you see IComparable<Double>, emit specific floating-point instructions, rather than virtual method calls to CompareTo().  I'm sure this isn't trivial :).  One way we've thought to work around this is to compile code on the fly using LINQ Expressions, which seems to give us direct binding to operators .. we just need to mitigate the cost of compiling the expression.

 

Lower overhead LINQ Expression compilation in full-trust

- I noticed while profiling code that most of the cost of compiling a LINQ Expression was related to permission checks.  It would be great to be able to tune this cost while running under full-trust.

 

Better System.IO.Compression

- Enable better compression ratios out of the box

 

Built-in zip container support (not System.IO.Packaging)

- As an internal team, it can be challenging to use OSS zip libraries (i.e. SharpZipLib is LGPL).

 

SIMD intrinsics

- see Mono.SIMD.  The Mono guys really nailed this, and I know Miguel would like to see this make it back into core .NET in one form or another.

 

Comments (0)

You don't have permission to comment on this page.