A Concurrent Affair

Right now I’m actually doubting that data annotations are necessary. It seems like assertions can do enough already. For method annotations, the important distinction was that the invariants in the annotations get inherited into subclasses.

The original idea of data annotations was that invariants would be checked every time an object is accessed. However, if I implement the scopes as discussed in the last post, then what’s the difference to assertions? You could simply place several assert statements in the code. Maybe the annotations would look cleaner, less littered, but is that really a justification for developing data annotations?

Originally, what intrigued me was calling a predicate method every time an object is accessed. In that predicate method, I could do whatever I wanted to do: This even includes implementing a lock-set algorithm and performing dynamic race condition detection.

But the scoping destroys that possibility, because the invariants would not be checked everywhere. So I think the scope idea is not the right way to go. Too bad, I already wrote a generified RangeMap that I would have used to store invariants that are active in a range of PC (program counter) values…

Maybe the right way to think about data annotations is that you specify the invariant at the time the object is created. Or maybe it’s class-based and you specify the properties inside the class, and then it applies to every instance. Maybe there are multiple places where you can specify invariants, e.g. when you define a field and when you define a parameter. But what invariants are checked when that field is passed as argument for that annotated parameter? Now the limited scope makes sense again. Or is everything merged?

I’ll have to think about this some more…

Update

Maybe it makes sense to have both scoped and unlimited invariants. The scoped invariants would pretty much replace assert statements littered in one particular area, while the unlimited invariants would follow an object throughout its entire lifetime.

One thing I’ve definitely realized is that the kind of opcode that is about to be executed should be transferred to the predicate method. That way, a predicate method could tell that it’s just before a monitorenter, for example.

I’ve thought a bit about what the scope of data predicate annotations should be. At first, I thought every time an object encounters another predicate annotation, that predicate just gets added to the list of predicates that an object has to fulfill. I’m not so sure about that anymore. In fact, I don’t think this is right.

Consider the following class:

public class Test {
private static Integer _field;
public static void increment(@NeverPositive Integer param) {
++_field;
}
public static void decrement(@NeverNegative Integer param) {
_field = _field -1;
}
public static void main(String[] args) {
_field = -10;
while(_field<=0) increment(_field); _field += 9; while(_field>=0) decrement(_field);
}
}

It’s a pointless example. Here, I annotate the parameters of two methods: For increment, the parameter may never be positive. For decrement, the parameter may never be negative. In the main method, I start with -10 for the field’s value, then keep calling increment until the field is positive.

Then the program enters a second phase. I add 9 to the field, so the value of the field now is 10. I keep calling decrement until the field’s value has reached -1.

If an object keeps accumulating the predicates it encounters, then in the decrement phase, the field would have both the @NeverPositive and the @NeverNegative predicates, and it would only accept 0.

This leads me to believe that the predicates must be scoped. The scope of the parameter annotations here, for example, should be only the method. For local variable (if they worked), it should probably be the smallest enclosing block.

What about fields? Should the predicates only apply if the data is used in this class? Or should it span to other classes as well? I’m not sure. By the way, to make things clear, the idea is that the predicates will be checked every time the object is accessed, so in the bytecode, before the access, bytecode will be inserted.

If I take the example with the parameter annotations that should probably be limited to just the methods and expand it to fields and classes, then I think limiting the predicates to just the class seems right.

I have thought a little about how to do predicate annotations on data. Of course there’s the local variable problem, but let’s ignore that for now.

Originally, I thought it would be rather easy: Whenever a field or parameter is declared, I run a check method every time it is accessed. This, of course, is wrong because the predicates should not be based on the declaration site but rather on the object that is created.

So I need to add fields to java.lang.Object that get filled in when the object is created to store the predicate class and method name. Of course, as we all know, you can’t add fields to Object, so I do what I have done for the object ID and add a method to Object that calls the real check method in edu.rice.cs.cunit.threadCheck.ThreadCheck, which then looks up the predicates in a hash table.

What I haven’t figured out is how I get the parameters from the annotations into the check method.

Ok, so it seems like I’m approaching the stage where I have to send out copies of my draft to my very friendly committee members. A lot of things are there, though I admit I have not checked for spelling mistakes, bad wording or layout problems. I just focused on getting content down.

