On 5/14/14, 6:33 AM, Yuriy wrote:
> On Wednesday, 14 May 2014 at 13:07:32 UTC, bearophile wrote:
>> I'd like to know why you think D classes should not have the monitor
>> on default (this means why you don't plan for a @no_pointer).
> There are 4 reasons for that.
> 1. I'm thinking of monitors as members of Object class, so all other
> classes have monitors just because they are inheriting it. So with my
> proposal you would be able to add a monitor, but not remove it.

Agreed.

> 2. Mutex synchronization is pretty old-school approach, there's a lot of
> cons to using it, and thus it should not be carved into the language core.

Agreed.

> 3. I can't imagine a project that has more than 10% of it's classes
> being synchronized on, so this feature looks like more often unneeded
> than needed.

Agreed.

> 4. I consider D a killemall language, that may be potentially used on
> tiny AVRs and PICs, where polymorphism might be welcome, but an extra
> pointer for each class instance may become a blocker. I know, thats
> fantasy now, but i think it's crucial to keep this concept of D.

Agreed at least with the "killing the mall" part :o).


Andrei

On Wednesday, 14 May 2014 at 19:08:30 UTC, bearophile wrote:
> You are good. Before this is ready for Walter's judgement I think this needs some simple performance/memory benchmarks, to compare the situation before and after this change.
I've made some minor optimizations, and rebased everything on current master (both dmd and druntime).
Also here is a simple test i've run:
http://dpaste.dzfl.pl/f44762a17fe4

You-have-no-choice-but-pay-the-price-monitors:
max: 8709, min: 3227, average: 3484

Optional inlined monitor:
max: 12010, min: 5136, average: 5361

Optional missing monitor: no need to measure for obvious reasons.

So yeah, my monitors are like %50 slower, but
1. does it really matter?
2. i think further optimizations may be done here. The best way i see it is to make _d_monitorenter/exit to be templates so that monitored classes will be at least as fast as current monitors, and even faster if _d_monitorenter/exit will be inlined. But anyway such optimization may be done later if needed, without any code breaking changes.

Yuriy:

> http://dpaste.dzfl.pl/f44762a17fe4

As workaround for a D design bug I suggest to write code like this:
foreach (immutable c; 0 .. 100_000)

Instead of:
foreach(c; 0..100000)

Because unfortunately by default that c index is not immutable, and this causes significant troubles if you mutate it by mistake.

Bye,
bearophile

On Wednesday, 14 May 2014 at 09:16:21 UTC, Yuriy wrote:
> On Wednesday, 14 May 2014 at 08:37:41 UTC, bearophile wrote:
>> What's the syntax to define a class without its __monitor? Are you using an annotation like @no_monitor?
> No syntax for that. The __monitor is not present by default anywhere. If you need it, you need to define one.
>
> class A
> {
>
> }
>
> class B
> {
>     void* __monitor;
> }
>
> {
>     A a = new A(); // sizeof a instance is 8
>     B b = new B(); // sizeof b instance is 16
>     synchronized(a)
>     {
>         // Internally allocates a monitor and place it to global monitor hash map. On synchronize, search the hash map for already created monitors.

Global hashmap is a bad idea IMO because it's possibly expensive and impure. Rather deprecate synchronizing on classes without an explicit monitor.

>     }
>
>     synchronized(b)
>     {
>         // Internally allocates a monitor, and sets b.__monitor to it. Pretty much like it was done before, except that __monitor field may now have different offset.
>     }
A UDA on the class is cleaner than adding magic members.
> }
>
> So the semantics remains the same, you just may want to define a __monitor field if you want better performance.

On 5/14/2014 2:17 PM, Andrei Alexandrescu wrote:
> On 5/14/14, 6:33 AM, Yuriy wrote:
>> 4. I consider D a killemall language, that may be potentially used on
>> tiny AVRs and PICs, where polymorphism might be welcome, but an extra
>> pointer for each class instance may become a blocker. I know, thats
>> fantasy now, but i think it's crucial to keep this concept of D.
>
> Agreed at least with the "killing the mall" part :o).

While I agree with Andrei's agreements (!), the rationale for the current approach is to make it relatively straightforward to translate existing Java code into D. There was a fair amount of this in the early days of D, I'm not sure how much of that lately.

On Sunday, 18 May 2014 at 04:44:56 UTC, Martin Nowak wrote:
> Global hashmap is a bad idea IMO because it's possibly expensive and impure. Rather deprecate synchronizing on classes without an explicit monitor.
Totally agreed. Hashmap is done just not to break existing code. I don't think i've got the right to deprecate anything with my PRs =).

> A UDA on the class is cleaner than adding magic members.
Yes, my PRs already include that.

On Sunday, 18 May 2014 at 05:01:21 UTC, Walter Bright wrote:
> While I agree with Andrei's agreements (!), the rationale for the current approach is to make it relatively straightforward to translate existing Java code into D. There was a fair amount of this in the early days of D, I'm not sure how much of that lately.
This is a great way to attract Java/C# communities by making D looking familiar, when possible. And i think it has to continue being like so, until D conquers the world =). As to builtin/optional monitors currently my PRs do not change anything in that sense.

But even if we later deprecate synchronizing on non-@monitored classes, it still remains trivial to fix when porting from Java.

On 5/17/14, 10:01 PM, Walter Bright wrote:
> On 5/14/2014 2:17 PM, Andrei Alexandrescu wrote:
>> On 5/14/14, 6:33 AM, Yuriy wrote:
>>> 4. I consider D a killemall language, that may be potentially used on
>>> tiny AVRs and PICs, where polymorphism might be welcome, but an extra
>>> pointer for each class instance may become a blocker. I know, thats
>>> fantasy now, but i think it's crucial to keep this concept of D.
>>
>> Agreed at least with the "killing the mall" part :o).
>
> While I agree with Andrei's agreements (!), the rationale for the
> current approach is to make it relatively straightforward to translate
> existing Java code into D. There was a fair amount of this in the early
> days of D, I'm not sure how much of that lately.

Maybe I misunderstood - I thought the change preserves semantics. -- Andrei

Andrei Alexandrescu:

> Maybe I misunderstood - I thought the change preserves semantics. -- Andrei

Perhaps it's Walter that has misunderstood.

Bye,
bearophile

On Sunday, 18 May 2014 at 10:33:53 UTC, Andrei Alexandrescu wrote:
> Maybe I misunderstood - I thought the change preserves semantics. -- Andrei

There are two layers to the changes discussed in this thread. The first is to remove __monitor from Object. This is something I think we all agree on.

Now there are two possibilities for what to do when a user tries to synchronize on an instance that does not have a monitor field. One option would be to just fall back on a global lock lookup table of some sorts. This is what Yuriy's proposal does, and indeed preserves language semantics at the expense of a "silent" slowdown in these cases. The other is to outright forbid synchronizing on such objects. This is a small breaking change, but arguably the cleaner solution.

If we didn't have to worry about being backwards compatible, I'd definitely argue for the second solution. Java compatibility is not a very strong argument in my opinion. First, porting a Java application 1:1 is asking for  performance hazards (w.r.t. GC, ...) anyway. Second, the no-synchronized-by-default design allows for clear error messages that immediately suggest the correct fix (add an attribute to the class declaration), and for mechanical porting, Java classes could just be translated to "@synchronizable class" or whatever.

David