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

Simpler using compressed oops flag representation #15509

Merged
merged 2 commits into from
Dec 17, 2015
Merged

Simpler using compressed oops flag representation #15509

merged 2 commits into from
Dec 17, 2015

Conversation

jasontedor
Copy link
Member

This commit modifies the internal representation of the JVM flag
UseCompressedOops to just be a String. This means we can just store the
value of the flag or "unknown" directly so that we do not have to engage
in shenanigans with three-valued logic around a boxed boolean.

Relates #15489

This commit modifies the internal representation of the JVM flag
UseCompressedOops to just be a String. This means we can just store the
value of the flag or "unknown" directly so that we do not have to engage
in shenanigans with three-valued logic around a boxed boolean.

Relates #15489
@jasontedor
Copy link
Member Author

The ultimate endgame here is simpler handling in the backwards compatibility code in the 2.x line so that we can distinguish between "true", "false" and "unknown" from a >= 2.2.0 node, and null from a < 2.2.0 node.

} else {
usingCompressedOops = null;
}
useCompressedOops = in.readOptionalString();
Copy link
Member

Choose a reason for hiding this comment

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

Can it be null?

Copy link
Member Author

Choose a reason for hiding this comment

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

@nik9000 Not in master, good catch. I'll remove the optional for master but it will be needed on the 2.x backport.

@nik9000
Copy link
Member

nik9000 commented Dec 17, 2015

LGTM - I left a comment asking about the return value from the jvm's info API. Maybe if it returns null we should set it to "unknown".

@@ -307,7 +314,7 @@ public XContentBuilder toXContent(XContentBuilder builder, Params params) throws
builder.field(Fields.GC_COLLECTORS, gcCollectors);
builder.field(Fields.MEMORY_POOLS, memoryPools);

builder.field(Fields.USING_COMPRESSED_OOPS, usingCompressedOops == null ? "unknown" : Boolean.toString(usingCompressedOops));
builder.field(Fields.USING_COMPRESSED_OOPS, useCompressedOops);
Copy link
Member

Choose a reason for hiding this comment

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

If it can be null we should skip it here.

Copy link
Member Author

Choose a reason for hiding this comment

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

@nik9000 Yes, that's exactly how it will be on the backport but it's not needed here.

@jasontedor
Copy link
Member Author

LGTM - I left a comment asking about the return value from the jvm's info API. Maybe if it returns null we should set it to "unknown".

The return from the API can not be null.

jasontedor added a commit that referenced this pull request Dec 17, 2015
…resentation

Simpler using compressed oops flag representation
@jasontedor jasontedor merged commit c867c7c into elastic:master Dec 17, 2015
@jasontedor jasontedor deleted the simpler-compressed-oops-representation branch December 17, 2015 17:21
jasontedor added a commit that referenced this pull request Dec 17, 2015
This commit backports commit c867c7c
from master to 2.x.

Relates #15509
@jasontedor
Copy link
Member Author

Thank you for reviewing @nik9000.

@jasontedor jasontedor removed the review label Dec 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants