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

Specialized collections with package remapping #231

Closed
wants to merge 3 commits into from

Conversation

avpotapov00
Copy link
Collaborator

  1. Standart java collections replaced with Fastutils collections
  2. Remapping Fastutil package to Lincheck package using Gradle shadow plugin

2. Remapping Fastutil package to lincheck package using gradle shadow plugin
@avpotapov00 avpotapov00 self-assigned this Aug 22, 2023
@ndkoval ndkoval changed the base branch from master to develop August 22, 2023 11:47
List<ActorGenerator> actorGenerators = new ArrayList<>();
List<Method> validationFunctions = new ArrayList<>();
List<Method> stateRepresentations = new ArrayList<>();
Map<String, OperationGroup> groupConfigs = new Object2ObjectOpenHashMap<>();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just a random suggestion.
Maybe add type-aliases like LincheckHashMap and factory functions like lincheckListOf() and use them everywhere?
I think such solution has several benefits:

  1. The underlying collection implementations can be changed quite easily by changing type-aliases.
  2. We would hide collections' implementation details in one place.
  3. The name Object2ObjectOpenHashMap is quire verbose compared to something like LincheckHashMap.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh, I see you did something similar in CollectionUtils.kt, but I guess there is no way to use type-aliases from Java : (

Copy link
Collaborator

Choose a reason for hiding this comment

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

Anyway, what about using LincheckMutableHashMap naming scheme instead of MutableObjectToObjectMap?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I agree with you, and due to this limitation on type aliases in Java, the solution with factory-like top-level functions as lincheckListOf() looks pretty convenient, especially taking into account your arguments above. @ndkoval Do you still think it is redundant?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I also like the flexibility it brings.

Copy link
Collaborator

@ndkoval ndkoval Aug 23, 2023

Choose a reason for hiding this comment

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

Please put this discussion as a comment in the code.

Aleksandr.Potapov and others added 2 commits August 29, 2023 12:03
# Conflicts:
#	src/jvm/main/org/jetbrains/kotlinx/lincheck/strategy/managed/ManagedStrategy.kt
@ndkoval ndkoval marked this pull request as draft January 18, 2024 12:51
@ndkoval
Copy link
Collaborator

ndkoval commented May 29, 2024

With the current lazy transformation approach for model checking, we can safely keep using the standard collections. Therefore, I'm closing the PR. Thanks @avpotapov00 for investigating potential performance improvements!

@ndkoval ndkoval closed this May 29, 2024
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.

None yet

3 participants