January 04, 2023
On 1/4/23 10:48, H. S. Teoh wrote:

> Allocations are not necessarily consecutive; the GC may have its own
> strategy of allocation that doesn't follow a linear sequence.

That was one of my guesses. So, I put the objects into a 2-length static array but the difference was still 0x20. (?)

> Furthermore, GC-allocated blocks may be larger than the request size
> because there may be some extra management information stored in the
> block (but outside the pointer range returned).

Good point. I think the minimum size of a dynamically allocated memory of the current GC implementation is 32 bytes.

I've just realized that I was confusing myself by thinking the object pointer that cast(void*) produces was the first member's address. I was wrong: That is the address of the first of the two hidden members (the vtbl pointer and the monitor).

My current guess is, although it could be a void*, the alignment of the first of those hidden members is 16.

Now that I have a more correct understanding, the following program prints those hidden members. One of the examples shows the monitor of an object used with 'synchronized' is non-null.

import std.stdio, std.traits;

class MyClass {
    char[1] c;
}

void main() {
    writeln(" Size  Alignment  Type\n",
            "=========================");

    size_t size = __traits(classInstanceSize, MyClass);
    size_t alignment = classInstanceAlignment!MyClass;
    writefln("%4s%8s      %s",size, alignment, MyClass.stringof);

    // Apologies for using lower-cased variable names. :)
    auto a = new MyClass();
    auto b = new MyClass();

    printObject!a;
    printObject!b;

    auto withMonitor = new MyClass();

    synchronized (withMonitor) {
        // This object's "hidden 1" (the monitor) will not be 'null'
        printObject!withMonitor;
    }

    // This object's "hidden 0" (vtbl pointer) will be different:
    class SubClass : MyClass {
    }
    auto sub = new SubClass();
    printObject!sub;
}

void printObject(alias obj)() {
    writeln("\n");
    writeln("name        : ", obj.stringof);

    const addr = cast(void*)obj;
    writeln("address     : ", addr);
    writeln("hidden 0    : ", hiddenValue(addr, 0));
    writeln("hidden 1    : ", hiddenValue(addr, 1));
}

void* hiddenValue(const(void)* obj, size_t index) {
    alias HiddenType = void*;
    auto ptrToHiddens = cast(HiddenType[2]*)obj;
    return (*ptrToHiddens)[index];
}

Here is the output:

 Size  Alignment  Type
=========================
  17       8      MyClass


name        : a
address     : 7F4009D48000
hidden 0    : 558A1E172520
hidden 1    : null


name        : b
address     : 7F4009D48020
hidden 0    : 558A1E172520
hidden 1    : null


name        : withMonitor
address     : 7F4009D48040
hidden 0    : 558A1E172520
hidden 1    : 558A20164B80  <-- non-null monitor


name        : sub
address     : 7F4009D48060
hidden 0    : 558A1E172630  <-- Different vtbl for sub-class
hidden 1    : null

Ali

January 04, 2023
On 1/4/23 11:27, Ali Çehreli wrote:

>      writeln("hidden 0    : ", hiddenValue(addr, 0));
>      writeln("hidden 1    : ", hiddenValue(addr, 1));

Silly me! :) Those members have names:

    writeln("__vptr      : ", obj.__vptr);
    writeln("__monitor   : ", obj.__monitor);

  https://dlang.org/spec/abi.html#classes

Ali

January 04, 2023

On 1/4/23 2:27 PM, Ali Çehreli wrote:

>

On 1/4/23 10:48, H. S. Teoh wrote:

>

Allocations are not necessarily consecutive; the GC may have its own
strategy of allocation that doesn't follow a linear sequence.

That was one of my guesses. So, I put the objects into a 2-length static array but the difference was still 0x20. (?)

Are you putting the class references in a 2-length static array? That's just going to be 2 pointers in an array, and won't affect where they are allocated on the heap.

> >

Furthermore, GC-allocated blocks may be larger than the request size
because there may be some extra management information stored in the
block (but outside the pointer range returned).

Good point. I think the minimum size of a dynamically allocated memory of the current GC implementation is 32 bytes.

It is 16 bytes, but there are no 24-byte bins. Here are the bin sizes:

https://github.com/dlang/dmd/blob/4dc7259a89950b0a0feda05b8c35e52cadd00c95/druntime/src/core/internal/gc/impl/conservative/gc.d#L1402-L1424

And of course, this could change again.

Basically, follow H. S. Teoh's advice, stop worrying about the addresses given out by the GC, it's not important.

-Steve

January 04, 2023
On 1/4/23 12:02, Steven Schveighoffer wrote:
> On 1/4/23 2:27 PM, Ali Çehreli wrote:

>> I put the objects into a 2-length
>> static array but the difference was still 0x20. (?)
>
> Are you putting the class *references* in a 2-length static array?

I lied. As I could not put the objects in a static array, I put them on the stack with the 'scope' keyword and the difference was still 0x20. (Of course, I could emplace the objects myself in my static array but that wouldn't prove anything about why the current alignment appears to be 0x20.)

> stop worrying about the addresses
> given out by the GC

No worries; just trying to explain...

Ali

January 04, 2023
On Wed, Jan 04, 2023 at 01:20:12PM -0800, Ali Çehreli via Digitalmars-d-learn wrote:
> On 1/4/23 12:02, Steven Schveighoffer wrote:
> > On 1/4/23 2:27 PM, Ali Çehreli wrote:
> 
> >> I put the objects into a 2-length
> >> static array but the difference was still 0x20. (?)
> >
> > Are you putting the class *references* in a 2-length static array?
> 
> I lied. As I could not put the objects in a static array, I put them on the stack with the 'scope' keyword and the difference was still 0x20. (Of course, I could emplace the objects myself in my static array but that wouldn't prove anything about why the current alignment appears to be 0x20.)

You do realize that the compiler is free to reorder local variables on the stack, right? ;-)  Generally it doesn't, but nothing in the spec precludes it from doing so.  Highly-optimizing compilers like ldc also tend to move code around, and with it, any associated local variables, so exactly where something is put on the stack isn't really something you can rely on.

And of course, stuff on the stack may also be subject to alignment requirements depending on your CPU/architecture. Though generally speaking this shouldn't be any stricter than alignment requirements on general heap/GC allocations.


> > stop worrying about the addresses given out by the GC
> 
> No worries; just trying to explain...
[...]

I think at this point any explanation is likely to involve many more implementation-specific details than is warranted for understanding D code. :-P  It can of course be extremely interesting (and instructive) to know about these details, but one has to keep in mind that the deeper one digs, the more non-portable these implementation details become, and the more divergences you'll see across different CPUs and OSes.


T

-- 
Insanity is doing the same thing over and over again and expecting different results.
January 04, 2023
On 1/4/23 13:43, H. S. Teoh wrote:

> You do realize that the compiler is free to reorder local variables on
> the stack, right? ;-)

Of course. :)

I was trying different strategies to catch the compiler (dmd here) in a single act of 8-byte object alignment as reported by .alignof.

Another thing the compiler is free for class members is to reorder them. I also theorized perhaps the compiler was also considering the alignment of a member. But as expected, char[1] does have 1 alignment and it can't be the reason in this case. (Again, there is no problem here; we are just learning.)

> implementation-specific details

RazvanN or Dennis may chime in on that.

Ali

January 05, 2023
>

(Again, there is no problem here; we are just learning.)
Ali

Do I have this much right?

import std.stdio, std.traits;
class MyClass {char c;}

void main() {
    auto MyInt = 1;
    writeln("The address of MyInt is      :  ",&MyInt," (stack)");
    auto MyClassVar1 = new MyClass();
    writeln("The address of MyClassVar1 is:  ",&MyClassVar1," (stack)");
    auto MyClassVar2 = new MyClass();
    writeln("The address of MyClassVar2 is:  ",&MyClassVar2," (stack)");

    writeln;

    auto MyClassObj1 = cast(void*)MyClassVar1;
    writeln("The address of MyClassObj1 is: ",MyClassObj1," (heap)");
    auto MyClassObj2 = cast(void*)MyClassVar2;
    writeln("The address of MyClassObj2 is: ",MyClassObj2," (heap)");
}

..with this output?

The address of MyInt is      :  1CA1CFFB1C (stack)
The address of MyClassVar1 is:  1CA1CFFB10 (stack)
The address of MyClassVar2 is:  1CA1CFFB08 (stack)

The address of MyClassObj1 is: 1EB93212000 (heap)
The address of MyClassObj2 is: 1EB93212020 (heap)
January 04, 2023
On 1/4/23 20:04, Paul wrote:
>> (Again, there is no problem here; we are just learning.)
>> Ali
>
> Do I have this much right?

> ..with this output?

Looks good to me.

While we're here, you can force the class objects to be on the stack as well:

    scope MyClassVar1 = new MyClass();

I replaced 'auto' with 'scope'.

Ali

January 05, 2023
On Thursday, 5 January 2023 at 04:04:39 UTC, Paul wrote:
>
> ..
> Do I have this much right?
> ...

First, i would say, add @safe to your main.

@safe void main() ...

Then you will see you are treading on dangerous waters ;-)

Second, to be sure your getting the correct results, it would be nice if there was a 'category of type' in std.traits for:

isAllocatedOnStack
isAllocatedOnHeap

As it is, your just guessing (although the addresses printed will clear this up for you anyway I guess).

Also, I cannot read hex, so if it were me, I'd be casting the hex into an size_t:

cast(size_t)&MyInt

January 05, 2023
On Thu, Jan 05, 2023 at 06:32:47AM +0000, areYouSureAboutThat via Digitalmars-d-learn wrote: [...]
> Second, to be sure your getting the correct results, it would be nice if there was a 'category of type' in std.traits for:
> 
> isAllocatedOnStack
> isAllocatedOnHeap
> 
> As it is, your just guessing (although the addresses printed will clear this up for you anyway I guess).

In general, it's not possible to determine whether an arbitrary reference is pointing to the stack or the heap, because it could have come from anywhere.  You can only determine this if you are privy to the internal implementation details of the allocator or code that created the reference (GC, other allocator, or whatever took an address of a stack-allocated object), or the platform-specific details of your runtime environment (range of stack addresses).


> Also, I cannot read hex,
[...]

IMNSHO, anyone who claims to be a programmer should at least know that much.  As Knuth once said,

	People who are more than casually interested in computers should
	have at least some idea of what the underlying hardware is like.
	Otherwise the programs they write will be pretty weird.
	-- D. Knuth


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall