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

[WIP] Add immutable interface as a hint to skip defensive cloning #11479

Closed
wants to merge 1 commit into from

Conversation

mmedenjak
Copy link
Contributor

We perform defensive cloning in some cases such as:

  • receiving user supplied objects (e.g. aggregators and projections for map query engine)
  • providing hazelcast internal object to the user (e.g. store implementations)
    If the user makes a promise not to mutate the object or provide state
    which changes during cloning, we can skip cloning and gain performance.

NOTE If we decide not to merge this now, I will just remove the cloning for the readFromEventJournal method.

See:
#11410

We perform defensive cloning in some cases such as:
- receiving user supplied objects
- providing hazelcast internal object to the user
If the user makes a promise not to mutate the object or provide state
which changes during cloning, we can skip cloning and gain performance.

See:
hazelcast#11410
* It is important that the user follows the rules:
* <ul>
* <li>the object must not have any state which is changed by cloning the object</li>
* <li>the existing state must not be changed</li>
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the first one not implied by the second one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The first one should cover the case where the user supplies an predicate, for example, where the result of the predicate depends on some state which is lost on cloning.
The second one should cover the case where we provide the user an internal hz object like giving him the OBJECT instance to the map store, for example, and we expect that he will play by the rules and not change it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried to make the javadoc as clear I could at the moment but I must admit the wording might not be ideal. I would definitely like to make it crystal clear that the user should "play by the rules". So I'm open to suggestions.

Copy link
Contributor

@Donnerbart Donnerbart left a comment

Choose a reason for hiding this comment

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

Just naming and JavaDoc comments, technically it's looking good to me.

* @param <T> the type of the object
* @return the object clone or the provided object if it implements {@link Immutable}
*/
private <T> T cloneIfNecessary(T object) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Alternative name: cloneIfMutable() (it's at least easier to spell and describes well what it does)

import com.hazelcast.spi.annotation.Beta;

/**
* Allows notifying Hazelcast code that the object implementing this interface is effectively immutable.
Copy link
Contributor

Choose a reason for hiding this comment

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

If we keep this text, it's optimizations (American English) and Hazelcast (uppercase).

Alternative:

/**
 * Marks classes that are (effectively) immutable.
 * <p>
 * Instances of immutable classes either have no state (e.g. pure functions) or the state
 * is not mutated after the object construction (e.g. all fields are final). This allows
 * Hazelcast to apply performance optimizations such as avoiding cloning user supplied
 * objects or cloning Hazelcast internal objects supplied to the user.
 * <p>
 * It is important that to follows these rules:
 * <ul>
 * <li>the object must not have any state which is changed by cloning the object</li>
 * <li>the existing state must not be changed</li>
 * </ul>
 * <b>Warning:</b> If a class implements this interface but does not follow these rules,
 * the results of the execution are undefined.
 */

@jerrinot jerrinot modified the milestones: 3.9, 3.10 Oct 4, 2017
@jerrinot
Copy link
Contributor

jerrinot commented Oct 4, 2017

@mmedenjak: I prefer to move this to 3.10.

@mmedenjak mmedenjak modified the milestones: 3.10, 3.11 Mar 7, 2018
@mmedenjak mmedenjak modified the milestones: 3.11, 3.12 Sep 4, 2018
@mmedenjak mmedenjak added the Source: Internal PR or issue was opened by an employee label Jan 29, 2019
@Holmistr
Copy link
Contributor

Closing for inactivity. Please reopen if necessary.

@Holmistr Holmistr closed this Jan 29, 2019
@mmedenjak mmedenjak added the ignore Ignore issue or PR in various lists and searches label Jan 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ignore Ignore issue or PR in various lists and searches Source: Internal PR or issue was opened by an employee Team: Core Type: Enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants