Issue for inconsistent result

[yiming-tang-cs]

If the test case is:

package p;

import java.util.HashSet;
import java.util.stream.*;

import edu.cuny.hunter.streamrefactoring.annotations.*;

class A {

	Stream<Object> m() {
		Stream<Object> stream = new HashSet<>().stream().parallel();
		return stream;
	}

	@EntryPoint
	void n() {
		Stream<Object> s = m();
		s.distinct().count();
	}
}

there are two elements in execution modes:

stream	start pos	length	method	type FQN	execution mode
new HashSet<>().stream()	192	24	m()	p.A	SEQUENTIAL
new HashSet<>().stream()	192	24	m()	p.A	PARALLEL

[yiming-tang-cs]

Related to #103

[khatchad]

Seems related to b8d3815.

[khatchad]

The table is quite helpful but I'm confused as to why this would happen with b8d3815 present. @saledouble Please verify that you have b8d3815 in your fork. In fact, please be even with origin/master and try again

[khatchad]

Hm, I just merged #124 locally and it passed. Investigating ...

[khatchad]

So m() is not supposed to be considered as a stream creation method. Given that testNonInternalAPI3() passes, it must have something to do with the sorted() being called immediately prior to returning the stream.

[khatchad]

After investigating, the typestate analysis is resulting in bottom states for the same stream for which it deemed to be ordered. So, we get two different possible states without any branching, which seems incorrect:

INFO: Factoid: (SITE_IN_NODE{< Primordial, Ljava/util/stream/StreamSupport, stream(Ljava/util/Spliterator;Z)Ljava/util/stream/Stream; >:NEW <Primordial,Ljava/util/stream/ReferencePipeline$Head>@5 in CallStringContext: [ java.util.Collection.stream()Ljava/util/stream/Stream;@7 p.A.m()Ljava/util/stream/Stream;@7 ]},[name: bottom, accepting: false],unique)
INFO: Factoid: (SITE_IN_NODE{< Primordial, Ljava/util/stream/StreamSupport, stream(Ljava/util/Spliterator;Z)Ljava/util/stream/Stream; >:NEW <Primordial,Ljava/util/stream/ReferencePipeline$Head>@5 in CallStringContext: [ java.util.Collection.stream()Ljava/util/stream/Stream;@7 p.A.m()Ljava/util/stream/Stream;@7 ]},[name: ordered, accepting: false],unique)

[khatchad]

Does not seem related to #127. I also tried switching the live analysis SAFE option on with no change in the results.

[khatchad]

At this point, we should probably have a dive into the SAFE code to see why it is assigning both the bottom state and the ordered state to the stream instance in question.

[khatchad]

I'm also wondering if it has something to do with the change for #103. Are we now analyzing blocks that make no sense? It would be good to debug this to find out

[khatchad]

#124 is a pull request. I wouldn't say it's related to a pull request. Let's just relate issues.

…

On Fri, 2017-12-08 at 20:30 +0000, @saledouble wrote: Related to #103<#103> #124<#124>

[khatchad]

Doesn't seem to depend on blocks:

Dec 18, 2017 8:27:23 PM edu.cuny.hunter.streamrefactoring.core.analysis.StreamStateMachine start
INFO: Adding state: [name: bottom, accepting: false] for instance: SITE_IN_NODE{< Primordial, Ljava/util/stream/StreamSupport, stream(Ljava/util/Spliterator;Z)Ljava/util/stream/Stream; >:NEW <Primordial,Ljava/util/stream/ReferencePipeline$Head>@5 in CallStringContext: [ java.util.Collection.stream()Ljava/util/stream/Stream;@7 p.A.m()Ljava/util/stream/Stream;@7 ]} for block: BB[SSA:5..5]3 - p.A.n()V for rule: ordering

Dec 18, 2017 8:27:23 PM edu.cuny.hunter.streamrefactoring.core.analysis.StreamStateMachine start
INFO: Adding state: [name: ordered, accepting: false] for instance: SITE_IN_NODE{< Primordial, Ljava/util/stream/StreamSupport, stream(Ljava/util/Spliterator;Z)Ljava/util/stream/Stream; >:NEW <Primordial,Ljava/util/stream/ReferencePipeline$Head>@5 in CallStringContext: [ java.util.Collection.stream()Ljava/util/stream/Stream;@7 p.A.m()Ljava/util/stream/Stream;@7 ]} for block: BB[SSA:5..5]3 - p.A.n()V for rule: ordering

[khatchad]

Here's the IR:

Dec 18, 2017 8:01:58 PM edu.cuny.hunter.streamrefactoring.core.analysis.StreamStateMachine start
INFO: IR is: < Application, Lp/A, n()V >
CFG:
BB0[-1..-2]
    -> BB1
BB1[0..1]
    -> BB2
    -> BB5
BB2[2..4]
    -> BB3
    -> BB5
BB3[5..5]
    -> BB4
    -> BB5
BB4[6..7]
    -> BB5
BB5[-1..-2]
Instructions:
BB0
BB1
1   v4 = invokevirtual < Application, Lp/A, m()Ljava/util/stream/Stream; > v1 @1 exception:v3(line 17)
BB2
4   v6 = invokeinterface < Application, Ljava/util/stream/Stream, distinct()Ljava/util/stream/Stream; > v4 @6 exception:v5(line 18)
BB3
5   v8 = invokeinterface < Application, Ljava/util/stream/Stream, count()J > v6 @11 exception:v7(line 18)
BB4
7   return                                   (line 19)
BB5

[khatchad]

No clue.

[khatchad]

Maybe we should just fall back to ordered.

[khatchad]

It is almost like it's treating the return value from the client method as a new instance ...

[khatchad]

It has something to do with the terminal operation, i.e., where it is called. It seems to work fine when the terminal operation is called in the same method as the transitioning method. The terminal operation corresponds to the block where we extract the typestate information (i.e., it is the state of the object at that block).

[khatchad]

I am trying out different solvers but they are taking way too long. We may have to wait for the performance improvements in #103.