| Groups | Blog | Home |
dotnet clr : Is there an ordering of objects?
[quoted text, click to view] "Ole Nielsby" <ole.nielsby@snailmail.dk> wrote in message news:OG5YzBPVGHA.4660@tk2msftngp13.phx.gbl... > 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? 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. 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:
On Fri, 31 Mar 2006 20:25:11 +0200, "Ole Nielsby"
[quoted text, click to view] <ole.nielsby@snailmail.dk> wrote: >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: > 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.
[quoted text, click to view] "Ole Nielsby" <ole.nielsby@snailmail.dk> wrote in message Why sort it then? Wouldn't just creating htem and inserting them into a list news:%23B6u32RVGHA.1304@tk2msftngp13.phx.gbl... > Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote: >> >> "Ole Nielsby" <ole.nielsby@snailmail.dk> wrote: >>> >>> When gc-able objects are created, this happens at >>> increasing (or decreasing) addresses. >>> >>> Is the ordering of these addresses guaranteed to stay the same? >> [...] >> >> 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. > achieve the same thing?
[quoted text, click to view]
Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote: > > "Ole Nielsby" <ole.nielsby@snailmail.dk> wrote: >> >> When gc-able objects are created, this happens at >> increasing (or decreasing) addresses. >> >> Is the ordering of these addresses guaranteed to stay the same? > [...] > > 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.
On Sat, 1 Apr 2006 15:41:00 +0200, "Ole Nielsby"
[quoted text, click to view] <ole.nielsby@snailmail.dk> wrote: > >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? > 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
On Sat, 1 Apr 2006 18:25:37 +0200, "Ole Nielsby"
[quoted text, click to view] <ole.nielsby@snailmail.dk> wrote: > >Jim Cheshire <contactme@mysite.com> wrote: > >> 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. > 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
[quoted text, click to view]
Daniel O'Connell [C# MVP] wrote: > > "Ole Nielsby" <ole.nielsby@snailmail.dk> wrote in message >> >> 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. >> > 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.
[quoted text, click to view]
Jim Cheshire <contactme@mysite.com> wrote: > 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.
[quoted text, click to view] Jim Cheshire <contactme@mysite.com> wrote: > 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. [quoted text, click to view] > 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.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |