On Wednesday, 7 May 2014 at 14:44:57 UTC, Yuriy wrote:
> Hello, is there a way of reducing size of an empty class to just vtbl? I tried to declare it as extern(C++) which works, but has a nasty side effect of limited mangling.

Just a general FYI:

Classes are relatively heavyweight in D. struct-based approaches are often favoured, as can be seen across the more heavily developed parts of phobos.

> How many of these? In order to justify saving 8 bytes per instance, you have have a lot. I don't see emplacing thousands or tens of thousands of objects on the stack.
Ok, i guess i have to agree with you. But. Why are you protecting __monitors so eagerly? :)

> Arrays of objects are stored as arrays of object references, with each one pointing at a separate block on the heap.
Or again you can emplace them in the heap, so that they occupy a continuous chunk.

> In D, class is not used for such things, struct is.
But classes have vtbls which is an ultimate feature for me, and moreover, it works in ctfe, while "reinventing" vtbls for ctfe might be a challenging task.

> I'm assuming you want D classes, but without the monitor object. D classes derive from Object.
> "Any chance to avoid monitor field in my class?" Those are your words. What is it that you want?
Thats right. I was saying that extern(C++) almost suits me except for it's mangling. And you said that extern(C++) classes are not derived from Object? But still such objects would have RTTI which will forbid casting to Object, wouldn't they?

> shared != thread safe. You still need to synchronize
Ok. So shared class is not a reason to omit __monitor field, as it still can be used, am i right here?

Yuriy:

> But. Why are you protecting __monitors so eagerly? :)

Also take a look at the Rust language, that avoids some of your problems :-)

Bye,
bearophile

> Also take a look at the Rust language, that avoids some of your problems :-)
Done already =). Rust is great, but I like D, and i strongly believe it's the next big language. If only it could allow a bit more tweaks ;)

On Thu, 08 May 2014 17:05:56 -0400, Yuriy <yuriy.glukhov@gmail.com> wrote:

>> How many of these? In order to justify saving 8 bytes per instance, you have have a lot. I don't see emplacing thousands or tens of thousands of objects on the stack.
> Ok, i guess i have to agree with you. But. Why are you protecting __monitors so eagerly? :)

I'm not, I'm trying to help you justify the path your taking :) Because where it's currently leading is somewhere that D doesn't support. This means in order to support it, you have to maintain a parallel compiler, or somehow convince the compiler writers to add such support. Neither of these burdens is small.

>> Arrays of objects are stored as arrays of object references, with each one pointing at a separate block on the heap.
> Or again you can emplace them in the heap, so that they occupy a continuous chunk.

This is not a good idea. The dtors of classes in the GC is stored per block, not per chunk of a block.

>> In D, class is not used for such things, struct is.
> But classes have vtbls which is an ultimate feature for me, and moreover, it works in ctfe, while "reinventing" vtbls for ctfe might be a challenging task.

Removing the monitor could also prove quite challenging.

I don't doubt your reasons, but then again, you have what you have right now in D. Asking for more, you have to provide it, or convince others to. If it's the latter, you need to make a very very strong case.

>
>> I'm assuming you want D classes, but without the monitor object. D classes derive from Object.
>> "Any chance to avoid monitor field in my class?" Those are your words. What is it that you want?
> Thats right. I was saying that extern(C++) almost suits me except for it's mangling. And you said that extern(C++) classes are not derived from Object? But still such objects would have RTTI which will forbid casting to Object, wouldn't they?

extern(C++) objects are not considered D objects. A D object can implement a C++ interface, but once you get to the C++ interface, you cannot go back.

This sounds to me very different from your goal.

-Steve

> I don't doubt your reasons, but then again, you have what you have right now in D. Asking for more, you have to provide it, or convince others to. If it's the latter, you need to make a very very strong case.
I want to provide it, but before i do, i want to know if there were any decisions made earlier, that would render my work useless. I mean, i have to know all possible cons for not having __monitor in an instance.

What i suggest is the following:
- Object does not have any __monitor field by default.
- One can add a __monitor object to his class.
- Offset to monitor is stored in TypeInfo. -1 if doesn't exist.
- synchronized() inspects typeInfo. If an object has monitor, then it is used. Otherwise, the monitor is allocated/looked up in a global hash-table from object pointer to monitor.

This way we could achieve performance in terms of both speed and memory. Also old code would not break.

Some additional optimizations might always include a __monitor field to a class, if compiler can prove, that this class is being synchronized on.

Yuriy:

> but I like D, and i strongly believe it's the next big language.

Oh, good. Do you want to briefly explain why? :)

Bye,
bearophile

Imho, offtop, also i'm a C++/Obj-C guy and that might partially explain my preferences, but here are some more reasons:
1. I like the concept of CT-reflection and CTFE a lot. This makes metaprogramming extremely powerful without any RT overheads. It brings a lot more control to what goes to RT. I guess D still needs to shrink it's runtime a bit more, and __monitors is just another example of that.
2. It's extremely easy for C++/C#/Java/Objc-C developers to switch to D without loosing any bit of their productivity, but gaining lots of possibilities, that can be used in future. And C++/C#/Java/Obj-C is the majority of the world now. Even PHP developers should think of D one day =).
3. That's the most arguable, but D's syntax and semantics looks much cleaner and uniform to me than Rust's.

One thing I hate about C# (which is what I use professionally) is
the sync block index in every single class instance. Why not have
the developer decide when he needs a Monitor and manually use
it?! I am disappointed D took the same route.

On Friday, 9 May 2014 at 14:56:21 UTC, flamencofantasy wrote:
> One thing I hate about C# (which is what I use professionally) is
> the sync block index in every single class instance. Why not have
> the developer decide when he needs a Monitor and manually use
> it?! I am disappointed D took the same route.

If it can be changed without breaking existing code, you might be able to convince people to make it somehow optional or elided when unnecessary.