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

8193031: Collections.addAll is likely to perform worse than Collection.addAll #1764

Closed
wants to merge 10 commits into from

Conversation

stsypanov
Copy link
Contributor

@stsypanov stsypanov commented Dec 14, 2020

Hello, I feel like this was previously discussed in https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot find original mail I post this here.

Currently Collections.addAll() is implemented and documented as:

    /**
     * ...
     * The behavior of this convenience method is identical to that of
     * {@code c.addAll(Arrays.asList(elements))}, but this method is likely
     * to run significantly faster under most implementations.
     */
    @SafeVarargs
    public static <T> boolean addAll(Collection<? super T> c, T... elements) {
        boolean result = false;
        for (T element : elements)
            result |= c.add(element);
        return result;
    }

But it practice the notation this method is likely to run significantly faster under most implementations is completely wrong. When I take this benchmark and run it on JDK 14 I get the following results:

                                                   (collection)  (size)      Score     Error   Units
addAll                                                ArrayList      10       37.9 ±     1.9   ns/op
addAll                                                ArrayList     100       83.8 ±     3.4   ns/op
addAll                                                ArrayList    1000      678.2 ±    23.0   ns/op
collectionsAddAll                                     ArrayList      10       50.9 ±     1.1   ns/op
collectionsAddAll                                     ArrayList     100      751.4 ±    47.4   ns/op
collectionsAddAll                                     ArrayList    1000     8839.8 ±   710.7   ns/op

addAll                                                  HashSet      10      128.4 ±     5.9   ns/op
addAll                                                  HashSet     100     1864.2 ±   102.4   ns/op
addAll                                                  HashSet    1000    16615.5 ±  1202.6   ns/op
collectionsAddAll                                       HashSet      10      172.8 ±     6.0   ns/op
collectionsAddAll                                       HashSet     100     2355.8 ±   195.4   ns/op
collectionsAddAll                                       HashSet    1000    20364.7 ±  1164.0   ns/op

addAll                                               ArrayDeque      10       54.0 ±     0.4   ns/op
addAll                                               ArrayDeque     100      319.7 ±     2.5   ns/op
addAll                                               ArrayDeque    1000     3176.9 ±    22.2   ns/op
collectionsAddAll                                    ArrayDeque      10       66.5 ±     1.4   ns/op
collectionsAddAll                                    ArrayDeque     100      808.1 ±    55.9   ns/op
collectionsAddAll                                    ArrayDeque    1000     5639.6 ±   240.9   ns/op

addAll                                     CopyOnWriteArrayList      10       18.0 ±     0.7   ns/op
addAll                                     CopyOnWriteArrayList     100       39.4 ±     1.7   ns/op
addAll                                     CopyOnWriteArrayList    1000      371.1 ±    17.0   ns/op
collectionsAddAll                          CopyOnWriteArrayList      10      251.9 ±    18.4   ns/op
collectionsAddAll                          CopyOnWriteArrayList     100     3405.9 ±   304.8   ns/op
collectionsAddAll                          CopyOnWriteArrayList    1000   247496.8 ± 23502.3   ns/op

addAll                                    ConcurrentLinkedDeque      10       81.4 ±     2.8   ns/op
addAll                                    ConcurrentLinkedDeque     100      609.1 ±    26.4   ns/op
addAll                                    ConcurrentLinkedDeque    1000     4494.5 ±   219.3   ns/op
collectionsAddAll                         ConcurrentLinkedDeque      10      189.8 ±     2.5   ns/op
collectionsAddAll                         ConcurrentLinkedDeque     100     1660.0 ±    62.0   ns/op
collectionsAddAll                         ConcurrentLinkedDeque    1000    17649.2 ±   300.9   ns/op

addAll:·gc.alloc.rate.norm                            ArrayList      10      160.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                            ArrayList     100      880.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                            ArrayList    1000     8080.3 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                 ArrayList      10       80.0 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                 ArrayList     100     1400.2 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                 ArrayList    1000    15025.6 ±     0.1    B/op

addAll:·gc.alloc.rate.norm                              HashSet      10      464.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                              HashSet     100     5328.5 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                              HashSet    1000    48516.7 ±     0.1    B/op
collectionsAddAll:·gc.alloc.rate.norm                   HashSet      10      464.0 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                   HashSet     100     5328.5 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                   HashSet    1000    48516.6 ±     0.1    B/op

