• Pavel (15/15) Nov 07 2013 Hello!
• bearophile (7/13) Nov 07 2013 Out there there is surely some D code that lacks your annotations
• Pavel (8/22) Nov 07 2013 For example, new annotation can be introduced in next version of
• Dmitry Olshansky (9/22) Nov 07 2013 Technically there is no need to synchronize on non-shared classes at
• Pavel (10/10) Nov 07 2013 I just want to say that mixing synchronization functionality

"Pavel" <phondogo gmail.com> writes:

Hello!

For every object of class there is two pointers (for vtable and 
monitor).
I wonder why there is a need to have sync functionality in object 
(1 pointer memory waste).
There is also such overhead in Java and during my work with it I 
use synchronized section only for about 0.01% of all objects in 
program (may be even less). So 99.99% of objects just waste 
memory for that monitor pointer.

Why don't to introduce some annotation (property) for class 
needed to be synchronized or it descendants, according to it 
compiler will extend the size of class by the size of monitor 
structure (+1 allocation less).
Synchronization will be allowed when class or supers is annotated 
with this property (it can be checked by compiler).

"bearophile" <bearophileHUGS lycos.com> writes:

Pavel:

 Why don't to introduce some annotation (property) for class 
 needed to be synchronized or it descendants, according to it 
 compiler will extend the size of class by the size of monitor 
 structure (+1 allocation less).
 Synchronization will be allowed when class or supers is 
 annotated with this property (it can be checked by compiler).

Out there there is surely some D code that lacks your annotations 
and relies on the presence of the monitor pointer in some class 
instances. I think your change is going to break that code. So 
what deprecation/update path do you suggest to use?

Bye,
bearophile

"Pavel" <phondogo gmail.com> writes:

On Thursday, 7 November 2013 at 11:04:05 UTC, bearophile wrote:
 Pavel:

 Why don't to introduce some annotation (property) for class 
 needed to be synchronized or it descendants, according to it 
 compiler will extend the size of class by the size of monitor 
 structure (+1 allocation less).
 Synchronization will be allowed when class or supers is 
 annotated with this property (it can be checked by compiler).

 Out there there is surely some D code that lacks your 
 annotations and relies on the presence of the monitor pointer 
 in some class instances. I think your change is going to break 
 that code. So what deprecation/update path do you suggest to 
 use?

 Bye,
 bearophile

For example, new annotation can be introduced in next version of 
compiler, but the functionality will stay the same. So in case of 
compiler meet synchronized section on object of class not 
annotated with it then deprecation warning with message "class 
<some class> should be annotated with <annotation> to be used in 
synchronized expression".
After that (several next versions) make it error.

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

07-Nov-2013 14:35, Pavel пишет:
 Hello!

 For every object of class there is two pointers (for vtable and monitor).
 I wonder why there is a need to have sync functionality in object (1
 pointer memory waste).
 There is also such overhead in Java and during my work with it I use
 synchronized section only for about 0.01% of all objects in program (may
 be even less). So 99.99% of objects just waste memory for that monitor
 pointer.

Agreed and I raised this point before.

 Why don't to introduce some annotation (property) for class needed to be
 synchronized or it descendants, according to it compiler will extend the
 size of class by the size of monitor structure (+1 allocation less).
 Synchronization will be allowed when class or supers is annotated with
 this property (it can be checked by compiler).

Technically there is no need to synchronize on non-shared classes at 
all. However the type-system is often violated and most code out there 
that uses synchronized on class instance undoubtedly violates it.

I'd say optimally shared(Class) should have monitor field, others don't. 
This would mean that cast to shared must not work on class references.

-- 
Dmitry Olshansky

"Pavel" <phondogo gmail.com> writes:

   I just want to say that mixing synchronization functionality 
with object concept is not good idea from conceptual and 
optimization points of view.
   If thinking like this, for example, we can add one more pointer 
to Object for GUI element (may be some of objects need to be 
associated with it) :) .
   I think it will be better that synchronized section must be 
used only with monitor object directly or with object annotated 
with sync property (or to be shared like Dmitry Olshansky 
suggested).