 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / April 2006Is there an ordering of objects?
When gc-able objects are created, this happens at increasing (or decreasing) addresses. Is the ordering of these addresses guaranteed to stay the same? Or can an object be moved past another during compacting, as a result of pinning or gc optimization techniques? A scenario might look like: create objects A-P create Q create R create S forget A-P pin Q gc while Q pinned unpin Q When compacting, will R and S be moved before P? Say, R is large and can't be fitted before Q. Will S then be moved to fill the vacant space? I ask this because I need an ordering of objects for a project. The ordering does not need to be immune to serialization/deserialization, but it must be immune to garbage collection. The objects aren't going to be pinned by my code but other pinned objects might exist. Is it possible in verifiable code to compare the pointers? Thanks/Ole N: > When gc-able objects are created, this happens at > increasing (or decreasing) addresses. [quoted text clipped - 27 lines] > Is it possible in verifiable code to compare the > pointers? I'm not 100% about the order changing. but I don't think anything is guarenteed. My question is what could you possibly be writing that requires knowing the order of objects? You aren't even guarenteed that objects will be created ontop of eachother since the runtime allocates blocks on its heap based on the underlying virtual memory system, its quite possible other bits of code will cause the release of other blocks of memory or allocatoin of other blocks. I doubt seriously you can bet on objects having any serious order at creation time, let alone after the GC runs. >> When gc-able objects are created, this happens at >> increasing (or decreasing) addresses. [quoted text clipped - 4 lines] > I'm not 100% about the order changing. but I don't think anything > is guarenteed. > My question is what could you possibly be writing that requires > knowing the order of objects? I'm dealing with attribute lists. I need to sort the attribute names (which are unified constants of various types, including tuples of other constants) in an arbitrary but consistent order. Simply using the addresses would give a very fast sort. >>> When gc-able objects are created, this happens at >>> increasing (or decreasing) addresses. [quoted text clipped - 12 lines] > tuples of other constants) in an arbitrary but consistent order. > Simply using the addresses would give a very fast sort. Why sort it then? Wouldn't just creating htem and inserting them into a list achieve the same thing? > "Ole Nielsby" <ole.nielsby@snailmail.dk> wrote in message >> [quoted text clipped - 5 lines] > Why sort it then? Wouldn't just creating them and inserting > them into a list achieve the same thing? I use the lists for pattern matching. I keep the names in one list which is unified and common for all nodes with that particular combination of attribute names, regardless of their order. The attribute values are kept in another list, at corresponding locations. There is no way two name lists can have the same attribute names in different order. This gives both economic storage and quick pattern matching - the pattern matcher can check all attribute names by a single pointer compare. This is vital because I'm porting a programming language that is based on pattern matching. regards/Ole N. >When gc-able objects are created, this happens at >increasing (or decreasing) addresses. [quoted text clipped - 29 lines] > >Thanks/Ole N: Compaction is not ever going to change the order of objects on the managed heap. Free blocks are going to show as System.Free on the managed heap until they are returned to the OS. The only exception to that is the LOH which will never return free blocks. On the LOH, we will reuse free blocks as needed. Jim > Compaction is not ever going to change the order of > objects on the managed heap. Free blocks are going > to show as System.Free on the managed heap until > they are returned to the OS. The only exception to > that is the LOH which will never return free blocks. > On the LOH, we will reuse free blocks as needed. Thanks. Is this behaviour part of the clr specification, or is there a risk that future or alternative versions of the clr (Mono etc.) might break it - or is there a silent agreement not to break it? I can't find a method for pointer comparison in the class library (except ReferenceEquals which doesn't provide an ordering). Is this because I haven't looked in the right place or because I'm not supposed to rely on pointer order? I might be able to convert the pointers to IntPtrs, but there will still be a race condition: what if a gc happens between the two casts? regards/Ole N. >Is this behaviour part of the clr specification, or is there >a risk that future or alternative versions of the clr (Mono [quoted text clipped - 10 lines] >there will still be a race condition: what if a gc happens >between the two casts? Don't ever design your app with a reliance upon any particular implementation. You never know about changes. Keep in mind that you're not really dealing with pointers in the classic sense of the word. The next object pointer is going to be moving all over the place as GC takes place. Fact is, you can never know where an object is without walking the roots. That's why we have pinning. Jim Jim Cheshire Jimco Software http://www.jimcosoftware.com Add-ins for Microsoft FrontPage Author of Special Edition Using Microsoft Office FrontPage 2003 > Don't ever design your app with a reliance upon any > particular implementation. You never know about changes. Which is why I'm curious about whether pointer ordering is version dependent or not. > Fact is, you can never know where an object is without > walking the roots. That's why we have pinning. I've been involved with compacting garbage collectors long before the clr was born (I implemented one on a Z80 CMP system back in 1985), so it's not like those walking pointers are aliens. Anyway, I guess I'll go for a content based ordering and see how it performs; then I can experiment with optimizations later. regards/Ole N. >> Fact is, you can never know where an object is without >> walking the roots. That's why we have pinning. [quoted text clipped - 3 lines] >Z80 CMP system back in 1985), so it's not like those >walking pointers are aliens. Sorry. Didn't realize it was a contest! :) I was stating a fact about something that you seemed to not understand. Glad to know that your questions were simply rhetorical. Jim Jim Cheshire Jimco Software http://www.jimcosoftware.com Add-ins for Microsoft FrontPage Author of Special Edition Using Microsoft Office FrontPage 2003 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.