QHelp previews:

public class UnsafePublication {
    private Object value;
    private int server_id;

    public UnsafePublication() {
        value = new Object(); // Not safely published, other threads may see the default value null
        server_id = 1; // Not safely published, other threads may see the default value 0
    }

    public Object getValue() {
        return value;
    }

    public int getServerId() {
        return server_id;
    }
}

public class SafePublication {
    private volatile Object value;
    private final int server_id;

    public SafePublication() {
        value = new Object(); // Safely published as volatile
        server_id = 1; // Safely published as final
    }

    public synchronized Object getValue() {
        return value;
    }

    public int getServerId() {
        return server_id;
    }
}

Commented offline.

Notes from offline review:

• Everything private
• Better lock detection, look at unreleased lock query
• Monitor abstract toString
• Remove char preds and fields from wrapped IPA types
• Revert to NodeToBeDominated
• locallySynchronizedOn not field?
  No, see example on page 550 of https://docs.oracle.com/javase/specs/jls/se25/jls25.pdf
• Prefix should be calculated via matches or as output + _
• getErasure -> getSourceDeclaration (needs to be on the field instead of the type)
• getTypeDescriptor -> getPackage.getName (needs to be on the field instead of the type)
• java.util , Collections, sync_name + sync_name.matches(“synchronized%”)
• Define ExposedField
  - [ ] Hoist lookups out of negations, using exists
• Pragma[inline] -> pragma[inline_late] + bindingset
• AnnotatedAsThreadSafe, inline char pred
• Create extension point
  - [ ] If a then b else any is often better than a implies b
• Safe publication example is wrong.
• Reformulate unsynchronized to find escaping paths from an exposed field access out to public methods.
  Is this not what providesAccess and "the call graph induced by a" do?
  Sure, but the reformulation is more about avoiding binary predicates and recursion through forall.
• Split into self_conflicting and inconsistently locked
  • A publicly accessible write that is not locked is self-conflicting and can be reported right away.
  • A publicly accessible read that is not locked is conflicting with any publicly accessible write.
    This can be reported right away, if the definition of exposed field includes that there is a publicly accessible write.
  • All other cases involve two different locks.

Code change looks good. If you haven't already, then it's probably good to triage a few results from a MRVA run to check that the latest version still looks good. Also, some basic performance checking is in order - let's do a dca run, but remember that it can be limited to these 3 queries to make it smaller/faster.

Not sure if the failing test is simply unrelated?

Not sure if the failing test is simply unrelated?

I think it's unrelated. I just tried to rerun, so let's see if that helps.

Triage of new results:

java/unreleased-lock, 21 new results
These are all due to lockInterruptibly now being correctly recognized as a locking call. This should in itself not introduce problems as the predicate failedLock handles InterruptedException.

• several FPs in apache/geode: The code is very complex, but ultimately a function wraps a locking call and therefor does not release the lock. The query correctly detects that, but it is probably intended by the developer.
• an FP in geode due to a ReadWriteLock (link). The reader is taken under certain conditions and the write under others. They are later released under the same conditions. A split control flow graph might have prevented this FP.
• some FPs in hadoop where locking is wrapped in methods.
• two FPs in google/guava due to locking being wrapped in methods.

java/safe-publication, 9 results
The FP rate for this has been scrutinized already, but with only 9 results I went throuhg them anyway.

• 3 TPs in apache/flink, repeated in the buildless version
• 2 TPs in gradle
• 1 FP in gradle due to the unsafely published value being unreadable (it is an internal factory, I think it could probably be static).

java/not-threadsafe, 75 results
The FP rate for this has already been established to be good, but I went through a flock for each repo as a sanity check

• several TPs in apache/flink SystemResourcesCounter.java (no locking at all in that file), repeated in buildless
• several TPs in gradle, little locking used

I will do an extra DCA run on nightly for timing, since I changed the code, but otherwise I am ready to merge this :-)

Timing has actually improved with the code change: palatable/lambda is now slightly slower, but apache/commons now sees no slow-down. So the project with the very many prefixes is the only one where running the new queries is even visible.