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:

"Ole Nielsby" <ole.nielsby (AT) snailmail (DOT) dk> wrote

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.

Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote:
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 Fri, 31 Mar 2006 20:25:11 +0200, "Ole Nielsby"
<ole.nielsby (AT) snailmail (DOT) dk> 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.

Jim

"Ole Nielsby" <ole.nielsby (AT) snailmail (DOT) dk> wrote

achieve the same thing?

Daniel O'Connell [C# MVP] wrote:
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.

Jim Cheshire <contactme (AT) mysite (DOT) com> wrote:

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.

On Sat, 1 Apr 2006 15:41:00 +0200, "Ole Nielsby"
<ole.nielsby (AT) snailmail (DOT) dk> wrote:
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

Jim Cheshire <contactme (AT) mysite (DOT) com> wrote:

Which is why I'm curious about whether pointer ordering
is version dependent or not.

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.

On Sat, 1 Apr 2006 18:25:37 +0200, "Ole Nielsby"
<ole.nielsby (AT) snailmail (DOT) dk> wrote:

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