I know there are no pointers in C#, but if you do:
a = b;
and a and b are both arrays, they now both point to the same memory
(changing one changes the other). So, it makes them seem like
pointers.
Can someone please explain why? thanks.
Zytan
Feb 25 '07
64  3351 
Peter Duniho wrote:
On Fri, 02 Mar 2007 14:28:30 +0800, Göran Andersson <gu***@guffa.com>
wrote:
>Yes, there is a mechanism, but that's all in the garbage collector, as
I am saying over and over. There is no mechanism in the application
code that handles a reference any different from a pointer.
I never said the mechanism had to be in the application. I am simply at
a loss as to why you would invest so much time rebutting a point that I
never actually made
Because I keep explaining that there is nothing more than a pointer in a
reference, and you keep saying that there is more.
>There is type information that the garbage collector uses, but that is
nothing special for references, that information exists for all
variables.
Yet, the mechanism by which the garbage collector *uses* this
information is entirely specific to the implementation of references.
There's a bunch of code in there that exists for the sole purpose of
updating references when the objects are relocated. It's disingenous to
claim that there's "nothing extra".
I have never said that there is no code for handling references. On the
contrary I have tried to explain this to you over and over.
>The reference is just a pointer, there is nothing more than the
pointer, and the only thing that makes it a reference is how it's used.
There is plenty more than the pointer. The code in the garbage
collector, and the data it uses, are all "more than the pointer".
No, there is nothing more than a pointer in a reference. Nothing. Not a
single bit.
The code in the garbage collector is not stored inside every reference,
neither is all the data that the garbage collector uses.
--
Göran Andersson
_____ http://www.guffa.com
Peter Duniho wrote:
On Fri, 02 Mar 2007 17:05:42 +0800, Göran Andersson <gu***@guffa.com>
wrote:
>Yes, as the program code has to do nothing at all to manage the
references, that means that updating a reference is perhaps twice as
efficient in .NET as in an environment that uses for example reference
counting.
It seems you are again responding to points I did not make. I never
once brought up the question of "reference counting", nor do I find it
relevant to the discussion I'm participating in.
I never said that you mentioned reference counting.
Do you really think that you are the only one that decides what the
discussion is about, and that noone else may mention anything that you
haven't brought up? ;)
I brought up the reference counting model as it's one of the major
alternatives to a garbage collection model.
The .NET method is nowhere near as efficient in *updating* as the old
Mac "handles" method. Using handles, a single value needs to be
updated. That's it. It's a few instructions at most. This is WAY
faster than .NET running through all of the data structures in the
memory manager, finding those that refer to a given object and modifying
them.
Yes, the garbage collection does far more work, but I was talking about
the work that the application code does.
>[...]
Even if the garbage collector has to to ten times the work to make up
for the lack of a object handle table or a reference reference table,
that should be nothing compared to making every reference operation in
the application code twice as fast.
Well, I haven't measured, but I'd say the garbage collector has to work
a LOT harder than just ten times, at least compared to the old Mac OS
"handle" paradigm.
In the "handle" paradigm, the garbage collector is basically O(n); the
collector can simply scan through the handle table, coalescing the
objects and updating each handle once. In the .NET paradigm, the
collector has to either scan the entire collection of data for each
object it wants to move, or it has to maintain some sort of hash table
or other fast-access data structure in which it stores (at least
temporarily) all of the current references to each given object (which
is essentially the "reference reference table" method anyway).
The garbage collector actually does neither of what you claim that it
has to. ;)
It only scans the data that is reachable from the application, not all
the data. There is no reason to look for references in objects that the
application can't reach anyway.
--
Göran Andersson
_____ http://www.guffa.com
"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@n33g2000cwc.googlegro ups.com...
>Sorry, I don't want to sound rude, but you got it wrong,
Telling me i'm wrong is not rude, so don't worry :)
>each object reference is held in a
program variable, and this variable can actually exist in a register, on the stack, in
the
Finalizer list or in the Handle table.
Ok.
>N references can point to the same object in the GC heap, see sample [1].
Yes.
>The JIT helps the GC, by updating a table (the GCInfo table) in which he stores the
aliveness state of the variables holding object references at JIT compile time (per
method).
Ok.
>Note that the JIT doesn't keep track of this for each machine instruction, only those
that
can possibly trigger a GC are kept in the GCInfo table.
All the GC has to do is inspect the GCInfo table and start walking the stack(s) and the
handle table to find the references to dead objects and reset these references (set to
null). When done, he can start a compactation of the heap, hereby updating the life
references of the moved objects, in the stack and the handle table. Note that I've
left-out
some details but at large that's it.
[1]
class C {
int i;}
...
void Foo()
{
C c = new C();
C c1 = c
(1)
...}
Here at point (1), the stack (or registers) will hold (at least) two reference to same
instance of C.
Yes.
Ok, while my explanation was very general, and as far as I can tell,
you explained the same thing, except in much more technical detail
(details that I didn't know). In general, this is what I suspected
was going on. Maybe I was unclear.
< snip
And in most cases, I bet there is only 1 reference to the object, so
if the GC really needs to move things, which I imagine it doesn't very
often, there's only 1 32-bit pointer it needs to update.
>
Above is what I called "wrong":
- there is at least one reference to an object not only 1, most of the time there are even
two or three root references, even if your application only hold a single reference to a
single instance. And as I said a single instance can have multiple application created
references.
- and the GC run more often than some might expect (or had wished :-)), all depends on your
allocation scheme, remember this is not C++, almost everything is an object in .NET.
A thousands of objects are already created and the the GC has already made a sweep before
the CLR enter the main entry In a simple console application.
Willy.
On Sat, 03 Mar 2007 04:34:20 +0800, Göran Andersson <gu***@guffa.com>
wrote:
Because I keep explaining that there is nothing more than a pointer in a
reference, and you keep saying that there is more.
Huh? You can only rebut my post if you introduce new concepts to disagree
with, ones I never mentioned in the first place? That should tell you
something.
I have never said that there is no code for handling references. On the
contrary I have tried to explain this to you over and over.
You continue to claim that a reference is nothing more than a pointer.
But it is.
If I believe your claim that you cannot consider any of the other things
surrounding that reference when considering whether it is more than a
pointer, then it's not even a pointer. It's just 32 bits. It's not a
pointer at all. It's just pure data, without any context whatsoever.
Conversely, once you start interpreting data as a specific kind of data,
you need to consider everything that interprets it. And a reference
definitely is not simply interpreted just as a pointer. It's a very
special kind of value that holds very special meaning beyond simply
describing a specific place in the virtual address space.
Likewise, using the logic you're using, an old Mac OS handle is "just a
pointer" also. After all, all the handle does is pointer to a place in
memory.
No, there is nothing more than a pointer in a reference. Nothing. Not a
single bit.
I don't think I need to reply to that statement one more time. You
already know what I'm going to write.
The code in the garbage collector is not stored inside every reference,
neither is all the data that the garbage collector uses.
I never said any of that was stored within a reference. Again, you
introduce entirely new concepts to disagree with, just for the sake of
rebuttal.
Pete
On Sat, 03 Mar 2007 00:15:41 +0800, Zytan <zy**********@yahoo.comwrote:
Pete, consider that it is optimized for the most gain as a whole.
One hopes (and I assume). However, it's not a given. If it turns out
that the memory scheme used by .NET is less efficient than other possible
schemes, well...let's just say that wouldn't be the first time some major
blunder was made when creating some computer architecture.
Most of the time, people get it right. But it's not a given that they
always do. I've been around long enough to know better than to just
assume that they have.
Meaning, if most often, things are only referenced once or twice, then
that's more important to make them fast than anything else, since
that's where the speed will be gained or lost.
Huh? I think you have that backwards. If something is referenced only
once or twice, then it doesn't matter how long it takes to resolve that
reference. It's when something is referenced a huge number of times that
the cost to resolve the reference is significant.
10x to update a single
reference? Yes, i know that single reference must be stored somehow
that allows other references to be in there, as well, in some kind of
data structure, or hash, or something, but, still. And, as you said,
even if it was 10x as bad as the "handle" scheme, we're probably still
ahead.
Well, except that I suspect that the difference in the relocation
algorithm is greater than 10x.
Also, isn't it unfair to compare it to the "handle" scheme? Shouldn't
you be comparing it to whatever other alternative the C# could have
used? Or, are you claiming the "handle" scheme IS something C# could
have used (I may have missed that)?
..NET (C# is just the compiler) certainly could have used the exact same
handle scheme. There's nothing fundamentally wrong with it. The major
disadvantage it has, of course, is that it does complicate resolving
references to objects. And it would require the compiler to do more
work. It introduces a variety of extra complexities in the compiled code
(eg, having to double-dereference all the time, having to remember to lock
the object when modifying the data, and the scheme wouldn't work nearly so
well in a true multitasking environment as it did in the cooperative
multitasking environment used in the old Mac OS), as a cost of simplifying
the garbage collection.
Pete
On Sat, 03 Mar 2007 05:06:53 +0800, Göran Andersson <gu***@guffa.com>
wrote:
I never said that you mentioned reference counting.
Do you really think that you are the only one that decides what the
discussion is about, and that noone else may mention anything that you
haven't brought up? ;)
When you are responding to points I've made (indicated by quoting my
post), then yes...it makes sense that you should limit your comments to
things that I've brought up. Or at least acknowledge that you are
introducing a new concept unrelated to the text to which you have
indicated you are commenting on.
[...]
The garbage collector actually does neither of what you claim that it
has to. ;)
I have not once claimed that the garbage collector does anything in
particular. I don't know anything about the inner workings of the garbage
collector other than what you and others have posted, and I'm making the
assumption that you and others know what you are talking about. Granted,
it's not always wise to make assumptions, but at this point it's all I've
got.
It only scans the data that is reachable from the application, not all
the data. There is no reason to look for references in objects that the
application can't reach anyway.
The garbage collector needs a map either of the objects allocated, or the
references in the application. Either way, it has to do a lot more work
than a handle-oriented scheme would (which does not need any information
at all about who is holding a reference to anything).
Pete
Peter Duniho wrote:
>The garbage collector actually does neither of what you claim that it
has to. ;)
I have not once claimed that the garbage collector does anything in
particular. I don't know anything about the inner workings of the
garbage collector other than what you and others have posted, and I'm
making the assumption that you and others know what you are talking
about. Granted, it's not always wise to make assumptions, but at this
point it's all I've got.
Ok, then let me quoute you:
"In the .NET paradigm, the collector has to either scan the entire
collection of data for each object it wants to move, or it has to
maintain some sort of hash table or other fast-access data structure in
which it stores (at least temporarily) all of the current references to
each given object (which is essentially the "reference reference table"
method anyway)."
There you claim that there is only two possible ways for the garbage
collector to work.
I agree with you that it's not always wise to make assumptions. When you
do, it might be a good idea to explain that it's just an assumption, so
that noone might do the mistake of thinking that you know what you are
talking about. ;)
--
Göran Andersson
_____ http://www.guffa.com
Peter Duniho wrote:
On Sat, 03 Mar 2007 04:34:20 +0800, Göran Andersson <gu***@guffa.com>
wrote:
>Because I keep explaining that there is nothing more than a pointer in
a reference, and you keep saying that there is more.
Huh? You can only rebut my post if you introduce new concepts to
disagree with, ones I never mentioned in the first place? That should
tell you something.
What new concept? Are you confused about what you have said yourself also?
>I have never said that there is no code for handling references. On
the contrary I have tried to explain this to you over and over.
You continue to claim that a reference is nothing more than a pointer.
But it is.
No, it's not.
If I believe your claim that you cannot consider any of the other things
surrounding that reference when considering whether it is more than a
pointer, then it's not even a pointer. It's just 32 bits. It's not a
pointer at all. It's just pure data, without any context whatsoever.
The difference is that the application code uses a pointer as a pointer,
not just 32 bits of data. Do you really fail to see this difference?
The concept of a pointer is not only handled by the compiler and the
memory management, as the concept of a reference is.
Conversely, once you start interpreting data as a specific kind of data,
you need to consider everything that interprets it. And a reference
definitely is not simply interpreted just as a pointer. It's a very
special kind of value that holds very special meaning beyond simply
describing a specific place in the virtual address space.
Yes, a reference truly is interpreted just as a pointer. There is
nothing in the application code that handles it differently from a
pointer in any way.
Likewise, using the logic you're using, an old Mac OS handle is "just a
pointer" also. After all, all the handle does is pointer to a place in
memory.
So you can take the handle and use it as a pointer? I thought that the
handle was a handle, not a pointer.
>No, there is nothing more than a pointer in a reference. Nothing. Not
a single bit.
I don't think I need to reply to that statement one more time. You
already know what I'm going to write.
No, I don't really know what you are going to write. Are you going to
claim that there is more inside a reference than a pointer? That the
size of a reference is more than the size of a pointer?
>The code in the garbage collector is not stored inside every
reference, neither is all the data that the garbage collector uses.
I never said any of that was stored within a reference. Again, you
introduce entirely new concepts to disagree with, just for the sake of
rebuttal.
I am just trying to understand what it is that you find so hard to
understand about references. You keep saying that there is more than
just a pointer, and only mention the garbage collector code and the data
it uses. If you don't believe that the garbage collector code is inside
each reference, what is it that you think is there?
--
Göran Andersson
_____ http://www.guffa.com
Huh? I think you have that backwards. If something is referenced only
once or twice, then it doesn't matter how long it takes to resolve that
reference. It's when something is referenced a huge number of times that
the cost to resolve the reference is significant.
I am speaking about updating reference pointers when GC moves the
object, not the run-time dereferencing of those points. So, I mean:
"only referenced once or twice" = the number of C# references to the
object is only 1 or 2. This occurs much more often than the number of
C# references to an object is >= 3. Thus, to optimize for speed, it
should be primarily be concerned with how to implement changing
pointers (when the GC moves the data) for cases where only 1 or two
references to the object exist.
10x to update a single
reference? Yes, i know that single reference must be stored somehow
that allows other references to be in there, as well, in some kind of
data structure, or hash, or something, but, still. And, as you said,
even if it was 10x as bad as the "handle" scheme, we're probably still
ahead.
Well, except that I suspect that the difference in the relocation
algorithm is greater than 10x.
I highly doubt whatever solution they used to update the 2 or so
pointers that it would take 10x longer than updating a single handle /
pointer. Possible, but very unlikely.
Considering how often GC causes this to happen is also an issue. If
it hardly ever happens, it really doesn't matter if it takes 100x as
long. As long as the code itself thinks pointers are just pointers
during the time that the GC isn't moving stuff around. THAT's what
happens most of the time of all these things, so that's what's
important for speed. This is why people say pointers are just
pointers. Because, to the code, they likely are. The GC just pauses
the universe to change things around once in a while, and then lets it
run, and the code doesn't know anything different. A pointer is just a
pointer. Hello speed. Everything else becomes much more irrelevant
for speed issues.
Zytan
Zytan wrote:
>>10x to update a single
reference? Yes, i know that single reference must be stored somehow
that allows other references to be in there, as well, in some kind of
data structure, or hash, or something, but, still. And, as you said,
even if it was 10x as bad as the "handle" scheme, we're probably still
ahead.
Well, except that I suspect that the difference in the relocation
algorithm is greater than 10x.
I highly doubt whatever solution they used to update the 2 or so
pointers that it would take 10x longer than updating a single handle /
pointer. Possible, but very unlikely.
Updating the references is just looping through a list and writing the
new value to the reference, so that is really a minor part of the
garbage collection process.
It takes a bit more work to find the references in the first place, but
that is also quite a small work compared to the work of actually moving
the objects, which is the same regardless of how they are referenced.
Considering how often GC causes this to happen is also an issue. If
it hardly ever happens, it really doesn't matter if it takes 100x as
long.
Actually it happens quite often, but only to a small part of the objects
that are handled. :)
In a garbage collection all objects in a heap generation that are still
used has to be moved to the next generation. Most objects are short
lived, so they will already be out of use at the time of their first
garbage collection sweep.
As long as the code itself thinks pointers are just pointers
during the time that the GC isn't moving stuff around. THAT's what
happens most of the time of all these things, so that's what's
important for speed. This is why people say pointers are just
pointers. Because, to the code, they likely are.
Not just likely. :)
The GC just pauses
the universe to change things around once in a while, and then lets it
run, and the code doesn't know anything different. A pointer is just a
pointer. Hello speed. Everything else becomes much more irrelevant
for speed issues.
--
Göran Andersson
_____ http://www.guffa.com
On Sat, 03 Mar 2007 21:03:43 +0800, Göran Andersson <gu***@guffa.com>
wrote:
Peter Duniho wrote:
>>The garbage collector actually does neither of what you claim that it
has to. ;)
I have not once claimed that the garbage collector does anything in
particular. [...]
Ok, then let me quoute you:
"In the .NET paradigm, the collector has to either scan the entire
collection of data for each object it wants to move, or it has to
maintain some sort of hash table or other fast-access data structure in
which it stores (at least temporarily) all of the current references to
each given object (which is essentially the "reference reference table"
method anyway)."
There you claim that there is only two possible ways for the garbage
collector to work.
Yes. The garbage collector must have some means of identifying references
to update. Either it looks for them each time, or has some data structure
that provides that information without requiring it to look for them each
time. This is a logical necessity. There are only two possibilities:
determine the references each time, or determine them ahead of time.
Making the trivially true statement that the garbage collector must do one
or the other doesn't even come close to making a statement about how the
garbage collector actually works.
That said, you are clearly on a single-minded quest to find fault in
whatever I write. I see no need to continue this course of discussion
with you, as it's completely unproductive. It seems only to serve to feed
whatever need it is you have, and frankly that's not among my list of
things to achieve in this lifetime.
Pete
Well, you know wrong then. Pointers can still be used in C# as below:
using System;
class a
{
unsafe public void calc(int x,int *p){
*p=x*x;
}
public static void Main()
{
int n=0;
unsafe{
int *p=&n;
a a1=new a();
a1.calc(12,p);
Console.WriteLine(n);
}
}
}
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Well, you know wrong then. Pointers can still be used in C# as below:
Yes, we've already established that.
The purpose of the question was to inquire what references really were
(to help my understanding of them). As I suspected, they are pointers
internally (that can be changed around internally when their objects
are moved to new location by the GC while the app is frozen, so it's
not a good idea to use their literal value and assume it'll be
constant, but that's not what I intended to do).
So, the question wasn't about if C# had pointers itself that can be
used as pointers like C, but to get an idea of what a reference is
really all about. It's easier to understand them when you know what's
under the hood.
Zytan
I am sure this must have come across your attention already. The pointer
used in the unsafe context would be assigned to the unmanaged memory
heap. Let me elaborate only on specific points as and when you come up
with them as otherwise, it may just turn out to be repeating things that
you may already know of.
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
J.V., thanks for the help, but this issue of mine has been resolved.
I understand it all, now, thanks to everyone for their help.
Zytan
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Canonical Latin |
last post by:
"Leor Zolman" <leor@bdsoft.com> wrote
> "Canonical Latin" <javaplus@hotmail.com> wrote:
>
> > ...
> >But I'm still curious as to the rational of having type
>...
|
by: Matteo Settenvini |
last post by:
Ok, I'm quite a newbie, so this question may appear silly. I'm using
g++ 3.3.x.
I had been taught that an array isn't a lot different from a pointer
(in fact you can use the pointer arithmetics to...
|
by: Linny |
last post by:
Hi,
I need some help in declaring an array of pointers to array of a
certain fixed size. I want the pointers to point to arrays of fixed
size only (should not work for variable sized arrays of the...
|
by: Charles Banas |
last post by:
i've got an interesting peice of code i'm maintaining, and i'd like to
get some opinions and comments on it, hopefully so i can gain some
sort of insight as to why this works.
at the top of the...
|
by: Me |
last post by:
Just a question/observation out of frustration.
I read in depth the book by Peter Van Der Linden entitled
"Expert C Programming" (Deep C Secrets). In particular the
chapters entitled:
4: The...
|
by: masood.iqbal |
last post by:
All this time I was under the illusion that I understand the concept of
multi-dimensional arrays well ---- however the following code snippet
belies my understanding.
I had assumed all along...
|
by: raphfrk |
last post by:
I have the following code:
char buf;
printf("%lp\n", buf);
printf("%lp\n", &buf);
printf("%lp\n", buf);
printf("%lp\n", buf);
printf("%d\n", buf-buf);
|
by: Nathan Gilbert |
last post by:
I have a function that is returning a 2D array (declared using double pointers)
and I want to be able to append a row of data to the beginning and end of this
array without having to create a new...
|
by: I.M. !Knuth |
last post by:
Hi. I'm more-or-less a C newbie. I thought I had pointers under control until
I started goofing around with this:
...
|
by: Christian Maier |
last post by:
Hi
After surfing a while I have still trouble with this array thing. I
have the following function and recive a Segmentation fault, how must
I code this right??
Thanks
Christian Maier
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
