 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006How large is an object reference?
Hi All, How large is an object reference? Not the object itself, just a reference to it. I.e. Object a = new Object(); b = a; c = a; How much memory to a, b and c take - not the object I made. :) Rob :) maybe two bytes 4 bytes at most. -------------------- Paul Hamaker, SEMM, teaching ICT since 1987 http://javalessons.com Thanks for the replies. Does any Java spec state this - or some reasoning behind the answer <=4 bytes? Read this http://en.wikipedia.org/wiki/Reference_%28computer_science%29, may be helpful On 22 Feb 2006 01:06:16 -0800, "Robert Mark Bram" <relaxedrob@optusnet.com.au> wrote, quoted or indirectly quoted someone who said : >Thanks for the replies. Does any Java spec state this - or some >reasoning behind the answer <=4 bytes? Why would you need any more than what a machine address takes? If you make it a different size, you introduce a layer of indirection that slows thing down. When writing a JVM the key thing to speed is to work directly with hardware machine addresses. If you don't, you will drop immediately to half speed or worse. Ask anyone who has written a FORTH engine, e.g. me.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > How large is an object reference? Not the object itself, just a > reference to it. Depends on the JRE. Typically a 32-bit JRE will use 32-bits per reference. A 64-bit JRE will use 64-bits per reference. In Java byte code references appear as if they take up the same space as an int. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > Depends on the JRE. Typically a 32-bit JRE will use 32-bits per > reference. A 64-bit JRE will use 64-bits per reference. > > In Java byte code references appear as if they take up the same space as > an int. Two mutually exclusive statements since ints have a fixed size on any JVM. http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9151 -Paul > > Depends on the JRE. Typically a 32-bit JRE will use 32-bits per > > reference. A 64-bit JRE will use 64-bits per reference. [quoted text clipped - 3 lines] > > Two mutually exclusive statements since ints have a fixed size on any JVM. They may well be mutually exclusive. They are nevertheless true. At the bytecode level, references to objects do indeed fit into the same space as that used for ints. (As I've already mentioned in this thread.) -- chris > At the bytecode level, references to objects do indeed fit into the same space > as that used for ints. (As I've already mentioned in this thread.) Oops, my mistake then. I had incorrectly made the assumption that object references would be a VM dependent feature, but of course they do have a representation in bytecode which has to be well specified. Apparently both are the size of a Java int. -Paul On Tue, 28 Feb 2006 09:56:11 -0000, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >At the bytecode level, references to objects do indeed fit into the same space >as that used for ints. (As I've already mentioned in this thread.) however, peek inside a 64-bit JVM and you will see references are 64 bits and ints 32, right? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > How large is an object reference? Not the object itself, just a > reference to it. Totally implementation dependent. Normally JVMs use either 32 or 64 bits. It'll typically be the size of a "pointer" on the same machine architecture -- mainly because it typically /is/ a pointer ;-) No realistic implementation for desktop or bigger apps would use less than 32 bits -- that would put far too tight limits on the total number of objects in existence at any one time, and without any corresponding gain. It seems plausible that implementations for /very/ resource-constrained device would accept a 16-bit limit if the amount of RAM were so limited that halving the size of a reference was important, and there wasn't enough RAM to hold anything like 64K objects. Interestingly[*] the JVM spec requires references to fit into the same sized stack slot as is used for 32-bit quantities. I don't know how implementers manage to kludge that. The only options I can think of are to use 64-bit slots for everything or to do control-flow analysis (like the verifier) to discover which logical slots have to be 64 bits wide and which can get away with only 32. Either way (or whatever other options there may be) I can't imagine 64-bit implementers being too pleased with the extra work ;-) BTW does anyone know if any ostensibly 64-bit JVMs use hybrid pointer sizes ? For instance they could represent the hidden pointer from an object to its class/vtable/whatever in 32-bits which looks (at first glance) like a simple but useful optimisation for space. -- chris ([*] or maybe not...) On Wed, 22 Feb 2006 12:18:11 -0000, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >nterestingly[*] the JVM spec requires references to fit into the same sized >stack slot as is used for 32-bit quantities. I don't know how implementers [quoted text clipped - 3 lines] >32. Either way (or whatever other options there may be) I can't imagine 64-bit >implementers being too pleased with the extra work ;-) the byte code verifier is one of the under heralded features of Java. You can statically study java byte code and KNOW with absolute certainty what will be on stack and what type of data it is an any point in the flow. The stack looks identical (at least the elements added since your method started) every time you run the program past a given point in the code. With this knowledge, it is fairly easy to generate code that has any size of address REALLY on the stack. JVM byte code is like a strongly typed assembler. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > the byte code verifier is one of the under heralded features of Java. It's certainly one of the most grossly under-specified. > You can statically study java byte code and KNOW with absolute > certainty what will be on stack and what type of data it is an any > point in the flow. The stack looks identical (at least the elements > added since your method started) every time you run the program past a > given point in the code. This is often called the "Gosling property". It's a slightly ironic name since the Gosling property doesn't actually hold -- you must take account of the effect of jsr/ret instructions too. They complicate analysis considerably, see Section 4.9.6 of the JVM spec. As far as I know, Sun are backing off from using jsr/ret to implement finally clauses (they already don't use it for anything else). Maybe in a few years Sun will change the spec so that jsr/ret are not allowed in classfiles intended to run on <some version> or later JVMs. Until then, and for any (future) JVM implementation that need backward compatibility, they are a right pain. Etienne Gagnon's thesis, part of the documentation for the Sable JVM, which is available at: http://sablevm.org/docs.html is an interesting read. Section 6.1.2 talks about the difficulties caused by jsr/ret, and the rather simple but effective solution that he uses. -- chris On Wed, 22 Feb 2006 12:18:11 -0000, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >BTW does anyone know if any ostensibly 64-bit JVMs use hybrid pointer sizes ? >For instance they could represent the hidden pointer from an object to its >class/vtable/whatever in 32-bits which looks (at first glance) like a simple >but useful optimisation for space. I have been wondering the same thing. How does Java keep separate caches of objects of different size and age so that it can rapidly only deal with a GC of one collection? The key is simple. You don't need any magic bits in the references. All the objects in a given cache will lie in a band of addresses, the low and high bound of that cache. You have to still chase the entire tree of objects, but you only have to rescue the objects in the band of the cache you are garbage collecting. This leads me to speculate. What could you do in hardware to speed up GC? A whacking huge parallel block move mini-CPU for compacting objects that worked with an independent background processor that ate any unused memory cycles would help. It could get dozens of moves behind the GC algorithm without causing much trouble. The other half of GC which is unclear to me is how you go about patching all the references to an object when you move it? Do you maintain a giant threaded list of referrers to every address? You would have reconstruct the list from scratch on every GC. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > The other half of GC which is unclear to me is how you go about > patching all the references to an object when you move it? > Do you maintain a giant threaded list of referrers to every address? > You would have reconstruct the list from scratch on every GC. You might find Lins's book "Garbage Collection" interesting. A bit pricey, but (IMO) very good. If you are talking about "ordinary" copying GC, then the block of memory you are copying /from/ acts as the list. You stuff a forwarding pointer into some no-longer-needed part of the object when you copy it. Then subsequent references to that object's old address can be fixed up as/when you find them. -- chris On 23 Feb 2006 17:09:32 GMT, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >If you are talking about "ordinary" copying GC, then the block of >memory you are copying /from/ acts as the list. You stuff a forwarding >pointer into some no-longer-need I guess the trick is figuring out where all the objects will go before you start moving anything. Then you can put the forwarding addressees in the old object before you start. Otherwise when you went to move an object, you could only do the fixups in it of the objects that had already been moved. Otherwise you would need a great todo list of fixups to do later once you knew the new addresses. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Hi All, > [quoted text clipped - 7 lines] > > How much memory to a, b and c take - not the object I made. :) An object reference is tied to the object so as it can act as a reference. The reference itself contains 1) a reference count and 2) a pointer to the object. The size of the pointer is architecture dependant. I could'nt find the size of the reference counter, but its probably 8, 16 or 32 bits. Each of the A B and C are pointers to the reference to they are platform specific, f.ex 32 bit. I have explained it a bit awkward, but a reference is a pointer to a pointer. Where the first pointer is A, B or C and the second pointer is a structure containing the reference counter and the pointer to the object. The second pointer (structure) is shared between all A, B and C, thats why you have reference counters which now should have the value 3. hope that helps:) /tom >> Hi All, >> [quoted text clipped - 24 lines] > > hope that helps:) What's the reference count for? > What's the reference count for? It doesn't exist. See my reply. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > An object reference is tied to the object so as it can act as a > reference. The reference itself contains 1) a reference count and 2) a > pointer to the object. The size of the pointer is architecture > dependant. I could'nt find the size of the reference counter, but its > probably 8, 16 or 32 bits. There is no reference count. If the VM were to implemenmt reference counting, the reference count would be part of the object, not part of the reference. However, no widely used virtual machine actually uses that technique. Instead, they use copying collection or mark/sweep collection, or some combination thereof. Reference counting is not used in real life because suffers from correctness problems, and the only known solutions involve sophisticated DAG algorithms and are unreasonably slow for that use. > I have explained it a bit awkward, but a reference is a pointer to a > pointer. No, that's not true either. It is true that very old versions of Sun's reference implementation of the Java virtual machine (versions up to, but not including, 1.2) did things that way. When they did, it was common to use the word "handle" to describe it. The word "reference" is defined by the Java Language Specification as a type that can hold either null or a pointer to an object. It is unspecified whether the pointer is indirect, or contains a direct memory address. In practice, though, it's a direct memory address. Around the mid to late 90s, a few people confused the word "reference" with the implementation details of Sun's implementation. For most of the last decade, though, it's been widely acknowledged that this is a mistake. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >> An object reference is tied to the object so as it can act as a >> reference. The reference itself contains 1) a reference count and 2) a [quoted text clipped - 3 lines] > > There is no reference count. Fair enough, I apologise for misinforming. After reading up on it, I realise that I did actually know that, but last time i remember using that knowledge was in 2002, So, no wonder I forgot about it. >> I have explained it a bit awkward, but a reference is a pointer to a >> pointer. [quoted text clipped - 7 lines] > pointer is indirect, or contains a direct memory address. In practice, > though, it's a direct memory address. I seem to have misinterpreted some information I read a couple a months ago, which was based on the above assumption, hence the conclusion was wrong. Thanks for pointing it out to me. /tom >The reference itself contains 1) a reference count and 2) a >pointer to the object. no, not in Java. There are no reference counters. see http://mindprod.com/jgloss/garbagecollection.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On 22 Feb 2006 00:33:36 -0800, "Robert Mark Bram" <relaxedrob@optusnet.com.au> wrote, quoted or indirectly quoted someone who said : >How large is an object reference? Not the object itself, just a >reference to it. usually 32 bits on a 32 bit addressable machine and 64-bits on a 64 bit one. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. 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.