8288477: nmethod header size reduction

[bulasevich]

Each compiled method contains an nmethod header. In trivial case, the header takes up half the method payload: ~350 bytes. Over time, the header gets bigger. With this change, I suggest sorting the header data fields from largest to smallest to minimize header paddings, and using one byte for the CompilerType and CompLevel values.

Cleanup work: apply CompLevel type where applicable.

The change tested with jtreg tier1-3, :hotspot_compiler :hotspot_gc :hotspot_serviceability :hotspot_runtime

Renaissance benchmarks shows no performance regressions on x86 and aarch.

BEFORE:

(gdb) ptype /o CodeBlob
/* offset    |  size */  type = class CodeBlob {
/*    8      |     4 */    const CompilerType _type;    <<<<
/*   12      |     4 */    int _size;
/*   16      |     4 */    int _header_size;
/*   20      |     4 */    int _frame_complete_offset;
/*   24      |     4 */    int _data_offset;
/*   28      |     4 */    int _frame_size;
/*   32      |     8 */    address _code_begin;
/*   40      |     8 */    address _code_end;
/*   48      |     8 */    address _content_begin;
/*   56      |     8 */    address _data_end;
/*   64      |     8 */    address _relocation_begin;
/*   72      |     8 */    address _relocation_end;
/*   80      |     8 */    ImmutableOopMapSet *_oop_maps;
/*   88      |     1 */    bool _caller_must_gc_arguments;
/*   89      |     1 */    bool _is_compiled;
/* XXX  6-byte hole  */
/*   96      |     8 */    const char *_name;
/*  104      |     8 */    class AsmRemarks {
/*  104      |     8 */        AsmRemarkCollection *_remarks;
                           } _asm_remarks;
/*  112      |     8 */    class DbgStrings {
/*  112      |     8 */        DbgStringCollection *_strings;
                           } _dbg_strings;

                           /* total size (bytes):  120 */
                         }

AFTER:

(gdb) ptype /o CodeBlob
/* offset    |  size */  type = class CodeBlob {
                         protected:
/*    8      |     8 */    address _code_begin;
/*   16      |     8 */    address _code_end;
/*   24      |     8 */    address _content_begin;
/*   32      |     8 */    address _data_end;
/*   40      |     8 */    address _relocation_begin;
/*   48      |     8 */    address _relocation_end;
/*   56      |     8 */    ImmutableOopMapSet *_oop_maps;
/*   64      |     8 */    const char *_name;
/*   72      |     4 */    int _size;
/*   76      |     4 */    int _header_size;
/*   80      |     4 */    int _frame_complete_offset;
/*   84      |     4 */    int _data_offset;
/*   88      |     4 */    int _frame_size;
/*   92      |     1 */    bool _caller_must_gc_arguments;
/*   93      |     1 */    bool _is_compiled;
/*   94      |     1 */    const CompilerType _type;    <<<<
/* XXX  1-byte hole  */
/*   96      |     8 */    class AsmRemarks {
/*   96      |     8 */        AsmRemarkCollection *_remarks;
                           } _asm_remarks;
/*  104      |     8 */    class DbgStrings {
/*  104      |     8 */        DbgStringCollection *_strings;
                           } _dbg_strings;

                           /* total size (bytes):  112 */
                         }

BEFORE:

(gdb) ptype /o nmethod
/* offset    |  size */  type = class nmethod : public CompiledMethod {
                         private:
/*  208      |     4 */    int _entry_bci;
/* XXX  4-byte hole  */
/*  216      |     8 */    uint64_t _gc_epoch;
/*  224      |     8 */    nmethod *_osr_link;
/*  232      |     8 */    nmethod::oops_do_mark_link * volatile _oops_do_mark_link;
/*  240      |     8 */    address _entry_point;
/*  248      |     8 */    address _verified_entry_point;
/*  256      |     8 */    address _osr_entry_point;
/*  264      |     4 */    int _exception_offset;
/*  268      |     4 */    int _unwind_handler_offset;
/*  272      |     4 */    int _consts_offset;
/*  276      |     4 */    int _stub_offset;
/*  280      |     4 */    int _oops_offset;
/*  284      |     4 */    int _metadata_offset;
/*  288      |     4 */    int _scopes_data_offset;
/*  292      |     4 */    int _scopes_pcs_offset;
/*  296      |     4 */    int _dependencies_offset;
/*  300      |     4 */    int _handler_table_offset;
/*  304      |     4 */    int _nul_chk_table_offset;
/*  308      |     4 */    int _speculations_offset;
/*  312      |     4 */    int _jvmci_data_offset;
/*  316      |     4 */    int _nmethod_end_offset;
/*  320      |     4 */    int _orig_pc_offset;
/*  324      |     4 */    int _compile_id;
/*  328      |     4 */    int _comp_level;    <<<<
/*  332      |     1 */    bool _has_flushed_dependencies;
/*  333      |     1 */    bool _unload_reported;
/*  334      |     1 */    bool _load_reported;
/*  335      |     1 */    volatile signed char _state;
/*  336      |     1 */    bool _oops_are_stale;
/* XXX  3-byte hole  */
/*  340      |     4 */    RTMState _rtm_state;
/*  344      |     4 */    volatile jint _lock_count;
/* XXX  4-byte hole  */
/*  352      |     8 */    volatile int64_t _stack_traversal_mark;
/*  360      |     4 */    int _hotness_counter;
/*  364      |     1 */    volatile uint8_t _is_unloading_state;
/* XXX  3-byte hole  */
/*  368      |     4 */    ByteSize _native_receiver_sp_offset;
/*  372      |     4 */    ByteSize _native_basic_lock_sp_offset;

                           /* total size (bytes):  376 */
                         }						 

AFTER:

(gdb) ptype /o nmethod
/* offset    |  size */  type = class nmethod : public CompiledMethod {
/*  200      |     8 */    uint64_t _gc_epoch;
/*  208      |     8 */    volatile int64_t _stack_traversal_mark;
/*  216      |     8 */    nmethod *_osr_link;
/*  224      |     8 */    nmethod::oops_do_mark_link * volatile _oops_do_mark_link;
/*  232      |     8 */    address _entry_point;
/*  240      |     8 */    address _verified_entry_point;
/*  248      |     8 */    address _osr_entry_point;
/*  256      |     4 */    int _entry_bci;
/*  260      |     4 */    int _exception_offset;
/*  264      |     4 */    int _unwind_handler_offset;
/*  268      |     4 */    int _consts_offset;
/*  272      |     4 */    int _stub_offset;
/*  276      |     4 */    int _oops_offset;
/*  280      |     4 */    int _metadata_offset;
/*  284      |     4 */    int _scopes_data_offset;
/*  288      |     4 */    int _scopes_pcs_offset;
/*  292      |     4 */    int _dependencies_offset;
/*  296      |     4 */    int _handler_table_offset;
/*  300      |     4 */    int _nul_chk_table_offset;
/*  304      |     4 */    int _speculations_offset;
/*  308      |     4 */    int _jvmci_data_offset;
/*  312      |     4 */    int _nmethod_end_offset;
/*  316      |     4 */    int _orig_pc_offset;
/*  320      |     4 */    int _compile_id;
/*  324      |     4 */    RTMState _rtm_state;
/*  328      |     4 */    volatile jint _lock_count;
/*  332      |     4 */    int _hotness_counter;
/*  336      |     4 */    ByteSize _native_receiver_sp_offset;
/*  340      |     4 */    ByteSize _native_basic_lock_sp_offset;
/*  344      |     1 */    CompLevel _comp_level;    <<<<
/*  345      |     1 */    volatile uint8_t _is_unloading_state;
/*  346      |     1 */    bool _has_flushed_dependencies;
/*  347      |     1 */    bool _unload_reported;
/*  348      |     1 */    bool _load_reported;
/*  349      |     1 */    volatile signed char _state;
/*  350      |     1 */    bool _oops_are_stale;

                           /* total size (bytes):  352 */
                         }

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8288477: nmethod header size reduction

Reviewers

• @eastig (no known github.com user name / role) ⚠️ Review applies to 313ca2e5
• Vladimir Kozlov (@vnkozlov - Reviewer)
• Tom Rodriguez (@tkrodriguez - Reviewer) ⚠️ Review applies to 2d2a07af

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9165/head:pull/9165
$ git checkout pull/9165

Update a local copy of the PR:
$ git checkout pull/9165
$ git pull https://git.openjdk.org/jdk pull/9165/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9165

View PR using the GUI difftool:
$ git pr show -t 9165

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9165.diff

[bridgekeeper]

👋 Welcome back bulasevich! 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.

[openjdk]

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

• hotspot

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.

[eastig]

Overall, lgtm.

[eastig]

Why do we need to move it to line 626?

[bulasevich]

I put it back. Thanks.

[eastig]

Hope it won't cause gcc to generate inefficient code manupulating bytes.

[bulasevich]

AARCH and AMD have load byte instructions (ldr:ldrb, mov:movzx), I believe method::comp_level() code takes the same number of instructions before/after the change.

[dean-long]

This enum change might be hard to back-port to jdk11, which still uses an older toolchain, at least for Oracle builds.

[eastig]

lgtm

[eastig]

It would be worth to add a comment to CodeBlob saying that fields have special order to reduce its size. Otherwise someone might break the order in the future.

[mlbridge]

Webrevs

• 03: Full - Incremental (3acf5dd7)
• 02: Full - Incremental (2d2a07af)
• 01: Full - Incremental (485b7250)
• 00: Full (644be419)

[forax]

It's also a good idea to have 64 bytes in between volatiles so they are not in the same cache-line

[vnkozlov]

What about CompiledMethod?

Would be interesting to profile fields access. I assume hot fields should be in first cache line. Or it is not important?

[dean-long]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.

There is also a lot of unnecessary space used by these addresses:
address _code_begin;
address _code_end;
address _content_begin;
address _data_end;
address _relocation_begin;
address _relocation_end;

Now that AOT has been removed, we could go back to 3 int fields like in jdk8.

[dean-long]

To minimize changes in other files, how about just making this:

int8_t _comp_level;

[bulasevich]

What about CompiledMethod?

I didn't find a way to reduce the size of CompiledMethod:

(gdb) ptype /o CompiledMethod
/* offset    |  size */  type = class CompiledMethod : public CodeBlob {
                         protected:
/*  120      |     1 */    enum CompiledMethod::MarkForDeoptimizationStatus _mark_for_deoptimization_status;
/*  120:23   |     4 */    unsigned int _has_unsafe_access : 1;
/*  120:22   |     4 */    unsigned int _has_method_handle_invokes : 1;
/*  120:21   |     4 */    unsigned int _has_wide_vectors : 1;
/*  120:20   |     4 */    unsigned int _has_monitors : 1;
/* XXX  4-bit hole  */
/* XXX  6-byte hole */
/*  128      |     8 */    class Method *_method;
/*  136      |     8 */    address _scopes_data_begin;
/*  144      |     8 */    address _deopt_handler_begin;
/*  152      |     8 */    address _deopt_mh_handler_begin;
/*  160      |    32 */    class PcDescContainer {
                             private:
/*  160      |    32 */        class PcDescCache {
                                 private:
/*  160      |    32 */            volatile PcDescPtr _pc_descs[4];

                                   /* total size (bytes):   32 */
                               } _pc_desc_cache;

                               /* total size (bytes):   32 */
                           } _pc_desc_container;
/*  192      |     8 */    class ExceptionCache * volatile _exception_cache;
/*  200      |     8 */    void *_gc_data;

                           /* total size (bytes):  208 */
                         }

Would be interesting to profile fields access. I assume hot fields should be in first cache line. Or it is not important?

I don't have a heatmap of the nmethod structure. If the nmethod data is being actively accessed on a critical code path, it probably makes sense to move the hot fields together (it doesn't have to be the first cache line, I guess).

Yes, my concern was that reordering the fields as a side effect might impact performance due to a cache miss or something like that. I ran Renaissance Suite to make sure that performance is not affected.

[bulasevich]

It's also a good idea to have 64 bytes in between volatiles so they are not in the same cache-line

Actually, there is not much space in nmethod. Can you suggest a better layout?:

    /* offset | size */ type = class nmethod : public CompiledMethod {
    /*  200   |    8 */    uint64_t _gc_epoch;
>   /*  208   |    8 */    volatile int64_t _stack_traversal_mark;
    /*  216   |    8 */    nmethod *_osr_link;
>   /*  224   |    8 */    nmethod::oops_do_mark_link * volatile _oops_do_mark_link;
    /*  232   |    8 */    address _entry_point;
    /*  240   |    8 */    address _verified_entry_point;
    /*  248   |    8 */    address _osr_entry_point;
    /*  256   |    4 */    int _entry_bci;
    /*  260   |    4 */    int _exception_offset;
    /*  264   |    4 */    int _unwind_handler_offset;
    /*  268   |    4 */    int _consts_offset;
    /*  272   |    4 */    int _stub_offset;
    /*  276   |    4 */    int _oops_offset;
    /*  280   |    4 */    int _metadata_offset;
    /*  284   |    4 */    int _scopes_data_offset;
    /*  288   |    4 */    int _scopes_pcs_offset;
    /*  292   |    4 */    int _dependencies_offset;
    /*  296   |    4 */    int _handler_table_offset;
    /*  300   |    4 */    int _nul_chk_table_offset;
    /*  304   |    4 */    int _speculations_offset;
    /*  308   |    4 */    int _jvmci_data_offset;
    /*  312   |    4 */    int _nmethod_end_offset;
    /*  316   |    4 */    int _orig_pc_offset;
    /*  320   |    4 */    int _compile_id;
    /*  324   |    4 */    RTMState _rtm_state;
>   /*  328   |    4 */    volatile jint _lock_count;
    /*  332   |    4 */    int _hotness_counter;
    /*  336   |    4 */    ByteSize _native_receiver_sp_offset;
    /*  340   |    4 */    ByteSize _native_basic_lock_sp_offset;
    /*  344   |    1 */    CompLevel _comp_level;
>   /*  345   |    1 */    volatile uint8_t _is_unloading_state;
    /*  346   |    1 */    bool _has_flushed_dependencies;
    /*  347   |    1 */    bool _unload_reported;
    /*  348   |    1 */    bool _load_reported;
>   /*  349   |    1 */    volatile signed char _state;
    /*  350   |    1 */    bool _oops_are_stale;

[bulasevich]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.

Do you mind using the CompilerType? Since we have this type defined, I think it should be used.
Does it make sense to propose this int->CompilerType cleanup as a separate change prior to this one?

[dean-long]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.

Do you mind using the CompilerType? Since we have this type defined, I think it should be used. Does it make sense to propose this int->CompilerType cleanup as a separate change prior to this one?

I was going to suggest doing it as a separate change after this one.

[vnkozlov]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.

There is also a lot of unnecessary space used by these addresses: address _code_begin; address _code_end; address _content_begin; address _data_end; address _relocation_begin; address _relocation_end;

Now that AOT has been removed, we could go back to 3 int fields like in jdk8.

There is Leyden project for which we may need it.

[dean-long]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.
There is also a lot of unnecessary space used by these addresses: address _code_begin; address _code_end; address _content_begin; address _data_end; address _relocation_begin; address _relocation_end;
Now that AOT has been removed, we could go back to 3 int fields like in jdk8.

There is Leyden project for which we may need it.

OK, but the X_end pointers could probably be 32-bit size fields relative to X_start.

[vnkozlov]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.

Do you mind using the CompilerType? Since we have this type defined, I think it should be used. Does it make sense to propose this int->CompilerType cleanup as a separate change prior to this one?

I was going to suggest doing it as a separate change after this one.

I agree with Dean. Lets change int->CompLevel in separate changes. CompilerType is not the same as CompLevel.

[vnkozlov]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.
There is also a lot of unnecessary space used by these addresses: address _code_begin; address _code_end; address _content_begin; address _data_end; address _relocation_begin; address _relocation_end;
Now that AOT has been removed, we could go back to 3 int fields like in jdk8.

There is Leyden project for which we may need it.

OK, but the X_end pointers could probably be 32-bit size fields relative to X_start.

I agree with that. I was also thinking about it.

[openjdk-notifier]

@bulasevich Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See OpenJDK Developers’ Guide for more information.

[openjdk-notifier]

@bulasevich Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See OpenJDK Developers’ Guide for more information.

[bulasevich]

Most of the files changed are because of CompLevel. It feels a little disruptive. I'd rather do the minimal changes.

Do you mind using the CompilerType? Since we have this type defined, I think it should be used. Does it make sense to propose this int->CompilerType cleanup as a separate change prior to this one?

I was going to suggest doing it as a separate change after this one.

Ok. I removed the unnecessary changes. I will bring them as a separate change.

[bulasevich]

Would be interesting to profile fields access. I assume hot fields should be in first cache line.

I created JDK-8290818 for that. I do not know profile tools to grab the access statistics automatically. I think I need to patch all the nmethod getters (check if it is done from asm), and run some apps to collect the data with the patched VM. Please let me know if you know a better way.

[vnkozlov]

Would be interesting to profile fields access. I assume hot fields should be in first cache line.

I created JDK-8290818 for that. I do not know profile tools to grab the access statistics automatically. I think I need to patch all the nmethod getters (check if it is done from asm), and run some apps to collect the data with the patched VM. Please let me know if you know a better way.

@ericcaspole can you suggest how we can do that without patching VM code?

[vnkozlov]

This version looks good to me. I will test it.

[vnkozlov]

@dougxc these changes affect JVMCI. Please, review it. They need to be uploaded to Graal's JVMCI after pushed.

[tkrodriguez]

Doug is out but I took a look. The changes look fine and since Graal doesn't access nmethod::_comp_level directly we don't need to adjust to these changes.

[tkrodriguez]

You should declare CompLevel in this file as well. I think it might be missing the sanity checking that detect missing type declarations.

[bulasevich]

Hmm. Actually most of the types used in vmStructs_jvmci.cpp are not declared in VM_TYPES:

• int, intptr_t, jbyte, jint, jlong, juint, u1, u2, u4, uint, uint64_t, uintptr_t, unsigned int, void*
• AccessFlags, Annotations*, ClassLoaderData*, CollectedHeap*, CompiledMethod*, ConstMethod*,
• JavaFrameAnchor, JavaThread*, MethodCounters*, MethodData*, ObjectWaiter*, OopHandle, OSThread*, Thread*

is it an issue?

[tkrodriguez]

You're right, it's fine to leave it out. Vladimir had added some sanity checks to the JVMCI vmStructs in https://bugs.openjdk.org/browse/JDK-8237497 and I'd assumed it was all of the checks that the regular vmStructs does but it's not. The regular VMStructs requires that all reachable types are fully described but JVMCI actually doesn't use the VMTypeEntry/declare_toplevel_type stuff at all. It's not exposed API so it should be dropped I think. A debug build will catch the field type mismatches at compile time which is the primary thing we care about, though I think that should enabled in all builds instead of being debug only. The required checks should fold away or produce a compile time error. You can see that jvmci_vmStructs_init compiles into an empty method in the fastdebug build. Anyway, I filed https://bugs.openjdk.org/browse/JDK-8291513 to remove those declarations completely.

[openjdk]

@bulasevich 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:

8288477: nmethod header size reduction

Reviewed-by: kvn, never

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 288 new commits pushed to the master branch:

• 54a2c5a: 8290059: Do not use std::thread in panama tests
• 5214a17: 8291479: ProblemList compiler/rangechecks/TestRangeCheckHoistingScaledIV.java on ppc64le
• 471a427: 8287794: Reverse*VNode::Identity problem
• 5d1ad39: 8290839: jdk/jfr/event/compiler/TestJitRestart.java failed with "RuntimeException: No JIT restart event found: expected true, was false"
• 97fc8de: 8291106: ZPlatformGranuleSizeShift is redundant
• dd69a68: 8291000: C2: Purge LoadPLocked and Store*Conditional nodes
• 07f0612: 8290532: Adjust PKCS11Exception and handle more PKCS11 error codes
• 93f96d8: 8290399: [macos] Aqua LAF does not fire an action event if combo box menu is displayed
• 5d82d67: 8290034: Auto vectorize reverse bit operations.
• 348a052: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options
• ... and 278 more: https://git.openjdk.org/jdk/compare/569de453c3267089d04befd756b81470693cf2de...master

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.

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

[tkrodriguez]

Why not be more aggressive about using offsets instead of explicit addresses? Why store both _begin and _end fields? The end of one section is usually the beginning of the another section. These explicit fields aren't very nice either. Why not use an enum with arrays for the various values? Then this stuff can all be written in a consistent pattern using offsets and getting the end of a section using the beginning of the next section. Section alignments could also be declared in a consistent way using the enum.

You could probably smush _is_compiled, _caller_must_gc_arguments, _type and _header_size into a bitfield. Certainly _header_size doesn't need to be a full int since sizeof(nmethod) is only around 400 bytes.

[eastig]

@tkrodriguez,

Why not be more aggressive about using offsets instead of explicit addresses? Why store both _begin and _end fields?

Using offset will make impossible to separate non-code data from nmethod. We are working on prototypes to separate non-code data to improve code density in CodeCache.

[tkrodriguez]

That's good to hear. I've always thought that would be a good idea. It seems like you'd still be able to separate it into two chunks and use offsets within those.

[mlbridge]

Mailing list message from John Rose on hotspot-dev:

I wish we had a more systematic way to handle packed structs with many variable-sized segments. It?s a problem in metadata as well. If there were something (with enums? offset arrays? iterators? bitmaps for conditional elements? all of the above?) that could handle such structs, that would be the place to put all of our heroics, rather than one place at at time, as with nmethods in this case.

On 21 Jul 2022, at 16:40, Tom Rodriguez wrote:

[bulasevich]

Thank you all!

/integrate

[openjdk]

Going to push as commit e052d7f.
Since your change was applied there have been 288 commits pushed to the master branch:

• 54a2c5a: 8290059: Do not use std::thread in panama tests
• 5214a17: 8291479: ProblemList compiler/rangechecks/TestRangeCheckHoistingScaledIV.java on ppc64le
• 471a427: 8287794: Reverse*VNode::Identity problem
• 5d1ad39: 8290839: jdk/jfr/event/compiler/TestJitRestart.java failed with "RuntimeException: No JIT restart event found: expected true, was false"
• 97fc8de: 8291106: ZPlatformGranuleSizeShift is redundant
• dd69a68: 8291000: C2: Purge LoadPLocked and Store*Conditional nodes
• 07f0612: 8290532: Adjust PKCS11Exception and handle more PKCS11 error codes
• 93f96d8: 8290399: [macos] Aqua LAF does not fire an action event if combo box menu is displayed
• 5d82d67: 8290034: Auto vectorize reverse bit operations.
• 348a052: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options
• ... and 278 more: https://git.openjdk.org/jdk/compare/569de453c3267089d04befd756b81470693cf2de...master

Your commit was automatically rebased without conflicts.

[openjdk]

@bulasevich Pushed as commit e052d7f.

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