Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spine's batch dropping seems erroneous. #230

Closed
frankmcsherry opened this issue Nov 19, 2019 · 1 comment

Comments

@frankmcsherry
Copy link
Member

@frankmcsherry frankmcsherry commented Nov 19, 2019

Spines drop batches when their advance_frontier reaches the empty set. This has a few flaws, however:

  1. The batch bounds are used by read_upper() to indicate how far along the trace has progressed. In principle one can announce that they don't care about times, but still read from read_upper() for some reason.
  2. Once batches are dropped, new batches can still land in the trace. The frontier will not advance again, and so these batches will probably just be held until the trace is eventually dropped.

I'm not aware of settings in which a trace has its frontier advanced to the empty frontier, but is not itself dropped. We could plausibly just remove the eager dropping of batches, and try and reconstruct which mode of execution holds on to more memory than it is supposed to, and track down whichever villains are holding on to traces the cannot read out of.

@frankmcsherry frankmcsherry changed the title Spines batch dropping seems erroneous. Spine's batch dropping seems erroneous. Nov 19, 2019
@frankmcsherry

This comment has been minimized.

Copy link
Member Author

@frankmcsherry frankmcsherry commented Dec 3, 2019

Fixed with #231

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.