On Wed, 29 May 2024 05:19:28 GMT, Chen Liang wrote:
>> I propose to add type-checked ConstantPool.entryByIndex and
>> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
>> ConstantPoolException instead of ClassCastException on type mismatch, which
>> can happen to malfor
> I propose to add type-checked ConstantPool.entryByIndex and
> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
> ConstantPoolException instead of ClassCastException on type mismatch, which
> can happen to malformed ClassFiles.
>
> Requesting a review from @asotona. Th
On Tue, 28 May 2024 16:56:18 GMT, Naoto Sato wrote:
>> This test intends to verify the behavior of JdkConsole for the java.base
>> module, wrt restoring the echo. The test assumes the internal methods that
>> sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request
> Get JDK 24 underway.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 16 commits:
- Correct release year.
- Merge branch 'master' into JDK-8330188
- Add symbol files current with JDK 23 build 24.
- Merge branch 'master'
On Fri, 24 May 2024 16:41:33 GMT, Adam Sotona wrote:
>> j.l.classfile.ClassReader instance is exposed in the Class-File API through
>> j.l.classfile.AttributeMapper::readAttribute method only.
>> ClassReader only purpose is to serve as a tool for reading content of a
>> custom attribute in a us
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made t
On Tue, 28 May 2024 22:20:39 GMT, Pavel Rappo wrote:
>> I believe, it should be `1`. Hear me out. In this method, the `length` is
>> scaled down, whereas in `StringUTF16` it is not. In this method, it's
>> `length`, in `StringUTF16` it's `((byte[]) value).length`.
>
> In fact, if I change it to
On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 28 May 2024 20:26:40 GMT, Naoto Sato wrote:
>> As a non-standard comment, it will trigger a warning (and hence an error),
>> since the prevailing standard for `java.base` is to compile with all
>> warnings enabled (`-Xlint`) and no warnings found (verified by `-Werror`)
>>
>> The alter
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
On Thu, 16 May 2024 18:09:04 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 418:
>>
>>> 416: __ cmpq(haystack_len, 0x10);
>>> 417: __ ja_b(L_moreThan16);
>>> 418:
>>
>> An assert here to check for header size >= 16 would be good.
>> Also a co
On Tue, 28 May 2024 21:17:07 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:
>>
>>> 486: __ cmpq(r11, nMinusK);
>>> 487: __ ja_b(L_return);
>>> 488: __ movq(rax, r11);
>>
>> At places where we know that return value in r11 is correct, we dont
> With the advent of JEP 467, `///` comments may be treated as documentation
> comments, and may be subject to the recently new `javac` warning about
> "dangling doc comments" in unexpected places.
>
> In keeping with the policy to keep the `java.base` module free of all `javac`
> warnings, thi
On Tue, 28 May 2024 22:08:06 GMT, Pavel Rappo wrote:
>> Yes, should be `2` (`a` is semantically a `char[]`). This typo likely pass
>> functional testing since `1` can never happen in practice, and the default
>> case should work for any value. There might be a String microbenchmark out
>> ther
On Tue, 28 May 2024 20:38:21 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 301:
>>
>>> 299: return switch (length) {
>>> 300: case 0 -> initialValue;
>>> 301: case 1 -> 31 * initialValue + JLA.getUTF16Char(a,
On Tue, 28 May 2024 20:13:24 GMT, Alexey Semenyuk wrote:
> Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to
> the test descriptor
This pull request has now been integrated.
Changeset: 91ab088d
Author:Alexey Semenyuk
URL:
https://git.openjdk.org/jdk/commit
On Tue, 28 May 2024 20:13:24 GMT, Alexey Semenyuk wrote:
> Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to
> the test descriptor
Looks good.
-
Marked as reviewed by almatvee (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19436#pullrequestrevie
On Fri, 24 May 2024 01:08:03 GMT, Alexander Matveev
wrote:
> This issue is reproducible with and without `--mac-sign`. jpackage will
> "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by
> using pseudo-identity "_-_". This is why jpackage tries to sign added files
> and t
On Tue, 28 May 2024 16:37:23 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix tests
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:
>
>> 486: __ cmpq(r11, nMinu
On Fri, 24 May 2024 20:42:12 GMT, Scott Gibbons wrote:
>> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 185:
>>
>>> 183: }
>>> 184:
>>> 185: private static int indexOfKernel(String haystack, String needle) {
>>
>> Is the intention of kernels not to be inlined so that it would be p
On Tue, 28 May 2024 16:57:54 GMT, Vladimir Kozlov wrote:
>> @vnkozlov I'm getting an error in CI tests with this line added. Can you
>> please advise?
>>
>> `TEST RESULT: Error. Parse Exception: Syntax error in @requires expression:
>> invalid name: vm.cpu.features`
>
> You need to add `vm.cp
On Tue, 28 May 2024 20:56:42 GMT, Scott Gibbons wrote:
>> We can also do full reads for (n-k) == 31, as we also compare the kth byte.
>
> I'll change and test.
Passes tests, so I'll change.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1617886613
On Tue, 28 May 2024 20:37:43 GMT, Sandhya Viswanathan
wrote:
>> I listed all registers for clarity. This ensures that we know what can be
>> used as values or as scratch registers with no ambiguity.
>
> Sounds good. We could keep only comment out of the two as it is the same for
> both small
On Tue, 28 May 2024 17:36:03 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 488:
>>
>>> 486: __ cmpq(r11, nMinusK);
>>> 487: __ ja_b(L_return);
>>> 488: __ movq(rax, r11);
>>
>> At places where we know that return value in r11 is correct, we dont
On Tue, 28 May 2024 20:13:24 GMT, Alexey Semenyuk wrote:
> Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to
> the test descriptor
@sashamatveev please review
-
PR Comment: https://git.openjdk.org/jdk/pull/19436#issuecomment-2136094953
On Tue, 28 May 2024 20:35:26 GMT, Sandhya Viswanathan
wrote:
>> No. For (n-k)==32 we can do full reads. I'll clarify by changing the label
>> name.
>
> We can also do full reads for (n-k) == 31, as we also compare the kth byte.
I'll change and test.
-
PR Review Comment: https://
On Tue, 28 May 2024 20:29:38 GMT, Sandhya Viswanathan
wrote:
>> No. This is checking for a zero length haystack. The following compare
>> checks for needle length longer than haystack, regardless of the value in
>> each. The comparison is signed, so a haystack length of 0 with a needle
>>
On Tue, 28 May 2024 19:13:30 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
>
On Tue, 28 May 2024 18:11:13 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1333:
>>
>>> 1331:
>>> 1332: __ cmpq(nMinusK, 32);
>>> 1333: __ jae_b(L_greaterThan32);
>>
>> Should this check be (n-k+1) >= 32? And so accordingly (n-k) >= 31
>> __ cmpq
On Tue, 28 May 2024 20:22:24 GMT, Jonathan Gibbons wrote:
> What about changing `///` to `//---` to give slightly more prominence to
> these comments, over plain old `//` comments. The dashes give a small sense
> of a horizontal rule, to delimit sections of code.
>
> (FWIW, I have locally edit
On Tue, 28 May 2024 17:30:24 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 278:
>>
>>> 276: __ bind(L_nextCheck);
>>> 277: __ testq(haystack_len_p, haystack_len_p);
>>> 278: __ je(L_zeroCheckFailed);
>>
>> This check could be removed as the next
On Tue, 28 May 2024 18:50:38 GMT, Jonathan Gibbons wrote:
>> src/java.base/share/classes/jdk/internal/icu/impl/StringPrepDataReader.java
>> line 122:
>>
>>> 120: * see store.c of gennorm for more information and values
>>> 121: */
>>> 122: // /* dataFormat="SPRP" 0x53, 0x50, 0x52,
On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons wrote:
> With the advent of JEP 467, `///` comments may be treated as documentation
> comments, and may be subject to the recently new `javac` warning about
> "dangling doc comments" in unexpected places.
>
> In keeping with the policy to keep
On Tue, 28 May 2024 17:59:49 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 578:
>>
>>> 576: // helper jumps to L_checkRangeAndReturn with a (-1) return value.
>>> 577: big_case_loop_helper(false, 0, L_checkRangeAndReturn, L_loopTop,
>>> mask, h
On Tue, 28 May 2024 20:01:46 GMT, Alan Bateman wrote:
> > OK. I was just trying to honor the apparent intent to make the comment
> > stand out more than just a plain `//` comment, but I have no strong
> > feelings against reducing `///` to `//`
>
> In this case I would reduce it to '//' but ot
On Tue, 28 May 2024 19:19:51 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
>
>>
Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to the
test descriptor
-
Commit messages:
- Add missing "--add-opens jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED" to
test desc. It fixes the following error:
Changes: https://git.openjdk.org/jdk/pull/19436
On Tue, 28 May 2024 18:57:07 GMT, Jonathan Gibbons wrote:
> OK. I was just trying to honor the apparent intent to make the comment stand
> out more than just a plain `//` comment, but I have no strong feelings
> against reducing `///` to `//`
In this case I would reduce it to '//' but others w
On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr wrote:
> Fix obvious typo in micro benchmark.
This pull request has now been integrated.
Changeset: 9ac8d05a
Author:Martin Doerr
URL:
https://git.openjdk.org/jdk/commit/9ac8d05a2567fbf65b944660739e5f8ad1fc2020
Stats: 8 lines in 1 fi
On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr wrote:
> Fix obvious typo in micro benchmark.
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/19427#issuecomment-2136008570
On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang wrote:
> Add two sample configuration files:
>
> jaxp-strict.properties: used to set strict configuration, stricter than
> jaxp.properties in previous versions such as JDK 22
>
>> jaxp-compat.properties: used to regain compatibility from any more
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made t
On Thu, 23 May 2024 05:52:57 GMT, Alan Bateman wrote:
> > A long vertical series of lines beginning /// is replaced by lines
> > beginning //|.
>
> This one looks unusual when it's just one line, I could imagine deleting the
> "|" in these cases.
OK. I was just trying to honor the apparent in
On Wed, 22 May 2024 20:13:08 GMT, Naoto Sato wrote:
>> With the advent of JEP 467, `///` comments may be treated as documentation
>> comments, and may be subject to the recently new `javac` warning about
>> "dangling doc comments" in unexpected places.
>>
>> In keeping with the policy to keep
On Tue, 28 May 2024 12:48:19 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix tests
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 239:
>
>> 237: // the needle siz
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
On Tue, 28 May 2024 16:00:10 GMT, Scott Gibbons wrote:
>> test/jdk/java/lang/StringBuffer/IndexOf.java line 28:
>>
>>> 26: * @summary Test indexOf and lastIndexOf
>>> 27: * @run main/othervm IndexOf
>>> 28: * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp
>>> -XX:-TieredCompilatio
> This test intends to verify the behavior of JdkConsole for the java.base
> module, wrt restoring the echo. The test assumes the internal methods that
> sets/gets the echo status of the platform.
Naoto Sato has updated the pull request with a new target base due to a merge
or a rebase. The pul
On Tue, 28 May 2024 16:27:24 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Sat, 25 May 2024 22:19:41 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Fri, 24 May 2024 16:36:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
> Add two sample configuration files:
>
> jaxp-strict.properties: used to set strict configuration, stricter than
> jaxp.properties in previous versions such as JDK 22
>
>> jaxp-compat.properties: used to regain compatibility from any more
>> restricted configuration than previous versions
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
On Sat, 25 May 2024 06:33:51 GMT, Alan Bateman wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix test; review comments
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 47:
>
>> 45: public class IndexOf {
>
On Fri, 24 May 2024 16:36:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Fri, 24 May 2024 20:12:07 GMT, Vladimir Kozlov wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test clarifications
>
> test/jdk/java/lang/StringBuffer/IndexOf.java line 28:
>
>> 26: * @summary Test indexOf an
On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr wrote:
> Fix obvious typo in micro benchmark.
Good.
-
Marked as reviewed by kvn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19427#pullrequestreview-2083281226
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically c
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically c
On Tue, 28 May 2024 15:11:39 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> removed obsolete entry
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 676:
>
>> 674:
On Tue, 28 May 2024 14:56:35 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>> regress
On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been removed. A deprecated me
On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr wrote:
> Fix obvious typo in micro benchmark.
Thanks for the review!
-
PR Comment: https://git.openjdk.org/jdk/pull/19427#issuecomment-2135446758
On Tue, 28 May 2024 14:01:44 GMT, Martin Doerr wrote:
> Fix obvious typo in micro benchmark.
Looks good and trivial!
-
Marked as reviewed by chagedorn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19427#pullrequestreview-2083086912
On Fri, 24 May 2024 16:36:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically c
Fix obvious typo in micro benchmark.
-
Commit messages:
- 8332228: TypePollution.java: Unrecognized VM option 'UseSecondarySuperCache'
Changes: https://git.openjdk.org/jdk/pull/19427/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19427&range=00
Issue: https://bugs.openjd
On Tue, 28 May 2024 11:55:30 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>> regress
On Tue, 28 May 2024 12:27:46 GMT, Erik Gahlin wrote:
>> Hi,
>>
>> Could I have a review of a change that moves the jdk.FileRead and
>> jdk.FileWrite events to java.base to remove the use of the ASM
>> instrumentation.
>>
>> Testing: jdk/jdk/jfr
>>
>> Thanks
>> Erik
>
> Erik Gahlin has update
On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>> `hotspot/
On Tue, 28 May 2024 11:55:30 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>> regress
On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>> `hotspot/
On Fri, 24 May 2024 15:45:07 GMT, Erik Gahlin wrote:
>> Collapsing the extra layer of methods and combining the test into
>>
>> if (jfrTracing && FileReadEvent.enabled())
>>
>> would indeed keep things a little neater.
>>
>> I'm still questioning the need for `jfrTracing` at all. There's t
On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote:
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
This pull request has now been integrated.
Changeset: e708d135
Author:Alan Bateman
URL:
https
On Fri, 24 May 2024 16:41:33 GMT, Adam Sotona wrote:
>> j.l.classfile.ClassReader instance is exposed in the Class-File API through
>> j.l.classfile.AttributeMapper::readAttribute method only.
>> ClassReader only purpose is to serve as a tool for reading content of a
>> custom attribute in a us
On Mon, 20 May 2024 08:03:28 GMT, Adam Sotona wrote:
> Class-File API `ClassRemapper` component suppose to remap all classes
> referenced in a class file.
> Actual implementation missed remapping of bootstrap methods referenced from
> `invokedynamic` instructions.
> This patch fixes the remappi
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally with one additional
commit since t
On Mon, 20 May 2024 08:03:28 GMT, Adam Sotona wrote:
> Class-File API `ClassRemapper` component suppose to remap all classes
> referenced in a class file.
> Actual implementation missed remapping of bootstrap methods referenced from
> `invokedynamic` instructions.
> This patch fixes the remappi
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically c
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically c
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically c
On Fri, 24 May 2024 17:57:28 GMT, Oussama Louati wrote:
>> test/jdk/java/lang/invoke/indify/Indify.java line 660:
>>
>>> 658: *
>>> 659: * @return true if any marks were changed, false otherwise.
>>> 660: */
>>
>> This method does incremental analysis of the constant
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally with one additional
commit since t
> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code
> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle,
> MethodType, and CallSite constants.
> It currently uses ad-hoc code to process class files and intends to migrate
> to ASM; but since we ha
85 matches
Mail list logo
