Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Partial History Tree (Index out of bounds error)
Hello Michel,

Thanks a lot for those detailed explanations!

Based on the algorithm you proposed, some changes seem to be required for the doQuery() too. I was trying to find a way to get the right end time for the intervals between the checkpoints, your proposition may help with that.

I have a question on how to add the intervals between the checkpoints to the query2D() output after reading them from the trace? This is what I'm doing, actually (the same thing is done  in the doQuery):

getting the interval start time from the ongoing state for the needed quark:
startTime = ((ITmfStateSystem) fPartialSS).getOngoingStartTime(quark);

getting the value of the interval:
val = ((ITmfStateSystem) fPartialSS).queryOngoing(i);

But now, which end time should I use to finish filling all the fields of the interval that I should return in the query2D() output "intervals"?
endTime = .....?

Interval = new TmfStateInterval(startTime, endTime, quark, val);
intervals.add(interval); // intervals is the list of the intervals we should return in the query2D() output.

We can't even use dummy end time since here we have a time range [t1,t2] and not a punctual timestamp t. The only method that I've found is  ((ITmfStateSystem) fPartialSS).getCurrentEndTime();  but this one returns the endTime of the history and not the endTime of a specific interval. Do you have any idea about this? Is there a better way of getting the intervals for the desired range time?

Thanks,

Abdellah





Le ven. 25 févr. 2022 à 10:51, Michel Dagenais via tracecompass-dev <tracecompass-dev@xxxxxxxxxxx> a écrit :
I looked more closely at the query methods in the public interface IStateHistoryBackend. Your stated goal is to implement this interface based on a partial state history backend, starting from an old prototype version that was written before the query2d method was added.

To obtain the desired query results from the partial history, some processing is required. Basically, all the intervals that entirely reside between two checkpoints are missing from the partial history. This is very significant for attributes that change state very frequently, and in those cases can save a lot of space for the (partial) state history files. A good example is the attribute that stores the number of events so far in the trace. This attribute changes value for each event read from the trace, and therefore adds one interval to the state history for each event in the trace. With a partial state history, you only store the fact that we are at say 234 100 000 events at one checkpoint, and 234 200 000 at the next (one new interval instead of 100000). If we want to show an histogram of the number of events in the trace, at a granularity close to the checkpoint granularity, this can be very efficient.

With this in mind, let's try to see how we can get the correct query answer, using the partial state history, and re-reading the trace to recreate the missing intervals. I am sort of thinking aloud here. Feel free to comment and correct... The query methods are the following.

void doQuery(@NonNull List<@Nullable ITmfStateInterval> currentStateInfo, long t)
            throws TimeRangeException, StateSystemDisposedException;

To answer that query from a partial state (where the state history is only complete at checkpoints), you seek to the closest preceeding checkpoint from time t and then read the trace updating the current state. When reaching time t, while reading the trace and updating the current state, the desired query result (state values at time t) is available in the current state structure. The difference with a query from the regular state history, though, is that the end time is not known for the new intervals added since the checkpoint. The querying client may or not care about those end times, and you can try putting a bogus value (e.g. t) as end time for those intervals. My understanding is that this is what the code that you have shown does.

If you wanted to have the correct end times, you could do something like the following.

- query the partial history at the checkpoint preceeding t.
- read the trace updating the current state until reaching t.
- continue reading the trace until reaching the checkpoint succeeding t. When a state changes, the closing interval is added to the query output if it intersects t. When reaching the checkpoint succeeding t, we have added to the query output all the intervals that intersect t and end between t and the succeeding checkpoint.
- clear the current state and query the partial history at the checkpoint succeeding t. Add to the query output any interval in the current state that intersects t. This will add to the query output all the intervals that intersect t and end after the succeeding checkpoint. Obviously, no interval ending before the preceeding checkpoint can intersect t. We should thus have this way a query result that contains all the needed intervals, complete with their end time.

ITmfStateInterval doSingularQuery(long t, int attributeQuark)
            throws TimeRangeException, StateSystemDisposedException;

This query can rely on the previous one, as stated in the comments in file IStateHistoryBackend.java

default Iterable<@NonNull ITmfStateInterval> query2D(IntegerRangeCondition quarkCondition, TimeRangeCondition timeCondition)

This is the more complex query method which was not there when the initial experiments on partial history were conducted by Alexandre Montplaisir. Fortunately, this method does not impose any constraint on the results ordering. We can thus generate the interval results as they are found, with whatever algorithm is used. The same general algorithm as above may be used, but with conditions on the attributes searched, and a time interval instead of a time point. Let t1 and t2 be the lower and upper bounds of the searched interval, and ckpt1 the preceeding checkpoint to t1 and ckpt2 the succeeding checkpoint to t2.

- query the partial history at ckpt1.
- read the trace updating the current state until reaching t1.
- continue reading the trace until reaching ckpt2. When a state changes, the closing interval is added to the query output if it intersects [t1,t2] and satisfies the quark condition. When reaching ckpt2, we have added to the query output all the matching intervals that intersect [t1,t2] and end between t1 and ckpt2.
- clear the current state and query the partial history at ckpt2. Add to the query output any interval in the current state that intersects [t1,t2] and satisfies the quark condition. This will add to the query output all the intervals that intersect [t1,t2] and end after ckpt2. Obviously, no interval ending before the t1 can intersect [t1,t2]. We should thus have this way a query result that contains all the needed intervals, complete with their end time.

----- Le 24 Fév 22, à 11:40, rahmani abdellah <rahmaniabdellah1994@xxxxxxxxx> a écrit :
Hi Ivan,

Thanks for your answer!

Indeed, the transient state was empty, I missed updating the partial state with the current state information before requesting the attributes.
I didn't yet have the result I'm working for on the views but at least, this resolved the issue that I've mentioned in my previous email.

Best regards,
Abdellah Rahmani
Research associate
Dorsal Laboratory

Le mer. 23 févr. 2022 à 05:22, Grinenko, Ivan <ivan.grinenko@xxxxxxxxxx> a écrit :

Hi Abdellah,

 

At first glance it looks like TransientState is empty by the time you try to do the query. Since, ITmfStateSystem#getOngoingStartTime(int) gets info from TransientState by default I think you need to override StateSystem#getOngoingStartTime(int) or fill TransientState before you try to query2D.

 

--

Best regards,

Ivan Grinenko

Software Engineer

Auriga

 

 

From: tracecompass-dev <tracecompass-dev-bounces@xxxxxxxxxxx> On Behalf Of rahmani abdellah
 Sent: Wednesday, February 23, 2022 4:54 AM
 To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
 Subject: [tracecompass-dev] Partial History Tree (Index out of bounds error)

 

Hi,

 

I'm actually working on the partial state system, I'm overriding the query2D() in order to be able to populate the views like the Control Flow view with the states.

 

With the actual code that I'm attaching to this email, if we comment out the lines 342 to 343, we will be able to see the states that we saved at the checkpoints when we open the control flow view or resources view.  My objective is to complete the view with the missing states by reading the trace and building the intervals from there without saving them to the state system, but actually, I'm having this error saying "Index 32 out of bounds for length 0" when I try to open the control flow view. It seems that the quark that I'm requesting at line 342 does not exist.

Can you please tell me what is missing or what I'm doing wrong in this code?

 

Thanks!

 

Best regards,

Abdellah Rahmani

Research associate

Dorsal Laboratory

 

 

 

 

_______________________________________________
tracecompass-dev mailing list
 tracecompass-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tracecompass-dev

_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
 tracecompass-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tracecompass-dev

Back to the top