Statics issues

[Ali Ebrahimi]

I think static synchronized methods issue can (should) be solved by
generating specialized versions for generic methods in host class.
We have
ValhallaTest.count${0=I}(Ljava/lang/Object;)V

What do you think?


On Sat, Dec 20, 2014 at 3:04 PM, Peter Levart <peter.levart at gmail.com>
wrote:

> Hi,
>
> I joined the list yesterday and read the thread about static fields and
> initialization. I have a feeling the one-static-variable-per-source-definition
> is the desired direction. Especially when the number of specialized classes
> is an implementation detail. With one variable per class you would get
> separate variables per each primitive specialization combination, but
> reference type variables do not get specialized classes, which would be
> confusing.
>
> If static variables are a special case then this should be consistently
> applied to other areas:
>
> public class ValhallaTest {
>
>     static int counter;
>
>     static synchronized <any T> void count(T arg) {
>         if (!Thread.holdsLock(ValhallaTest.class)) {
>             throw new IllegalStateException("Not synchronized on
> ValhallaTest.class");
>         }
>         counter++;
>         System.out.println("Counting " + counter);
>     }
>
>     public static void main(String[] args) {
>         count("A");
>         count(BigDecimal.ONE);
>         count(1);
>
>         System.out.println(counter);
>     }
> }
>
>
> This prints:
>
> Counting 1
> Counting 2
> Specializing method ValhallaTest$count${0=I}.count(Ljava/lang/Object;)V
> with class=[] and method=[I]
> Exception in thread "main" java.lang.IllegalStateException: Not
> synchronized on ValhallaTest.class
>         at ValhallaTest$count${0=I}/1096979270.count(ValhallaTest.java:12)
>         at ValhallaTest.main(ValhallaTest.java:21)
>
>
> The specializer should also rewrite specialized synchronized static
> methods so they synchronize on the "host" class object.
>
> More "hiding" of specialized classes might be necessary. What would happen
> with the following code:
>
> <any T> void m(T arg) {
>     synchronized(getClass()) {
>     }
> }
>
> This could be "fixed" by not allowing things like Foo<int>.class and
> making Object.getClass() always return the "host" class regardless of
> implementation class. But that means something like:
>
>     this.getClass().cast(this)
>
> ...could throw ClassCastException then...
>
> This could be "fixed" by getClass() returning a special interface class
> object that is implemented by "host" class AND all specialized classes.
>
> Reflection issues left behind for now.
>
> I have doubts about "fixing" Object.getClass(), but for static
> synchronized methods I think they should be fixed.
>
> Regards, Peter
>
>