Skip to content

Conversation

@dcapwell
Copy link
Contributor

@dcapwell dcapwell commented Sep 3, 2025

No description provided.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

think i should likely rename this to call out its really only safe for CAS since it has 1 condition

Copy link
Contributor

Choose a reason for hiding this comment

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

where is this used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we spoke in slack

It used to be used but after moving off the all/non bit sets, nothing uses and i forgot to cleanup

Copy link
Contributor

Choose a reason for hiding this comment

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

do we use this hashCode, or can we throw UnsupportedOperationException? If not, can we just use id?

Copy link
Contributor

Choose a reason for hiding this comment

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

suggest: new line

Copy link
Contributor Author

Choose a reason for hiding this comment

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

code has changed a lot since this comment, i assume you changed this in your feedback branch? I assume you wanted a newline above this?

Copy link
Contributor

Choose a reason for hiding this comment

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

should this use TxnCondition.None instead of null? Can simplify some other logic then.

Copy link
Contributor

@belliottsmith belliottsmith Sep 4, 2025

Choose a reason for hiding this comment

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

outter is a typo, but I prefer superset/subset for this kind of logic as it makes clearer the relationship. Also, we already have this logic in various places. The most obvious is AbstractWithKeysSerializer, though this is more annoying to use that we might like. Surely we at least have the subset bitset logic somewhere already? If not, let's at least consider adding that, but it's a shame this form of logic is getting fragmented and reproduced in different ways.

Copy link
Contributor

Choose a reason for hiding this comment

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

why not standardise(ish) the two serializers? They're basically the same, we just have an implicit capacity for the small bitset. Then for this serializer we can avoid writing a kind and instead write the capacity, which implies if it can be created as a SmallBitSet or must be a LargeBitSet.

The large serializer can avoid writing out wordsInUse if <= 1, and always serialize at least one long (with value 0 if empty), and then the two are serialied identically, and we would just need the large serializer to expose methods that accept/assume the capacity so we can invoke that directly for this use case.

{
long size = TypeSizes.sizeofUnsignedVInt(t.id);
size += serializedSizeWithVIntLength(t.condition.bytes());
size += TypeSizes.sizeof(t.condition != null);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is condition nullable? I don't believe we assign it anything non-null in real codepaths, and I don't think we should either, since we have the None condition (which takes up 1 byte rather than zero).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants