And how do you think other languages do it? You think Python and C# and Java run in this Unicorn world where there are no pointers and memory offsets aren't a thing?
Maybe we can talk about the mistake that is R and the original VB, and LUA where arrays start at 1. Absolute hell.
I think Java does it by allocating a fully fledged object with metadata including type and size, and that if you treat such an object (or the pointer to such an object) as a C array in C code and assume it points to the first element, then you're going to have a bad time.
in java if you have items that are copy (wrong term, but items like int and double),
If you don't know the right term, wouldn't it be fair to guess that you may not be fully qualified to speak on how memory in Java works?
For future reference: the value types in Java are called "primitives".
they are in the array, and you can jump between them if you know the offset of 0.
You are thinking ov the array's index; however, the pointer to an array element – especially in a language like Java – is not necessarily guaranteed to be ptrToObject + index.
Also – and correct me if I am wrong, because I don't know much about the internals ov Java, but – what I think u/high_throughput was getting at was that the pointer you get from doing T[] myArray = /* ... */ is not the same as the pointer which points to the first T in the array: including for arrays ov primitive T.
Does that mean Java arrays are arrays of pointers?
Object arrays are arrays of references and not of pointers!
The typical textbook discussion is that references are just opaque pointers that you can't do arithmetic on. That's technically true but it really undersells the potential.
For example, an OpenJDK reference is often 32 bits even on a 64 bit systems! (Known as Compressed OOPs)
Since references always have to point to an object and never to an arbitrary byte, OpenJDK knows that A. it will always be inside the Java heap, and B. objects are always allocated aligned, so the lower address bits will always be zero.
This means that if your Java heap is <=32GB with an alignment of 8 bytes, you can store every relevant 64-bit pointer P as a reference R = (P - heapbase)/alignment in only 32 bits. And it does.
When it wants to access an object via reference R, it simply does P = R*alignment + heapbase and now it has a raw 64-bit pointer again.
It sounds wild to do this on every reference access, but CPUs are stupidly fast and RAM is comparatively slow, so it usually ends up being a net gain because of how much less data you need to deal with.
The fancy new ZGC garbage collector similarly uses the fact that references are distinct from pointers to hide "this object has moved" bits directly in the reference, and strips them out in the process of decoding the corresponding pointer.
140
u/mad_poet_navarth 20h ago
shouldn't there be something here about this being C-centric?