remove branch model?

[yilongli]

We are not really using or testing it. And I am not very enthusiastic about maintaining this part of the code in the future. I believe sliced causality is more promising.

What do you think? @grosu @traiansf

[traiansf]

Are you sure sliced causality can be (easily) adapted to the maximal model?
As far as I know, sliced causality assumes a causal model based on an order relation and uses that relation to ease the slicing.
Moreover, implementing sliced causality requires some kind of a branch model be computed anyway through static analysis of the classes being instrumented.

[grosu]

1. I think we should first have a version of the tool without branches and without sliced causality, and hopefully that to be good enough that we can go public with it.

2. Then try to add branches only, like in the PLDI'14 paper, but to also take into account where the branch starts. It is a bit ridiculous to consider that a branch depends on ALL the previous reads in a thread, when in fact it only depends on the reads happening while the condition is evaluated. Once implemented, then evaluate its runtime overhead and overall effectiveness, to see whether it is worth introducing it as an option.

3. Go for sliced causality, which in fact means to start developing our own static analysis infrastructure in RV. Yes, because I think we should use the same in RV-Monitor to reduce the instrumentation overhead, and perhaps in other tools we have, too.

Anyway, for now let's keep the big picture in mind. Which is, we still don't have an RV-Predict product, in spite of pouring $ in it since 2010!

Grigore

---

From: Yilong Li [notifications@github.com]
Sent: Monday, February 23, 2015 10:24 PM
To: runtimeverification/rv-predict
Cc: Rosu, Grigore
Subject: [rv-predict] remove branch model? (#332)

We are not really using or testing it. And I am not very enthusiastic about maintaining this part of the code in the future. I believe sliced causality is more promising.

What do you think? @grosuhttps://github.com/grosu @traiansfhttps://github.com/traiansf

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/332.

[yilongli]

@traiansf No, I am not sure. But the point of this issue is to remove something we are not using or testing and not to implement something new.

@grosu

1. The version without branch and sliced causality is going to be our only tool for a while. And it's definitely going to be good enough for public use.
2. I agree. I think this more efficient implementation of the branch model can replace the above version once we have it.
3. I am neither proposing nor volunteering to work on it anytime soon.

Again, I am simply saying that I don't want to maintain something not used or tested. If both of you are against this then I am fine with keeping it as broken as it is right now.

[traiansf]

I'm OK with removing it for now, to keep code clean. We can resurrect it at anytime if needed later.

[grosu]

No, it is OK with me to remove it and keep the code clean.

[yilongli]

closed via #335