Value Types

RE: Value Types

Mike — Sun, 11 May 2003 09:11:00 GMT

Chris, you need a girlfriend! =)

RE: Value Types

Jeroen Frijters — Sun, 11 May 2003 15:10:00 GMT

Recently I looked into the implementation of Equals for Value Types and I was surprised by what I found. Object.Equals actually does a memcmp for value types (why?) and ValueType.Equals overrides this with a more complicated algorithm that either does a memcmp (if the value type has no reference members) or uses reflection to call Equals on each member. I don't like both of these. Object.Equals shouldn't deal with value types (is this perhaps a historical left over, from a time where System.ValueType didn't yet exist?) I don't like ValueType.Equals because using a memcmp for value types that don't contain references isn't all that sensible, because the individual field types could have overriden Equals to do something that isn't equivalent to a memcmp. Also, changing the semantics of Equals because of the presence or absence of a reference field isn't very intuitive either.

RE: Value Types

kathryn — Sun, 11 May 2003 20:00:00 GMT

RE: Value Types

Chris Brumme — Mon, 12 May 2003 19:29:00 GMT

Jeroen, Object.Equals considers whether 'this' is a value type, because a language like C++ allows scoped calls to virtual methods. In other words, you can call Object.Equals on ValueType instances. Last week I was talking to a dev who will be rewriting some of this code for better performance, but he intends to mostly retain the current semantics. In part, this is because it would be a breaking change to switch these methods over to a significantly different plan. And in part, this is because the current semantics aren't terribly broken. If you are satisfied with the default implementations, you can use them. If you are dissatisfied with them, you can add a more appropriate override on any value types you author. I think the original plan was to have something that was at least reasonable and that could perform well. Our current implementation does not perform well, but we should be able to replace it with a better memcmp style of comparison that is very efficient. Of course, the actual details won't be clear until our next release.

RE: Value Types

Chris Brumme — Mon, 12 May 2003 19:44:00 GMT

Mike, I'm not sure what Kathryn's cryptic comment is saying. But I would guess that -- as my wife of 18 years -- she is unwilling to share me with a girlfriend. She's been out of town for a week or so. In fact, I wrote the ValueType blog while sitting at the airport waiting for her. Now that I can spend time with her again, I expect I'll be blogging less.

RE: Value Types

Andrew Stopford — Tue, 13 May 2003 14:43:00 GMT

LOL, nice one Chris ;-) Let me echo what others have said here and thanks for providing such a technical overview of CLR subjects. I guess you don't have the cycles for a book but this kind of info would be a great backdrop to Jeffs and Don's books.

RE: Value Types

Keith Brown — Wed, 14 May 2003 17:56:00 GMT

Interesting that the instance header is 4 bytes long; simply a pointer. I've been led to believe that it was 8 bytes long, consisting of a type handle, sync block index, and some other bit flags. Was I wrong? If it's just a pointer, how does a sync block get associated with the instance?

RE: Value Types

Pinku Surana — Wed, 14 May 2003 19:31:00 GMT

Great explanation of ValueTypes. You state: "boxing is an efficient operation, but it necessarily involves allocating an object in the GC heap." I have found boxing to be rather inefficient, actually. For example, storing ints in a generic collection is much slower than an int-specific collection, even after substracting the cost of type-casting. Would it be possible for the VM to handle the box instruction specially to improve allocation performance? Two ideas come to mind. (1) If boxed values do not escape the method, stackalloc the box. If possible, reuse the box. (2) The GC could allocate a special page for boxed Int32s (and others), where the entire page is marked Int32 so you don't need a type tag over each box. The JIT knows that pointers to that page are really to boxed Int32s and "does the right thing". GC becomes more complex, too. I believe SMLnj does something similiar to allocate List structures (cons cells). Right now I warn people to be careful how they use ValueTypes. Since they will usually use structs for perf reasons, they should check that no box instruction is inserted into their inner loops. Otherwise, perf gets hit hard due to allocation.

RE: Value Types

Chris Brumme — Fri, 16 May 2003 16:44:00 GMT

