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

Make m_mempool optional in CChainState #22415

Merged
merged 4 commits into from
Jul 15, 2021

Conversation

jamesob
Copy link
Contributor

@jamesob jamesob commented Jul 7, 2021

Make CChainState::m_mempool optional by making it a pointer instead of a reference. This will allow a simplification to assumeutxo semantics (see #15606 (review)) and help facilitate the -nomempool option.

@jamesob jamesob force-pushed the 2021-07-mempool-ptr branch 2 times, most recently from 518531e to 349ab28 Compare July 7, 2021 20:32
Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/validation.h Outdated Show resolved Hide resolved
@ryanofsky
Copy link
Contributor

Concept ACK. I think you can drop the second commit and add a LOCK_RETURNED helper method to be able to keep using lock annotations when m_mempool is null:

RecursiveMutex* MempoolMutex() const LOCK_RETURNED(m_mempool->cs) { return m_mempool ? &m_mempool->cs : nullptr; }

Seems to work for me in commit 8db5953

@DrahtBot
Copy link
Contributor

DrahtBot commented Jul 8, 2021

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@jamesob
Copy link
Contributor Author

jamesob commented Jul 8, 2021

Rebased to remove the second commit per Russ' suggestion, which also addresses most of Marco's feedback.

Seems to work for me in commit 8db5953

Wow, that was wizardly. Thanks @ryanofsky!

I think std::variant can do this

I'll look into this tomorrow.

src/validation.h Outdated Show resolved Hide resolved
@naumenkogs
Copy link
Member

Light code review ACK b17bb4c

Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice solution with the LOCK_RETURNED

src/validation.h Outdated Show resolved Hide resolved
@jonatack
Copy link
Member

jonatack commented Jul 8, 2021

Concept ACK, will review on next push.

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK b17bb4c

src/init.cpp Outdated Show resolved Hide resolved
@@ -2254,7 +2257,7 @@ static void UpdateTip(CTxMemPool& mempool, const CBlockIndex* pindexNew, const C
bool CChainState::DisconnectTip(BlockValidationState& state, DisconnectedBlockTransactions* disconnectpool)
{
AssertLockHeld(cs_main);
AssertLockHeld(m_mempool.cs);
if (m_mempool) AssertLockHeld(m_mempool->cs);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In commit "validation: make CChainState::m_mempool optional" (b17bb4c)

Note: It could be nice to be able to write AssertLockHeld(MempoolMutex() for consistency with LOCK(MempoolMutex()) and to avoid the if statement. But it'd be beyond scope of this PR since it'd require changing AssertLockHeld and there are other issues with that function anyway.

@@ -4763,7 +4772,7 @@ bool ChainstateManager::ActivateSnapshot(
}

auto snapshot_chainstate = WITH_LOCK(::cs_main, return std::make_unique<CChainState>(
this->ActiveChainstate().m_mempool, m_blockman, base_blockhash));
nullptr, m_blockman, base_blockhash));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In commit "validation: make CChainState::m_mempool optional" (b17bb4c)

Note: Naively I'd expect the mempool pointer for the activated snapshot to be non-null, but I guess it could be set later when the snapshot is fully initialized.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also surprised by this. Is the snapshot chainstate the one that eventually becomes our tip? In that case, don't we want it to have a mempool?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is a little confusing absent context, but basically the idea per @ryanofsky's feedback is that mempool presence should be used to indicate chainstate activeness, so we don't want to give the snapshot chainstate a mempool until we consider it active.

@jamesob jamesob force-pushed the 2021-07-mempool-ptr branch from b17bb4c to 8511429 Compare July 8, 2021 16:12
@jamesob
Copy link
Contributor Author

jamesob commented Jul 8, 2021

Rebased.

Note: Naively I'd expect the mempool pointer for the activated snapshot to be non-null, but I guess it could be set later when the snapshot is fully initialized.

This is a good point. I'd come up with a commit that implements the std::variant feedback (and am glad to have for learning about that), but @ryanofsky's point here makes that change inappropriate: with assumeutxo, we may actually want the snapshot chain to have a non-null mempool if we're in, say, init.cpp and loading a snapshot chainstate that is active but not yet at tip.

I've covered all of the other feedback aside from the lock assertion for the reasons Russ mentioned; maybe we can get around to it later.

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK 8511429. Just some minor tweaks since last review: whitespace, unique_ptr assert, null mempool args

Copy link
Member

@jonatack jonatack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 8511429 code review, debug build, running bitcoind on signet as a sanity check, operation nominal

src/validation.cpp Outdated Show resolved Hide resolved
src/validation.h Outdated Show resolved Hide resolved
Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK. A few non-blocking suggestions inline.

src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
@jamesob jamesob force-pushed the 2021-07-mempool-ptr branch from 8511429 to 29acd85 Compare July 9, 2021 17:14
@jamesob
Copy link
Contributor Author

jamesob commented Jul 9, 2021

Thanks for the prompt attention, good people. I've pushed a rebase that includes pretty much all of @jnewbery's feedback. This widens the scope of the PR to encompass a bit of refactoring, but I think it's all reasonable stuff to include here.

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK 29acd85. Simplifications from John make the change nicer.

src/validation.cpp Outdated Show resolved Hide resolved
@jamesob jamesob force-pushed the 2021-07-mempool-ptr branch from 29acd85 to e34a992 Compare July 9, 2021 18:48
@jamesob
Copy link
Contributor Author

jamesob commented Jul 9, 2021

Rebase to incorporate minor changes from @ryanofsky's feedback (#22415 (comment)).

src/validation.cpp Outdated Show resolved Hide resolved
src/validation.cpp Outdated Show resolved Hide resolved
src/validation.h Show resolved Hide resolved
@@ -4763,7 +4772,7 @@ bool ChainstateManager::ActivateSnapshot(
}

auto snapshot_chainstate = WITH_LOCK(::cs_main, return std::make_unique<CChainState>(
this->ActiveChainstate().m_mempool, m_blockman, base_blockhash));
nullptr, m_blockman, base_blockhash));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also surprised by this. Is the snapshot chainstate the one that eventually becomes our tip? In that case, don't we want it to have a mempool?

Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. Just a few small comments inline.