Tomorrow, I think, I’ll provide the committee members a duplex printout of the current version and ask them to scribble any notes they have on the paper, or point out my mistakes in any way they feel comfortable. I’ll also ask a few of my friends to proof-read. While all of that is going on, I’ll flip through my blog to see if I have forgotten anything that is really crucial.

Well, and then, once the feedback from the committee members is in, I have to schedule a defense date. Do I want to defend before my mom gets here for her summer vacation, or do I let her be part of my audience? Of course I’d want her to be there, the problem is just that I have so many serious things going on in my family, I don’t want to be disturbed until this thing is done. And I also don’t want to make it seem like I’m using my mom to get my committee off my back. Anyway, I think now people (including me) have some reading ahead, and then I’ll either make improvements and get back to them, or we schedule a defense. Then I get to make a PowerPoint presentation about all of this. Yay.

So far, writing has been an interesting experience: Without a doubt, I can say that I’ve never written anything at this length. I’ve never got involved with anything this in-depth. However, sometimes I got bored writing about something that I had already done half a year ago and that worked. It felt like “I want to do something new!”

Now, when the MS defense is coming closer, though, I realize that after the MS are a lot more challenges for me. I need to pass the candidacy exam, and I need to finally get that replay algorithm to work, something I botched up but half a dozen other groups got working. I just hope that I have learned enough to get my second attempt to work.

One thing that I definitely have to mention is an advantage over the current, classical solution: assertions. Assertions aren’t inherited like my annotations.

I have now implemented @SuppressSubtypingWarning as far as I am going to, I think. I limited it only to methods and constructors; it can’t be applied to classes or interfaces. I think the impact would have been to unspecific.

There are several ways a method can acquire an annotation:

• A method is annotated itself.
• The same method in a superclass is annotated.
• A class is annotated and the method is first defined in that class or a subclass.

More formally:

Let be an annotation.
Let be a method.
Let , , , be classes.
Let be the set of methods defined (i.e. introduced or overridden) in class .
Let be the set of annotations that are directly attached to class , i.e. that appear in front of ’s class definition.
Let be the set of annotations that are directly attached to method in class , i.e. that appear in front of ’s method definition in the class definition of .
Finallly, let be the set of annotations that are applied to a method in class , either because the method was directly annotated or because the annotations were somehow inherited.

A method in class has an annotation if one of the following statements is true: .

The definition of is:

The first subset corresponds to a method being directly annotated. The second subset comes into effect if a method in a superclass was annotated. Because of the reflexive property of subtyping , this statement actually subsumes the first rule. The third subset contains the annotations that meet the following three criteria: The method exists in the class or a superclass, the class is annotated with the annotation, and the method had not already been introduced in a class higher up. I defined the semantics of @SuppressSubtypingWarning to act only on the specific method that is annotated with it. If it acquires an annotation in any of the three ways above, but the same method in a superclass does not have the annotation, then the subtyping warning that would normally be generated is suppressed. The @SuppressSubtypingWarning does not have any effect on subtyping warnings that methods in superclasses may generate because they may have annotations that super-superclasses lack.

I also decided to not allow annotations of whole classes because the annotation of a class has effects reaching beyond that class itself: It also affects subclasses. If a class is annotated and a subclass introduces a method, then that method will carry the annotation. Therefore, annotating a class with @SuppressSubtypingWarning would suppress annotations for all methods introduced further down in the hierarchy.

I’m really having problems sleeping lately, so tonight I’ve been doing some thinking about @SuppressSubtypingWarning. At first, I thought I’d just bake it into the PredicateLink and Combine meta-annotations, but then it would mean that an annotation will always suppress subtyping warnings, and I don’t think that’s desired.

So the @SuppressSubtypingWarning annotation has to be a meta-annotation that gets applied to an annotation at the usage site. For example:

@SuppressSubtypingWarning @OnlyEventThread.AfterRealized
private void handleButton() {
System.out.println("Button was pushed");
final Thread ct = Thread.currentThread();
System.out.println("thread name = '" + ct.getName() + "'");
System.out.println("thread id = " + ct.getId());
System.out.println("thread grp = '" + ct.getThreadGroup().getName() + "'");
}


Unfortunately, Java’s grammar doesn’t let you apply annotations to the usage sites of other annotations, only to their definitions. So this approach isn’t going to work.

I could use a @SuppressSubtypingWarning annotation applied to a class or method to completely disable subtyping warnings for all annotations on that class or method, but I’d rather have it fine-grained. I’ll have to think some more about it.