Keith, Of course you are correct. The self-describing part is pointer-sized. And before that (at a negative offset from where we point at the object, for better cache line filling) is the obj header. This is really an aggressively unioned set of bit fields. One interpretation of those bits is a sync block index, but we also might place an AppDomain index, a hash code, a lock, information about specific types like Strings, finalization status and other information in there. Of course, it can't all fit, so eventually we may have to overflow to some other structure like a sync table entry or even a sync block from that header. It's a good job that one of us is paying attention.

RE: Value Types

Chris Brumme — Fri, 16 May 2003 16:59:00 GMT

Pinku, There's clearly more that we can and should do to improve the performance of boxing. I'm not sure how often your first suggestion would pay off. For the particular languages I'm thinking of, boxing is a prelude to insertion into a collection, or making an indirected call (an interface or virtual call), or a late-bound call via reflection. In most of those cases, it's either difficult to tell it won't escape the method or it's easy to show that it will escape. For the special case of calling virtual methods on Object, overrides on the valuetype can often be used to avoid this spurious box. I'm also hopeful that many of the scenarios where we box for collections can be avoided by using well-typed generic collections in a future release. The idea of using a special allocator has come up before. It's a good idea that we may eventually pursue here, though I doubt that we'll get to it for some time. Pinku, were you involved in Project 7? Are you using a dynamic language (where boxing performance is clearly an entirely different level of pain)? If so, I would love to get a list of what you currently consider the most painful limitations with the CLR in supporting your language. I'm interested in more than just performance here. For example, I know our tail call guarantees are probably too weak.

RE: Value Types

Andrew Stopford — Mon, 19 May 2003 18:50:00 GMT

This may seem like a silly question but just what type does a Enum take, value or referance and can a Enum be declared as a boxed (referance) value?

RE: Value Types

Chris Brumme — Mon, 19 May 2003 20:09:00 GMT

Pinku sent me the following email: Yes, I was involved in Project 7 with a Scheme compiler. A quickie respone is that a dynamic language needs type-checking and box/unboxing to be as fast as possible. Every possible trick is employed to make those two things fast. Scheme also needs tail-call to be as close as possible to a jmp. Unfortunately, these three things are not particularly fast on .NET, though there are well-known solutions to all. Let me think a bit more about issues beyond performance or I'll end up writing a long, rambling email. ;-) Gee, he makes it sound like long rambling stuff is a bad idea!

RE: Value Types

Chris Brumme — Wed, 21 May 2003 16:45:00 GMT

RE: Value Types

Chris Brumme — Wed, 21 May 2003 16:47:00 GMT

Andrew, If you are asking about System.Enum, it is a reference type. If you are asking about specific enums, they derive from System.Enum and are value types. As such, they can be boxed. As I noted in the blog, ECMA specifies support for well-typed boxed types in signatures. The CLR has not implemented that support.

RE: Value Types

Pinku Surana — Thu, 22 May 2003 21:03:00 GMT

I wrote a bunch of stuff, then deleted it when I realized I had just described a fancy Scheme VM. That reflects my bias that nearly anything can be implemented given closures and dynamic code generation. I've been sick and am writing this in a NyQuil induced haze, so I hope this makes some sense. ----- Closures: A closure is a tuple pointing to an environment and a function. A delegate is a closure with no environment; therefore, a closure could be a subclass of delegate with an extra slot for the environment. A closure constructor might be: Closure..ctor (BarClass target, Environment1 env, int ptrToBar) retType Bar (BarClass this, Environment1 env, args ...) Some P7 compiler guys wrote their own closure class to do precisely this, but the code was unverifiable and does not benefit from any JIT optimizations. Language VMs implement closures efficiently by employing lots of tricks, many of which could benefit the CLR's implementation of delegates. It is unfortunate that the delegate hierarchy is so rigid. Could you have done the MarshalByRef trick instead? ----- Dynamic code generation: Often languages must generate code at runtime to implement dynamic behaviour like new dispatch trees, speculative inlining, type-specific code, etc. Reflection.Emit is much too slow to generate code on-the-fly. Also, it should be possible to pitch code when you don't need it anymore, rather than have it frozen in an assembly once it is baked. [Serializable], generics, remoting, etc. are all instances where the CLR team felt they had to do specialized code generation. How would you do it if you were forced to write these in a user-library instead? You'd probably want the same code-generation stuff I want (maybe not the code pitching, but trust me - it's really useful). My sense is that code-generation should be a cooperative task between static and JIT compiler writers, communicating with each other through attributes and a low-level Emit library. ----- Continuations: It isn't fair to ask for continuations. Instead, if you are adding Fibers to the next version, how about generalizing the interface so I can add something else via a C DLL? Wishful thinking, probably ... ----- Here's a question for you: given your intimate knowledge of the CLR, how would you implement Dylan-like multiple dispatching, where methods can be loaded dynamically from different assemblies (you can't see everything at compile or load time)?

RE: Value Types

Frank Hileman — Fri, 23 May 2003 06:18:00 GMT

It seems that if the CLR could support two types of object instances, ones in the heap, and ones on the stack, boxing/unboxing could be made faster, at least for local and temporary value types vars. That is, if the IL generator knows that a value type will need to be boxed, it could create a "stack instance" that consists of the bits normally in the value type, preceeded by the header. Then no copying or GC perf overhead. Of course the rest of the CLR would have to be able to handle those special "stack instances", which would have to be marked somehow in the header. This would not help value types in an array, where there is no extra space to stick the header, but perhaps they need less boxing. A silly related anecdote: many years ago I worked on the internationalization of a OO C application (custom OO environment) and we needed to support both double-byte and single-byte strings simultaneously, at runtime. To be able to incrementally internationalize the system, we decided that older code would continue to use char* strings, but newer code would use a pseudo-object called the "GString", simply because G was our traditional prefix. We added an extra byte at the beginning of each string, which was used to dynamically look up the apropriate function pointer for each "method" call, resolving to single-byte or double-byte code. When calling into older code, we incremented past that byte, and then passed the pointer. We had lots of laughs about "encapsulation", "private members", etc. with regards to our GString.

RE: Value Types

Mike Dimmick — Fri, 23 May 2003 19:32:00 GMT

I think the point about 'boxed types on the stack' is that you're creating a boxed type in order to pass it to some other method which requires a System.Object. What that method then does with the boxed value is, in the general case, undiscoverable. However, if the inliner in the JIT (I assume there is one!) decides to inline all the called methods and can determine that those methods don't do anything particularly interesting (i.e. only call methods defined on System.Object) the inliner might be able to generate code on the fly that calls the appropriate methods directly, with no boxing. Come to think of it, that's probably already done.

RE: Value Types

Joe Schwartz — Wed, 25 Jun 2003 02:39:00 GMT

You wrote: "Incidentally, something similar is going on with System.Array and all the array types. In terms of layout, System.Array really isn’t an array. But it does serve as the base class under which all kinds of arrays (single-dimension, multi-dimension, zero-lower-bounds and non-zero-lower-bounds) are parented." This brings up an interesting question: When I have an int[] object in C#, can I safely assume that it's always zero-lower-bounds? I realize that I can use Array.CreateInstance to create an Array object containing ints with non-zero-lower-bounds. However (and here's the interesting part), I cannot cast that Array to an int[] -- I get an InvalidCastException. From this, I gather than a general Array object can use any lower bounds, but the more specific int[] (or any object[]) must have zero lower bounds. Is that correct?

RE: Value Types

Chris Brumme — Sat, 19 Jul 2003 19:36:00 GMT

Joe, The single-dimension array types in C# (e.g. Object[] and int[]) are indeed constrained to have zero-lower-bounds. The array hierarchy is a bit surprising in how it is structured. I have added this to the growing list of possible blog articles.

cbrumme s WebLog Value Types | internet marketing tools

cbrumme s WebLog Value Types | internet marketing tools — Tue, 16 Jun 2009 07:37:42 GMT

PingBack from http://einternetmarketingtools.info/story.php?id=22239