src/validation.cpp Outdated Show resolved Hide resolved
src/validation.h Outdated Show resolved Hide resolved
@jamesob jamesob force-pushed the 2021-07-mempool-ptr branch from e34a992 to c13e832 Compare July 12, 2021 18:38
Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK c13e832

src/validation.h Outdated Show resolved Hide resolved
src/validation.cpp Show resolved Hide resolved
src/validation.cpp Show resolved Hide resolved
src/validation.h Outdated Show resolved Hide resolved
src/validation.cpp Show resolved Hide resolved
src/test/validation_flush_tests.cpp Show resolved Hide resolved
@jamesob
Copy link
Contributor Author

jamesob commented Jul 13, 2021

Anyone have any idea what the deal is with libsecp tests failing on ARM here?
image

This doesn't look like a spurious failure.

@ryanofsky
Copy link
Contributor

ryanofsky commented Jul 13, 2021

@MarcoFalke would probably be most knowledgeable about the qemu-arm coredump #22415 (comment) https://cirrus-ci.com/task/6754077301276672?logs=ci#L3494, I was curious about that too. It seems like it is happening in a libsecp256k1 test so not related? But maybe there are ways to debug.

(I don't want to bikeshed the style issues, since they don't actually matter at all. But just for fun I'll say I do agree with John in not liking mostly spurious const. Also would drop Try prefix or replace it with Maybe since Try suggests some kind of failure would be expected. I do think having this-> prefixes is more readable in current code to distinguish method calls from function calls, but in non-legacy code it'd be cleaner to use lowerCaseMethod() and UpperCaseFunction() names to avoid the ambiguity.)

@maflcko
Copy link
Member

maflcko commented Jul 13, 2021

The (~x[m][shift]) << (64 - (1 << usebits))) == 0 failure is expected: bitcoin-core/secp256k1#610 (comment)

@maflcko
Copy link
Member

maflcko commented Jul 13, 2021

Could edit OP to remove the section that no longer applies to make sure it doesn't end up in the final merge commit?

jamesob and others added 2 commits July 13, 2021 11:11
Since we now have multiple chainstate objects, only one of them is active at any given
time. An active chainstate has a mempool, but there's no point to others having one.

This change will simplify proposed assumeutxo semantics. See the discussion here:
bitcoin#15606 (review)

Co-authored-by: Russell Yanofsky <[email protected]>
Allows fewer arguments and simplification of call sites.

Co-authored-by: John Newbery <[email protected]>
@jamesob jamesob force-pushed the 2021-07-mempool-ptr branch from c13e832 to 8a38f35 Compare July 13, 2021 15:13
@jamesob
Copy link
Contributor Author

jamesob commented Jul 13, 2021

Pushed a rebase:

  • TryUpdateMempool... -> MaybeUpdateMempool...
  • Removed unnecessary consts
  • Removed outdated content from OP

jamesob and others added 2 commits July 13, 2021 11:16
Unnecessary argument since we can make use of this->m_mempool

Co-authored-by: John Newbery <[email protected]>
Makes sense and saves on arguments.

Co-authored-by: John Newbery <[email protected]>
@jamesob jamesob force-pushed the 2021-07-mempool-ptr branch from 8a38f35 to ceb7b35 Compare July 13, 2021 15:16
@jamesob
Copy link
Contributor Author

jamesob commented Jul 13, 2021

  • unnecessary tx_pool removed

@jnewbery
Copy link
Contributor

ACK ceb7b35

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK ceb7b35 (just minor style and test tweaks since last review)

Copy link
Contributor

@lsilva01 lsilva01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review ACK and tested on Signet ACK ceb7b35

@naumenkogs
Copy link
Member

ACK ceb7b35

Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

review ACK ceb7b35 😌

Show signature and timestamp

Signature:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

review ACK ceb7b35a39145717e2d9d356fd382bd1f95d2a5a 😌
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUhhlwwAtTlbDcsq2EyaUfR0ZvA00PHL6azSeUF1jZ0G0i3eTSVzYlATm+ePtd0W
wsJW4atryMHoqAGZeXTpjt8SZ9XqVdlylswiYefDVTmc9qq9T7ejW4uVtzY/sM45
D6jWRRSUg9xX8c7zrjRaxbPfdGonDTKxkh4BK3v1B9mm2+YVb5EjMDqszzsJs1ef
3VfWNwhRWmfLI9voCAIfOUzFQQC1dWI7NqS7V6MoTnEIpJouK34hvaA51un7iu38
ER5rUhmVUTT/VxkwbzlOlu4C654IVgAq4S2YQ0NWSIDgsuqxEe/C2nfUlm/bPl/v
Khu3jCJz9u26BCLOfkBEpftGUhhFK+djxgitDz/ktzD8taU6Fy2sDPp8vjL8cL3B
//Y87WELvtdUwDxBtqfxkkh+Yy7029uNm3n4Rh6Gex3dsAAZhWAaCKM/1uO1g2+9
KLFtb8sjMb57JQwG3Cdqs889JKjkUzeHdM52w9eu2WBQyWUhSAApuYsf1CUasjwS
I/SNB2Cz
=pjF5
-----END PGP SIGNATURE-----

Timestamp of file with hash 74406e84f80bcb1056122ddab2c038117cd73fd1e1a79cd5df1958eacc8b9b20 -

@maflcko maflcko merged commit c0224bc into bitcoin:master Jul 15, 2021
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jul 23, 2021
gwillen pushed a commit to ElementsProject/elements that referenced this pull request Jun 1, 2022
@jamesob jamesob mentioned this pull request Jun 28, 2022
18 tasks
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants