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

rename verifier related value-types, rename JVM_SIGNATURE_VALUETYPE, … #83

Closed
wants to merge 2 commits into from

Conversation

hseigel
Copy link
Member

@hseigel hseigel commented Jun 15, 2020

This pull requiest renames JVM_SIGNATURE_VALUETYPE to JVM_SIGNATURE_INLINETYPE, renames verifier related value_type items to inline_type, and has a few other small changes.


Progress

  • Change must not contain extraneous whitespace

Reviewers

  • David Simms (dsimms - Committer)

Download

$ git fetch https://git.openjdk.java.net/valhalla pull/83/head:pull/83
$ git checkout pull/83

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 15, 2020

👋 Welcome back hseigel! A progress list of the required criteria for merging this PR into lworld will be added to the body of your pull request.

@openjdk
Copy link

openjdk bot commented Jun 15, 2020

@hseigel This change now passes all automated pre-integration checks, type /integrate in a new comment to proceed. After integration, the commit message will be:

rename verifier related value-types, rename JVM_SIGNATURE_VALUETYPE, …

Reviewed-by: dsimms
  • If you would like to add a summary, use the /summary command.
  • To credit additional contributors, use the /contributor command.
  • To add additional solved issues, use the /issue command.

Since the source branch of this PR was last updated there have been 2 commits pushed to the lworld branch:

  • 55bfd32: 8244561: [lworld] Javac should not allow instantiation of V.ref or V.val
  • bb06ed4: 8247664: [lworld] Bogus error message: incompatible types while using separate compilation

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge lworld into your branch, and then specify the current head hash when integrating, like this: /integrate 55bfd32bf8d9a4d4c4a01a8a59c8de442ded23ad.

➡️ To integrate this PR with the above commit message to the lworld branch, type /integrate in a new comment.

@mlbridge
Copy link

mlbridge bot commented Jun 15, 2020

Webrevs

Copy link
Member

@MrSimms MrSimms left a comment

Looks good

@hseigel
Copy link
Member Author

hseigel commented Jun 16, 2020

/integrate

@openjdk openjdk bot closed this Jun 16, 2020
@openjdk openjdk bot added integrated and removed ready rfr labels Jun 16, 2020
@openjdk
Copy link

openjdk bot commented Jun 16, 2020

@hseigel The following commits have been pushed to lworld since your change was applied:

  • 55bfd32: 8244561: [lworld] Javac should not allow instantiation of V.ref or V.val
  • bb06ed4: 8247664: [lworld] Bogus error message: incompatible types while using separate compilation

Your commit was automatically rebased without conflicts.

Pushed as commit 66c1d44.

Copy link
Collaborator

@fparain fparain left a comment

Harold,

Overall changes look good.
I've commented a few places where naming could be made more consistent (putting an underscore between "inline" and "type"). They are just suggestions, I'll let you decide to change names or not.

Thank you,

Fred

@@ -112,7 +112,7 @@ VerificationType StackMapFrame::set_locals_from_arg(
sig = sig_copy;
}
if (ss.type() == T_VALUETYPE) {
return VerificationType::valuetype_type(sig);
return VerificationType::inlinetype_type(sig);
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

VerificationType::inlinetype_type looks weird.
Could we use VerificationType::inline_type instead, which is consistent with VerificationType::reference_type?

@@ -194,7 +194,7 @@ VerificationType StackMapReader::parse_verification_type(u1* flags, TRAPS) {
_stream->stackmap_format_error("TBD something bad happened", THREAD);
return VerificationType::bogus_type();
}
return VerificationType::valuetype_type(fund_name);
return VerificationType::inlinetype_type(fund_name);
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

VerificationType::inlinetype_type -> VerificationType::inline_type ?

assert(is_valuetype(), "called with a non-valuetype type");
assert(!is_null(), "valuetype is not null");
return (!from.is_null() && from.is_valuetype() && name() == from.name());
bool VerificationType::is_inlinetype_assignable_from(const VerificationType& from) const {
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

is_inlinetype_assignable_from() -> is_inline_type_assignable_from()
to be more consistent with other names?

return (!from.is_null() && from.is_valuetype() && name() == from.name());
bool VerificationType::is_inlinetype_assignable_from(const VerificationType& from) const {
// Check that 'from' is not null, is an inline type, and is the same inline type.
assert(is_inlinetype(), "called with a non-inlinetype type");
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

is_inlinetype() -> is_inline_type() ?

@@ -153,8 +153,8 @@ class VerificationType {
// any reference is assignable to reference_check.
static VerificationType reference_check()
{ return VerificationType(ReferenceQuery); }
static VerificationType valuetype_check()
{ return VerificationType(ValueTypeQuery); }
static VerificationType inlinetype_check()
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

inlinetype_check() -> inline_type_check() ?

static VerificationType valuetype_type(Symbol* sh) {
// For inline types, store the actual Symbol* and set the 3rd bit.
// Provides a way for an inline type to be distinguished from a reference type.
static VerificationType inlinetype_type(Symbol* sh) {
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

inlinetype_type() -> inline_type() ?

@@ -222,7 +222,7 @@ class VerificationType {
return ((_u._data & Category2_2nd) == Category2_2nd);
}
bool is_reference_check() const { return _u._data == ReferenceQuery; }
bool is_valuetype_check() const { return _u._data == ValueTypeQuery; }
bool is_inlinetype_check() const { return _u._data == InlineTypeQuery; }
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

is_inlinetype_check() -> is_inline_type_check() ?

@@ -242,11 +242,11 @@ class VerificationType {
bool is_double_array() const { return is_x_array(JVM_SIGNATURE_DOUBLE); }
bool is_object_array() const { return is_x_array(JVM_SIGNATURE_CLASS); }
bool is_array_array() const { return is_x_array(JVM_SIGNATURE_ARRAY); }
bool is_value_array() const { return is_x_array(JVM_SIGNATURE_VALUETYPE); }
bool is_inline_array() const { return is_x_array(JVM_SIGNATURE_INLINE_TYPE); }
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

The term "inline" alone can be misleading (is it about the element being an inline type, is it about the elements of the array being inlined in the array, is it about the array being inlined in something else, etc).
Here, the check is about the kind of elements stored in the array, so I would suggest "is_inline_type_array()".

@@ -263,10 +263,10 @@ class VerificationType {
return VerificationType(is_long() ? Long_2nd : Double_2nd);
}

static VerificationType change_ref_to_valuetype(VerificationType ref) {
static VerificationType change_ref_to_inlinetype(VerificationType ref) {
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

change_ref_to_inlinetype() -> change_ref_to_inline_type() ?

@@ -588,9 +588,9 @@ void ErrorContext::stackmap_details(outputStream* ss, const Method* method) cons

// Methods in ClassVerifier

VerificationType reference_or_valuetype(InstanceKlass* klass) {
VerificationType reference_or_inlinetype(InstanceKlass* klass) {
Copy link
Collaborator

@fparain fparain Jun 16, 2020

Choose a reason for hiding this comment

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

reference_or_inlinetype() -> reference_or_inline_type() ?

@mlbridge
Copy link

mlbridge bot commented Jun 16, 2020

Mailing list message from John Rose on valhalla-dev:

On Jun 16, 2020, at 6:25 AM, Frederic Parain <fparain at openjdk.java.net> wrote:

src/hotspot/share/classfile/verificationType.hpp line 245:

244: bool is_array_array() const { return is_x_array(JVM_SIGNATURE_ARRAY); }
245: bool is_inline_array() const { return is_x_array(JVM_SIGNATURE_INLINE_TYPE); }
246: bool is_reference_array() const

The term "inline" alone can be misleading (is it about the element being an inline type, is it about the elements of
the array being inlined in the array, is it about the array being inlined in something else, etc). Here, the check is
about the kind of elements stored in the array, so I would suggest "is_inline_type_array()".

I actually have the opposite take on this (but it?s stylistic
and esthetic, so I?m OK with it going either way).
The term TYPE (and _type etc.) occurs too much in this
selection of names. And it is permanently jarring to
have T_INT (not T_INT_TYPE) but T_INLINE_TYPE.
?Can be misleading? is a relative term; usually it isn?t,
and there are other ways to reduce mistakes than put
an extra noise-word everywhere. The extra noise word
(?type?) can be annoying, and (more to the point) distracting
to the reader. In other words, there?s such a thing as
too much information in a name, and I think we are
over the line with this set of choices.

? John

@hseigel hseigel deleted the renameVerf branch Nov 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants