Hello, I've played a bit with monitors, trying to make them optional, and here's what i've come up with:
https://github.com/yglukhov/dmd/tree/optional_monitor
https://github.com/yglukhov/druntime/tree/optional_monitors

The whole idea is that Object doesn't contain __monitor field anymore.
TypeInfo_Class will hold a monitor offset, if a class defines one (like void* __monitor), or -1.
Monitor lookup is done with a hash map, if monitorOffset is -1.
The hash map is protected by a primitive RW spin lock.
The only downside i see here is that finalization of every object will now lookup for a corresponding monitor, if it's class doesn't define embedded one.
Tested on Mac, but i think it should work anywhere.

Your feedback is very appreciated. Thanx.

13-May-2014 19:46, Yuriy пишет:
> Hello, I've played a bit with monitors, trying to make them optional,
> and here's what i've come up with:
> https://github.com/yglukhov/dmd/tree/optional_monitor
> https://github.com/yglukhov/druntime/tree/optional_monitors
>
> The whole idea is that Object doesn't contain __monitor field anymore.
> TypeInfo_Class will hold a monitor offset, if a class defines one (like
> void* __monitor), or -1.
> Monitor lookup is done with a hash map, if monitorOffset is -1.
> The hash map is protected by a primitive RW spin lock.
> The only downside i see here is that finalization of every object will
> now lookup for a corresponding monitor, if it's class doesn't define
> embedded one.
> Tested on Mac, but i think it should work anywhere.
>
> Your feedback is very appreciated. Thanx.

Sounds cool, as I always was in favor of pay as you go principle.
Especially with thread-local as default, allocating monitor slot is dubious.


-- 
Dmitry Olshansky

On 5/13/14, 8:46 AM, Yuriy wrote:
> Hello, I've played a bit with monitors, trying to make them optional,
> and here's what i've come up with:
> https://github.com/yglukhov/dmd/tree/optional_monitor
> https://github.com/yglukhov/druntime/tree/optional_monitors
>
> The whole idea is that Object doesn't contain __monitor field anymore.
> TypeInfo_Class will hold a monitor offset, if a class defines one (like
> void* __monitor), or -1.
> Monitor lookup is done with a hash map, if monitorOffset is -1.
> The hash map is protected by a primitive RW spin lock.
> The only downside i see here is that finalization of every object will
> now lookup for a corresponding monitor, if it's class doesn't define
> embedded one.
> Tested on Mac, but i think it should work anywhere.
>
> Your feedback is very appreciated. Thanx.

I think that's a great idea. Please follow through with it! -- Andrei

> The only downside i see here is that finalization of every object will now lookup for a corresponding monitor, if it's class doesn't define embedded one.

Ok, i think i've found a simple yet effective solution.
Adding a flag to ClassFlags: hasAllocatedMonitors.
Mark m_flags with this flag in runtime, when monitor is allocated.
When finalizing, check this flag to know if we need to lookup the monitors.

This way the only types that suffer would be those who don't define embedded __monitor, but still use synchronized() over them.

Would that be an ultimate win-win solution?

> Ok, i think i've found a simple yet effective solution.
Implemented and pushed to the repo. Any more thoughts before a PR?

Yuriy:

> Your feedback is very appreciated. Thanx.

What's the syntax to define a class without its __monitor? Are you using an annotation like @no_monitor?

Bye,
bearophile

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.
    }

    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.
    }
}

So the semantics remains the same, you just may want to define a __monitor field if you want better performance.

Yuriy:

> No syntax for that. The __monitor is not present by default anywhere. If you need it, you need to define one.

> class B
> {
>     void* __monitor;

What kind of clear error messages do you receive if you write:

class B {
    void* _monitor;

Or:

class B {
    size_t __monitor;


This isn't C++, in D land we prefer features to be safe and clean, the D compiler is designed to have clean syntax, to give nice errors, and remove the probability of invisible mistakes as much as possible. An annotation like @no_monitor (or its opposite @monitor if we don't want __monitor on default) seems the safe and clean way to ask for this in D.

Bye,
bearophile

bearophile, good point. What do you think of the following solution:
1. Declaring member variable with __monitor identifier is disallowed.
2. class may be defined with @__monitor attribute, in which case a __monitor variable will be added to it's beginning.
3. Subclass of such class may again be defined with @__monitor attar, in which case it will be simply ignored, as it already inherits __monitor from super.

Yuriy:

> 2. class may be defined with @__monitor attribute, in which case a __monitor variable will be added to it's beginning.

I suggest a name like "@monitor". The is no need for the underscores.


> 3. Subclass of such class may again be defined with @__monitor attar, in which case it will be simply ignored, as it already inherits __monitor from super.

A more tidy design could require the @monitor in all classes that inherit from a @monitor-annotated class. But this also looks a little overkill. So let's hear what other people think about this.

Bye,
bearophile