addAll:·gc.alloc.rate.norm                           ArrayDeque      10      112.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                           ArrayDeque     100      560.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                           ArrayDeque    1000     4160.5 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                ArrayDeque      10      112.0 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                ArrayDeque     100     1048.1 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm                ArrayDeque    1000    14929.4 ±     0.0    B/op

addAll:·gc.alloc.rate.norm                 CopyOnWriteArrayList      10       88.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                 CopyOnWriteArrayList     100      448.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                 CopyOnWriteArrayList    1000     4048.1 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm      CopyOnWriteArrayList      10      456.0 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm      CopyOnWriteArrayList     100    22057.2 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm      CopyOnWriteArrayList    1000  2020150.3 ±     7.3    B/op

addAll:·gc.alloc.rate.norm                ConcurrentLinkedDeque      10      312.0 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                ConcurrentLinkedDeque     100     2472.1 ±     0.0    B/op
addAll:·gc.alloc.rate.norm                ConcurrentLinkedDeque    1000    24073.7 ±     0.1    B/op
collectionsAddAll:·gc.alloc.rate.norm     ConcurrentLinkedDeque      10      288.0 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm     ConcurrentLinkedDeque     100     2448.3 ±     0.0    B/op
collectionsAddAll:·gc.alloc.rate.norm     ConcurrentLinkedDeque    1000    24051.4 ±     0.3    B/op

There's never a case when Collections.addAll is fater - on the contrary c.addAll(Arrays.asList()) always wins. Pay attention especially to dramatic difference for array-based collection.

So I propose to reimplement the method by simply delegating to Arrays.asList because the spec declares identical behaviour and to remove perfomance notation from JavaDoc.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8193031: Collections.addAll is likely to perform worse than Collection.addAll

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1764/head:pull/1764
$ git checkout pull/1764

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Dec 14, 2020

👋 Welcome back stsypanov! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@stsypanov stsypanov changed the title Collections.addAll() is implemented ineffective and its Javadoc provides misleading information Collections.addAll() is implemented ineffectively and its Javadoc provides misleading information Dec 14, 2020
@stsypanov stsypanov changed the title Collections.addAll() is implemented ineffectively and its Javadoc provides misleading information Collections.addAll() is implemented ineffectively and its JavaDoc provides misleading information Dec 14, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Dec 14, 2020

@stsypanov The following label will be automatically applied to this pull request:

  • core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the core-libs label Dec 14, 2020
@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Dec 17, 2020

/issue JDK-8193031

@openjdk openjdk bot changed the title Collections.addAll() is implemented ineffectively and its JavaDoc provides misleading information 8193031: Collections.addAll is likely to perform worse than Collection.addAll Dec 17, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Dec 17, 2020

@stsypanov The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Dec 17, 2020

Looks like I've found the original ticket: https://bugs.openjdk.java.net/browse/JDK-8193031

@openjdk openjdk bot added the rfr label Dec 17, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 17, 2020

Webrevs

@@ -5587,11 +5586,9 @@ public static boolean disjoint(Collection<?> c1, Collection<?> c2) {
* @since 1.5
*/
@SafeVarargs
@SuppressWarnings("varargs")
Copy link
Member

@forax forax Dec 17, 2020

Choose a reason for hiding this comment

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

I don't think you need a SuppressWarnings here

Copy link
Contributor Author

@stsypanov stsypanov Dec 17, 2020

Choose a reason for hiding this comment

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

Hi, without this I get failed build:

Compiling 3057 files for java.base
Compiling 89 properties into resource bundles for java.desktop
/home/s.tsypanov/IdeaProjects/jdk-github/src/java.base/share/classes/java/util/Collections.java:5590: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter elements
        return c.addAll(Arrays.asList(elements));
                                      ^
error: warnings found and -Werror specified
1 error
1 warning
make[3]: *** [/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1
CompileJavaModules.gmk:604: recipe for target '/home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch' failed
make[2]: *** [java.base-java] Error 2
make[2]: *** Waiting for unfinished jobs....
make/Main.gmk:193: recipe for target 'java.base-java' failed

Copy link
Member

@forax forax Dec 17, 2020

Choose a reason for hiding this comment

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

ok, it means there is a bug in the compiler, the analysis done for unsafe varargs (with -Xlint:varargs) doesn't check that the called method (here Arrays.asList()) is tagged with @SafeVarargs.

Copy link
Contributor Author

@stsypanov stsypanov Dec 17, 2020

Choose a reason for hiding this comment

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

Should I then wait for the fix of that bug to remove @SupressWarnings?

Copy link
Member

@forax forax Dec 17, 2020

Choose a reason for hiding this comment

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

I don't think so, the code is fine, for me.

Copy link
Contributor Author

@stsypanov stsypanov Dec 18, 2020

Choose a reason for hiding this comment

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

I've looked into com.sun.tools.javac.comp.Check and it seems the warning is produced here:

        @Override
        public void warn(LintCategory lint) {
            boolean warned = this.warned;
            super.warn(lint);
            if (warned) return; // suppress redundant diagnostics
            switch (lint) {
                case UNCHECKED:
                    Check.this.warnUnchecked(pos(), Warnings.ProbFoundReq(diags.fragment(uncheckedKey), found, expected));
                    break;
                case VARARGS:
                    if (method != null &&
                            method.attribute(syms.trustMeType.tsym) != null &&
                            isTrustMeAllowedOnMethod(method) &&
                            !types.isReifiable(method.type.getParameterTypes().last())) {
                        Check.this.warnUnsafeVararg(pos(), Warnings.VarargsUnsafeUseVarargsParam(method.params.last()));
                    }
                    break;
                default:
                    throw new AssertionError("Unexpected lint: " + lint);
            }
        }

Can we somehow read @SaveVarargs from signature of Arrays.asList() to avoid the warning?

Copy link
Contributor Author

@stsypanov stsypanov Dec 21, 2020

Choose a reason for hiding this comment

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

@forax I've sent a mail into compiler-dev list: http://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015857.html

Let's see what they decide.

Copy link
Contributor

@jonathan-gibbons jonathan-gibbons Dec 21, 2020

Choose a reason for hiding this comment

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

FYI, despite the confusing (historical) name, syms.trustMeType is the SafeVarargs annotation. See Symtab.java, line 579.

@forax
Copy link
Member

@forax forax commented Dec 17, 2020

Apart from the @SuppressWarnings, this looks good to me.
And i like the irony of this.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 17, 2020

Mailing list message from Simon Roberts on core-libs-dev:

When updating this, might you take the opportunity to remove the ambiguous
antecedent too? The use of "this method" when there are two methods in the
discussion (Collections.addAll, and the proximate one; Collection.addAll)
is unclear (indeed, one could argue the original text might have intended
to use "this method" to refer to Collection.addAll, in which interpretation
it's correct :)

A more specific comment on the lines of "Collection.addAll is likely to run
faster..." would entirely avoid the ambiguity.

Perhaps that's the intended solution anyway, in which case, I apologize for
the distraction.

On Thu, Dec 17, 2020 at 3:38 AM R?mi Forax <github.com+
828220+forax at openjdk.java.net> wrote:

--
Simon Roberts
(303) 249 3613

@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 18, 2020

Mailing list message from Сергей Цыпанов on core-libs-dev:

Hi Simon, I've removed 'but this method is likely to run significantly faster under most implementations.' so the doc is cleaner now

Cheers,
Sergey

17.12.2020, 16:38, "Simon Roberts" <simon at dancingcloudservices.com>:

When updating this, might you take the opportunity to remove the ambiguous
antecedent too? The use of "this method" when there are two methods in the
discussion (Collections.addAll, and the proximate one; Collection.addAll)
is unclear (indeed, one could argue the original text might have intended
to use "this method" to refer to Collection.addAll, in which interpretation
it's correct :)

A more specific comment on the lines of "Collection.addAll is likely to run
faster..." would entirely avoid the ambiguity.

Perhaps that's the intended solution anyway, in which case, I apologize for
the distraction.

On Thu, Dec 17, 2020 at 3:38 AM R?mi Forax <github.com+
828220+forax at openjdk.java.net> wrote:

--
Simon Roberts
(303) 249 3613

@lgxbslgx
Copy link
Member

@lgxbslgx lgxbslgx commented Dec 19, 2020

Hi all,

According to the document of SafeVarargs.

Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where:

The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable arity parameter's array that generates an unchecked warning.

The SafeVarargs may not suppress the warning of this assignment and the SuppressWarnings may be necessary.

If you still think it is the bug of compiler. I suggest that you move the bug discussion to the compiler-dev@openjdk.java.net to solve the bug as soon as possible.

@openjdk
Copy link

@openjdk openjdk bot commented Dec 21, 2020

⚠️ @stsypanov This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

@pavelrappo
Copy link
Member

@pavelrappo pavelrappo commented Dec 21, 2020

This message is purely informational: I may have found a JBS comment that provides historical context for that "this method is likely to run significantly faster under most implementations" phrase. Here: https://bugs.openjdk.java.net/browse/JDK-4822887?focusedCommentId=12241154&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12241154

@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Dec 21, 2020

@pavelrappo the problem is that people still believe this message and use this utility method widely: see e.g. spring-projects/spring-framework#23478

They expect it to improve performance, but in fact it degradates. Also for some cases it degrade dramatically, e.g. when instead of ArrayList COWArrayList comes as argument

@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Dec 21, 2020

@pavelrappo also see this not very old comment: spring-projects/spring-framework#24636 (review)

@pavelrappo
Copy link
Member

@pavelrappo pavelrappo commented Dec 21, 2020

"This message" referred to the entirety of that very comment of mine #1764 (comment)

I prepended that message with that clause (that is, the wording to the left of the colon) to make it clear that I didn't want to review or argue with anything said before that in that thread; it seems that clause made more harm than good.

@plevart
Copy link
Contributor

@plevart plevart commented Dec 29, 2020

Hi,
Sorry for joining late to this discussion, but I think that changing this method to delegate to c.addAll(Arrays.asList(...)) might not be the best thing to do here. Why?

  • This might look as a convenience method, but it takes only 2 characters less to type Collections.addAll(c, ...) than it takes to type c.addAll(Arrays.asList(...)), so we would basically end up with two ways of performing the same thing. I think we can make a method that would be worth more than that.
  • Pursuing performance is a noble goal, but performance is not everything. Predictability and guarantees are also important. The convenience method, being varargs method, can also be invoked with an array in place of varargs argument. Current implementation is trusted (part of JDK) and guarantees to never modify the passed-in array argument. If this was modified to just delegate to Collection.addAll(Arrays.asList(array)), it depends on the concrete implementation of the .addAll method of the implementation class of the collection. Misbehaving collection implementation could modify the passed-in Arrays.asList and such modifications would propagate to the array.

So I would preferably do one of two things here. Either change the javadoc to describe current behaviour better, or use some other immutable List wrapper different than Arrays.asList() which is mutable. WDYT?

@plevart
Copy link
Contributor

@plevart plevart commented Dec 29, 2020

Hint: you could use java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed if only this method would allow other types of arrays, not just Object[]... I really don't know why this restriction couldn't be lifted as the captured array is fully encapsulated.

@plevart
Copy link
Contributor

@plevart plevart commented Dec 29, 2020

On a second thought, using java.util.ImmutableCollections#listFromTrustedArrayNullsAllowed is not a good idea, since the method expects the passed-in array to be trusted and use of this method in Collections.addAll(col, array) would wrap an untrusted array. Surely the resulting List would only be used as an argument to col.addAll(list), but since neither col is trusted, it could "steal" the passed-in list and use it...
Some other implementation of immutable list array wrapper would be needed here.

@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Dec 29, 2020

@plevart hi, I've decided to revert implementation change and keep only the change in JavaDoc because it's performance-related part is often referenced to while being incorrect in most of cases.

@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Jan 8, 2021

@forax, @plevart could I ask for review once again?

@plevart
Copy link
Contributor

@plevart plevart commented Jan 8, 2021

Hi @stsypanov,

The behavior of this convenience method is identical to that of c.addAll(Arrays.asList(elements))

What about:

The behaviour of this convenience method is similar to that of c.addAll(Arrays.asList(elements))

...since it is not entirely identical. The outcome is usually identical because collections usually adhere to the specification, but we can not claim the behaviour is identical if the target collection does not adhere.

@plevart
Copy link
Contributor

@plevart plevart commented Jan 8, 2021

...but we could employ this method to guarantee more than c.addAll(Arrays.asList(elements)) does. So what about:

The behaviour of this convenience method is similar to that of c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))

This means that the method guarantees that the passed in elements array will not be modified even if given collection c is not trusted. Speaking of that, perhaps you could try benchmarking such c.addAll(Collections.unmodifiableList(Arrays.asList(elements))) and see how it compares. The speed-up you observed from c.addAll(Arrays.asList(elements)) with some collections was probably a result of them calling .toArray() on the argument collection and incorporating the resulting array into their own data structure in a bulk-copying-way. So c.addAll(Collections.unmodifiableList(Arrays.asList(elements))) might have same performance characteristics while guaranteeing same things about argument array. It might be slower when Iterator is employed though because unmodifiableList wrapper wraps Iterator(s) too....

@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Jan 14, 2021

@plevart done. Should I also rename this PR to e.g. 'Fix performance-related notation in Collections.addAll'?

@plevart
Copy link
Contributor

@plevart plevart commented Jan 14, 2021

@plevart done. Should I also rename this PR to e.g. 'Fix performance-related notation in Collections.addAll'?

I think the title of JIRA ticket has to be the same as that of PR (with JIRA bug number prepended) in order to pass all checks needed for integrating. So If you modify both, it would be fine.

@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Jan 14, 2021

I cannot modify JIRA ticket without account there, so let's keep it as is

Copy link
Contributor

@plevart plevart left a comment

I think this looks good.

@openjdk
Copy link

@openjdk openjdk bot commented Jan 14, 2021

⚠️ @stsypanov the full name on your profile does not match the author name in this pull requests' HEAD commit. If this pull request gets integrated then the author name from this pull requests' HEAD commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:

$ git checkout add-all
$ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name'
$ git push

@openjdk
Copy link

@openjdk openjdk bot commented Jan 14, 2021

@stsypanov This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8193031: Collections.addAll is likely to perform worse than Collection.addAll

Reviewed-by: plevart

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 7 new commits pushed to the master branch:

  • d18d26e: 8259350: Add some internal debugging APIs to the debug agent
  • a6b2162: 8259278: Optimize Vector API slice and unslice operations
  • da6bcf9: 8255019: Shenandoah: Split STW and concurrent mark into separate classes
  • aba3431: 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result
  • 8554fe6: 8253866: Security Libs Terminology Refresh
  • c2a3c7e: 8259727: Remove redundant "target" arguments to methods in Links
  • 1620664: 8259723: Move Table class to formats.html package

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@plevart) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label Jan 14, 2021
@stsypanov
Copy link
Contributor Author

@stsypanov stsypanov commented Jan 14, 2021

/integrate

@openjdk openjdk bot added the sponsor label Jan 14, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 14, 2021

@stsypanov
Your change (at version 2400492) is now ready to be sponsored by a Committer.

@plevart
Copy link
Contributor

@plevart plevart commented Jan 15, 2021

Hearing no objections, I'll sponsor this for Sergei.

@plevart
Copy link
Contributor

@plevart plevart commented Jan 15, 2021

/sponsor

@openjdk openjdk bot closed this Jan 15, 2021
@openjdk openjdk bot added integrated and removed sponsor ready rfr labels Jan 15, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 15, 2021

@plevart @stsypanov Since your change was applied there have been 26 commits pushed to the master branch:

  • 5855d52: 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros
  • 360c722: 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion
  • b78cd63: 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations
  • eb7fa00: 8259216: javadoc omits method receiver for any nested type annotation
  • bcf20a0: 8259777: Incorrect predication condition generated by ADLC
  • bbac91a: 8257959: Add gtest run with -XX:+UseLargePages
  • 707bce0: 8257212: (bf spec) Clarify byte order of the buffer returned by CharBuffer.subsequence(int,int)
  • 0ec2c96: 8259820: JShell does not handle -source 8 properly
  • b01a15e: 8258884: [TEST_BUG] Convert applet-based test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular java test
  • 6d4a593: 8259627: Potential memory leaks in JVMTI after JDK-8227745
  • ... and 16 more: https://git.openjdk.java.net/jdk/compare/38a1201746db938f01ebe50115689c86681ef050...master

Your commit was automatically rebased without conflicts.

Pushed as commit 27a39c8.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@stsypanov stsypanov deleted the add-all branch Jan 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs integrated
6 participants