On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Thu, 19 Jun 2025 10:02:45 GMT, Aleksey Shipilev wrote:
>> Thank you for the backport! @shipilev indicated that the backport to 21
>> should wait a bit, could you clarify when should I file that (e.g. end of
>> July, ...)?
>
>> @shipilev indicated that the backport to 21 should wait a bit, co
On Thu, 19 Jun 2025 10:02:45 GMT, Aleksey Shipilev wrote:
>> Thank you for the backport! @shipilev indicated that the backport to 21
>> should wait a bit, could you clarify when should I file that (e.g. end of
>> July, ...)?
>
>> @shipilev indicated that the backport to 21 should wait a bit, co
On Wed, 18 Jun 2025 15:42:14 GMT, Radim Vansa wrote:
> @shipilev indicated that the backport to 21 should wait a bit, could you
> clarify when should I file that (e.g. end of July, ...)?
I would say for the fairly big change like this, we want to wait until JDK 25
GA (that would pass the all-t
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
Hi all,
This pull request contains a backport of commit
[e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was
revi
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Wed, 11 Jun 2025 16:35:01 GMT, Radim Vansa wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Copyright update
>
> Thank you! I'll mark this for integration and I would appreciate if I can get
> your sponsorship.
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Wed, 11 Jun 2025 17:15:33 GMT, Coleen Phillimore wrote:
> I've been testing this against mainline source base -with just this change
> patched in and it seems fine. I don't know if it's worth merging. Also if you
> do merge it do 'git merge' not 'git rebase' I'm rerunning tier1-7 now.
@rvan
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Wed, 11 Jun 2025 16:35:01 GMT, Radim Vansa wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Copyright update
>
> Thank you! I'll mark this for integration and I would appreciate if I can get
> your sponsorship.
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
On Tue, 10 Jun 2025 09:30:31 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
On Tue, 10 Jun 2025 12:49:55 GMT, Johan Sjölen wrote:
>> @coleenp Can't find the comment to reply... I've replaced all
>> `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.
>
> Hi @rvansa ,
>
> What about this type of API for dealing with the compressed table? We do the
> 8 by
On Tue, 10 Jun 2025 15:15:34 GMT, Radim Vansa wrote:
>> I think you misunderstand me, as what I'm proposing wouldn't requre creating
>> an array in `create_search_table`.
>>
>> I'm saying that you do this:
>>
>> ```c++
>> // Note: we require the supplier to provide the elements in the final or
On Tue, 10 Jun 2025 14:30:06 GMT, Johan Sjölen wrote:
>> But then you'd need create an array of `Pair` in `create_search_table` and
>> copy the data into that. You wouldn't need a Supplier at all, just pass the
>> array and its length to the `fill` method. If you are worried about the
>> virtu
On Tue, 10 Jun 2025 13:45:52 GMT, Radim Vansa wrote:
>> This was done this way with a "Supplier" because this package would be
>> useful for other Unsigned5 packed types.
>
> But then you'd need create an array of `Pair` in `create_search_table` and
> copy the data into that. You wouldn't need
On Tue, 10 Jun 2025 13:02:15 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/utilities/packedTable.hpp line 56:
>>
>>> 54: // Packed table does NOT support duplicate keys.
>>> 55: virtual bool next(uint32_t* key, uint32_t* value) = 0;
>>> 56: };
>>
>> Does it make sense to take the
On Tue, 10 Jun 2025 12:49:55 GMT, Johan Sjölen wrote:
>> @coleenp Can't find the comment to reply... I've replaced all
>> `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.
>
> Hi @rvansa ,
>
> What about this type of API for dealing with the compressed table? We do the
> 8 by
On Tue, 10 Jun 2025 08:44:05 GMT, Johan Sjölen wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert removing FieldInfoReader::next_uint()
>
> src/hotspot/share/utilities/packedTable.hpp line 56:
>
>> 54: // P
On Tue, 10 Jun 2025 12:49:55 GMT, Johan Sjölen wrote:
>> @coleenp Can't find the comment to reply... I've replaced all
>> `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.
>
> Hi @rvansa ,
>
> What about this type of API for dealing with the compressed table? We do the
> 8 by
On Mon, 9 Jun 2025 15:36:14 GMT, Radim Vansa wrote:
>> To integrate hotspot changes, you need two reviewers and people 'requesting
>> changes' to withdraw their requests. Thank goodness the bots prevented this
>> from being integrated. You need to wait for all the comments to be resolved.
>>
On Tue, 10 Jun 2025 09:05:00 GMT, Johan Sjölen wrote:
>> src/hotspot/share/utilities/packedTable.hpp line 69:
>>
>>> 67: // by the supplier (when Supplier::next() returns false the whole
>>> array should
>>> 68: // be filled).
>>> 69: void fill(u1* table, size_t table_length, Supplier &su
On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Tue, 10 Jun 2025 10:14:21 GMT, Johan Sjölen wrote:
>> What's wrong about `memcpy`, or rather the builtin version? Naturally I
>> could write a for cycle copying the bytes, and rely on the compiler to
>> optimize that out anyway, but I think that this makes the intention clear.
>>
>> If the
On Tue, 10 Jun 2025 08:34:49 GMT, Johan Sjölen wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert removing FieldInfoReader::next_uint()
>
> src/hotspot/share/utilities/packedTable.hpp line 69:
>
>> 67: // by
On Mon, 9 Jun 2025 13:50:54 GMT, Radim Vansa wrote:
>What's wrong about memcpy, or rather the builtin version?
Doesn't regular `memcpy` compile into the builtin anyway? Aren't there LE/BE
concerns when you do this type of computation?
-
PR Review Comment: https://git.openjdk.org/j
On Tue, 10 Jun 2025 09:30:31 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>>
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
On Mon, 9 Jun 2025 21:42:03 GMT, Ioi Lam wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert removing FieldInfoReader::next_uint()
>
> src/hotspot/share/utilities/packedTable.cpp line 83:
>
>> 81: assert((elem
On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Mon, 9 Jun 2025 14:45:53 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/utilities/packedTable.cpp line 64:
>>
>>> 62: assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x
>>> (%x)", value, _value_mask, ~_value_mask);
>>> 63: uint64_t element = static_cast(key) |
>
On Mon, 9 Jun 2025 14:45:24 GMT, Coleen Phillimore wrote:
>> Well, now I am surprised :-). Thank you for looking that up, I've probably
>> misunderstood the style and applied my own advice incorrectly. Sorry about
>> the conflicting review comments.
>
> This typedef didn't really bother me beca
On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Fri, 6 Jun 2025 11:01:34 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add more comments
>> - Disable search table with dynamic CDS
>
> To integrate hotspot changes, you need two revie
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
On Mon, 9 Jun 2025 14:38:47 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix coding style
>
> src/hotspot/share/utilities/packedTable.cpp line 64:
>
>> 62: assert((value & ~_value_mask
On Mon, 9 Jun 2025 14:32:52 GMT, Johan Sjölen wrote:
>> From https://wiki.openjdk.org/display/HotSpot/StyleGuide :
>>> [#Names](https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names)
>>> Instance variable names start with underscore "_", classes start with
>>> upper case letter,
On Mon, 9 Jun 2025 14:14:00 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Mon, 9 Jun 2025 13:53:26 GMT, Radim Vansa wrote:
>> Now I am confused; @iklam just requested to use the underscores.
>
> From https://wiki.openjdk.org/display/HotSpot/StyleGuide :
>> [#Names](https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names)
>> Instance variable names star
On Mon, 9 Jun 2025 06:40:48 GMT, Radim Vansa wrote:
>> The addition of read_name_and_signature() is a good level of abstraction.
>
> We must have some misunderstanding. This is not `FieldInfoStream`, this is
> `FieldInfoReader::read_field_info`, therefore I don't see any issue accessing
> priva
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
On Mon, 9 Jun 2025 12:16:38 GMT, Coleen Phillimore wrote:
>> From what I could find, strict alignment checking must be explicitly enabled
>> an aarch64. x86_64 does not require alignment either. In both cases, there
>> might be a performance penalty.
>
> Once I turned on hard signals for these
On Mon, 9 Jun 2025 13:41:01 GMT, Radim Vansa wrote:
>> src/hotspot/share/oops/fieldInfo.cpp line 132:
>>
>>> 130: // We use both name and signature during the comparison; while JLS
>>> require unique
>>> 131: // names for fields, JVMS requires only unique name + signature
>>> combination.
>>>
On Mon, 9 Jun 2025 13:23:40 GMT, Johan Sjölen wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Print debugging info for InstanceKlass
>
> src/hotspot/share/oops/fieldInfo.cpp line 132:
>
>> 130: // We use both name
On Mon, 9 Jun 2025 11:33:00 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Mon, 9 Jun 2025 11:33:00 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Mon, 9 Jun 2025 06:52:41 GMT, Radim Vansa wrote:
>> src/hotspot/share/utilities/packedTable.cpp line 49:
>>
>>> 47: assert((key & ~_key_mask) == 0, "key out of bounds");
>>> 48: assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x
>>> (%x)", value, _value_mask, ~_value
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
On Fri, 6 Jun 2025 16:13:11 GMT, Ioi Lam wrote:
> While the benefit can be seen in a synthetic benchmark, do we have any data
> that shows a benefit in real world applications?
@iklam Regrettably I cannot disclose the reproducer that came from a customer,
but it is not synthetic - it caused p
On Fri, 6 Jun 2025 19:22:10 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add more comments
>> - Disable search table with dynamic CDS
>
> src/hotspot/share/utilities/packedTable.cpp line
On Fri, 6 Jun 2025 19:04:40 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add more comments
>> - Disable search table with dynamic CDS
>
> src/hotspot/share/utilities/packedTable.cpp line
On Fri, 6 Jun 2025 15:46:31 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/fieldInfo.inline.hpp line 126:
>>
>>> 124: fi._offset = _r.next_uint();
>>> 125: fi._access_flags = AccessFlags(checked_cast(_r.next_uint()));
>>> 126: fi._field_flags = FieldInfo::FieldFlags(_r.next_uint()
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Fri, 6 Jun 2025 16:41:25 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add more comments
>> - Disable search table with dynamic CDS
>
> test/hotspot/jtreg/runtime/FieldStream/LocalFiel
On Thu, 5 Jun 2025 20:37:22 GMT, Coleen Phillimore wrote:
>> Yes, in practice these all are of the same size, but in case of the masks
>> (as well as in case of arguments in API) I want to stress out that these are
>> 32 bit numbers. The `unsigned int`s are just 'some not too big number'.
>> Is
On Fri, 6 Jun 2025 15:44:28 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add more comments
>> - Disable search table with dynamic CDS
>
> src/hotspot/share/oops/fieldInfo.inline.hpp line
On Thu, 5 Jun 2025 21:06:44 GMT, Radim Vansa wrote:
>> src/hotspot/share/oops/fieldInfo.hpp line 238:
>>
>>> 236:
>>> 237: private:
>>> 238: uint32_t next_uint() { return _r.next_uint(); }
>>
>> Why did you make this change and have the callers expose _r ?
>
> AFAIU `_r` is not exposed, it
On Thu, 5 Jun 2025 20:52:10 GMT, Radim Vansa wrote:
>> src/hotspot/share/oops/fieldInfo.cpp line 164:
>>
>>> 162: r.read_field_counts(&java_fields, &injected_fields);
>>> 163: assert(java_fields >= 0, "must be");
>>> 164: if (java_fields == 0 || fis->length() == 0 ||
>>> static_cast(java_
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Wed, 21 May 2025 15:00:07 GMT, Chris Plummer wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo
>
> It looks like you removed the SA changes, so I'm not so sure you still need a
> review from me. I just as
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Wed, 21 May 2025 15:00:07 GMT, Chris Plummer wrote:
>> Radim Vansa has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typo
>
> It looks like you removed the SA changes, so I'm not so sure you still need a
> review from me. I just as
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Thu, 5 Jun 2025 23:11:21 GMT, Ioi Lam wrote:
>> I have written a POC that shows that the table must be sorted again when
>> dumping a dynamic CDS archive. See
>> https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f
>>
>> Explanations are in
>> [here](https://github.
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
On Thu, 5 Jun 2025 05:17:48 GMT, Ioi Lam wrote:
>> Radim Vansa has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Moved jtreg test
>> - Improved documentation
>> - Fix coding style (asterisk placement)
>
> I have written a POC that sh
On Thu, 5 Jun 2025 05:17:48 GMT, Ioi Lam wrote:
>> Radim Vansa has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Moved jtreg test
>> - Improved documentation
>> - Fix coding style (asterisk placement)
>
> I have written a POC that sh
On Thu, 5 Jun 2025 21:32:50 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Thu, 5 Jun 2025 18:04:00 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Moved jtreg test
>> - Improved documentation
>> - Fix coding style (asterisk placement)
>
> src/hotspot/share/
> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
> trying to reduce the performance regression in some scenarios introduced in
> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
> memory consumption it is a (better) alternative to
> https
On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Thu, 5 Jun 2025 20:28:13 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Moved jtreg test
>> - Improved documentation
>> - Fix coding style (asterisk placement)
>
> src/hotspot/share/
On Thu, 5 Jun 2025 19:02:49 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Moved jtreg test
>> - Improved documentation
>> - Fix coding style (asterisk placement)
>
> src/hotspot/share/
On Thu, 5 Jun 2025 18:54:07 GMT, Coleen Phillimore wrote:
>> Radim Vansa has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Moved jtreg test
>> - Improved documentation
>> - Fix coding style (asterisk placement)
>
> src/hotspot/share/
On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Tue, 3 Jun 2025 05:51:38 GMT, Radim Vansa wrote:
>> Can you explain somewhere how fields are mapped to this? I assume they're
>> sorted, for some reason I expected the packed table to be {name-cp-index,
>> sig-cp-index, offset-in-fieldstream-for-direct-access}. Does every field
>> get 4 i
On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
On Fri, 30 May 2025 21:14:53 GMT, John R Rose wrote:
>> Radim Vansa has refreshed the contents of this pull request, and previous
>> commits have been removed. Incremental views are not available.
>
>> I like the idea of mapping each element in the table as raw bits, though
>> handling of acces
On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa wrote:
>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290
>> trying to reduce the performance regression in some scenarios introduced in
>> https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and
>> m
1 - 100 of 192 matches
Mail list logo
