On Fri, 4 Jun 2021 14:10:20 GMT, Matthias Baesken wrote:
>> Hello, please review this small Sonar finding.
>> Sonar reports a potential NULL pointer dereference here :
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&typ
> …d on macOS
>
> This patch simply round up the specified stack size to multiple of the system
> page size.
>
> Test is trivial, simply run java with -Xss option against following code. On
> MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get
> `7183` and `649` respective
On Sat, 5 Jun 2021 00:15:25 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the implemen
On Fri, 4 Jun 2021 23:41:06 GMT, Dan Smith wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 312:
>>
>>> 310: * @return a CallSite whose target can be used to perform capture,
>>> generating
>>> 311: * instances of the interface named by {@code
> …d on macOS
>
> This patch simply round up the specified stack size to multiple of the system
> page size.
>
> Test is trivial, simply run java with -Xss option against following code. On
> MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get
> `7183` and `649` respective
> Standardizes and better specifies the errors thrown by LambdaMetafactory,
> including for inputs that would not be generated by javac.
>
> Does some renaming of core parameters/fields to better reflect their purpose.
>
> In the implementation, stops using ACC_BRIDGE for any methods, which is n
On Fri, 4 Jun 2021 22:09:39 GMT, Mandy Chung wrote:
> Can you also rename the parameter names in
> `java.lang.invoke.LambdaProxyClassArchive` methods to match the new ones?
Hmm, that expands the reach of the patch a bit—into native HotSpot code—but
I've given it a try. Let me know if it looks
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote:
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on the
On Fri, 4 Jun 2021 22:06:49 GMT, Mandy Chung wrote:
>> Dan Smith has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address reviewer comments
>
> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 312:
>
>> 310:
On Fri, 4 Jun 2021 22:04:19 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the implemen
On Fri, 4 Jun 2021 06:16:45 GMT, Peter Levart wrote:
>> Dan Smith has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix accidentally commented-out parts of test
>
> src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetaf
> Standardizes and better specifies the errors thrown by LambdaMetafactory,
> including for inputs that would not be generated by javac.
>
> Does some renaming of core parameters/fields to better reflect their purpose.
>
> In the implementation, stops using ACC_BRIDGE for any methods, which is n
On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov
wrote:
> I got rid of `realpath` usage as discussed in
> https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro
> instead, however there were quite a few problems with this macro, here's the
> example:
>
> $(call RelativePath,/
On Fri, 4 Jun 2021 01:22:05 GMT, liach
wrote:
>> Dan Smith has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix accidentally commented-out parts of test
>
> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 547:
>
On Fri, 4 Jun 2021 00:08:41 GMT, Mandy Chung wrote:
>> Dan Smith has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix accidentally commented-out parts of test
>
> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 45
I got rid of `realpath` usage as discussed in
https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro instead,
however there were quite a few problems with this macro, here's the example:
$(call RelativePath,/foo/bar,/foo/bar/baz) -> "..//foo/bar"
$(call RelativePath,/foo/bar/
Hi Mandy,
the OOME thrown for VM limits reasons is not related to any purported
heap exhaustion but to the VM refusing to allocate an array of size
Integer.MAX_VALUE or Integer.MAX_VALUE - 1, *even* if there's plenty of
space.
For example, with 8 GiB of heap and a size of Integer.MAX_VALUE -
On Fri, 4 Jun 2021 18:23:28 GMT, Vicente Romero wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing typo.
>
> test/langtools/tools/javac/patterns/SealedTypeChanges.java line 71:
>
>> 69: }
>> 70:
>> 71: sealed i
> This is a preview of a patch implementing JEP 406: Pattern Matching for
> switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>
> A
On Fri, 4 Jun 2021 15:46:32 GMT, Paul Sandoz wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing typo.
>
> test/langtools/tools/javac/patterns/DisambiguateParenthesizedPattern.java
> line 72:
>
>> 70: Sw
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
I'm not sure if the spec should be updated. JDK-8267222 needs the GC
team to evaluate.
I have added my comment in this JBS issue.
The SoftReference spec has the guarantee:
“All soft references to softly-reachable objects are guaranteed to
have been cleared before the virtual machine throws
> …d on macOS
>
> This patch simply round up the specified stack size to multiple of the system
> page size.
>
> Test is trivial, simply run java with -Xss option against following code. On
> MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get
> `7183` and `649` respective
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
On Thu, 3 Jun 2021 00:29:00 GMT, Sandhya Viswanathan
wrote:
> The Vector API toShuffle method can be optimized using existing vector
> conversion intrinsic.
>
> The following changes are made:
> 1) vector.toShuffle java implementation is changed to call
> VectorSupport.convert.
> 2) The conv
On Fri, 4 Jun 2021 13:03:24 GMT, Vladimir Ivanov wrote:
>> Sandhya Viswanathan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implement review comments
>
> Looks good.
>
> One inefficiency I noticed is that repeated `toVector()`/`toSh
On Fri, 4 Jun 2021 13:36:27 GMT, Maxim Kartashev
wrote:
>> Character strings within JVM are produced and consumed in several formats.
>> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
>> or dlopen()) consume strings also in UTF8. On Windows, however, the
>> situat
On Fri, 4 Jun 2021 14:00:25 GMT, Maxim Kartashev
wrote:
>> Not an expert by my understanding is that the VM only deals with modified
>> UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and
>> then converted to UTF16.
>>
>> That said, this is shared code being modified on
On Wed, 2 Jun 2021 00:39:25 GMT, Stuart Marks wrote:
> I'm fixing this along with a couple intertwined issues.
>
> 1. Add Map.Entry::copyOf as an idempotent copy operation.
>
> 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not
> really immutable) but that subclasses
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
On Fri, 4 Jun 2021 05:14:13 GMT, Joe Wang wrote:
> Revert changes in StreamResult.java made through
> https://github.com/openjdk/jdk/pull/4318 since it was creating a file stream
> on behalf of the Transformer, which resulted in a leaking file handle because
> the Transformer would only close
On Fri, 4 Jun 2021 08:50:09 GMT, Daniel Fuchs wrote:
>> Revert changes in StreamResult.java made through
>> https://github.com/openjdk/jdk/pull/4318 since it was creating a file stream
>> on behalf of the Transformer, which resulted in a leaking file handle
>> because the Transformer would onl
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
On Thu, 3 Jun 2021 11:35:13 GMT, Rémi Forax wrote:
>> My mistake. I've replaced the colon now with the lambda operator. See a8706b0
>
>> My mistake. I've replaced the colon now with the lambda operator.
>
> Drive by comment, in term of name, `->` is the arrow operator not the lambda
> operator.
On Fri, 4 Jun 2021 15:10:18 GMT, Nick Gasson wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on
On Fri, 4 Jun 2021 11:07:27 GMT, Jorn Vernee wrote:
>> test/jdk/java/foreign/valist/VaListTest.java line 706:
>>
>>> 704: vaList.skip(BigPoint_LAYOUT);
>>> 705: assertEquals((long) vaList.vargAsLong(C_LONG), 42);
>>> 706: })},
>>
>> Looks
On Fri, 4 Jun 2021 12:57:17 GMT, Maurizio Cimadamore
wrote:
>
> That fix has a switch on the ABI type in the SystemLookup class (a new class
> introduced by that fix). I believe that switch will no longer compile with
> the changes in this PR as the ABI enum constants have changed - hopefully
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on the stack following the normal calling
> convention. To h
On Fri, 4 Jun 2021 14:10:20 GMT, Matthias Baesken wrote:
>> Hello, please review this small Sonar finding.
>> Sonar reports a potential NULL pointer dereference here :
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&typ
> Hello, please review this small Sonar finding.
> Sonar reports a potential NULL pointer dereference here :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&types=BUG
> "Access to field 'item' results in a dereference of a
On Fri, 4 Jun 2021 02:12:42 GMT, David Holmes wrote:
>> I am not sure we can pass non `modified UTF-8` through `JVM_LoadLibrary()`.
>> Probably some VM folks can enlighten here?
>
> Not an expert by my understanding is that the VM only deals with modified
> UTF-8, as does JNI. So the incoming s
> Character strings within JVM are produced and consumed in several formats.
> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
> or dlopen()) consume strings also in UTF8. On Windows, however, the situation
> is far less simple: some new(er) APIs expect UTF16 (wide-ch
On Thu, 3 Jun 2021 17:51:54 GMT, Naoto Sato wrote:
> I think we can simply limit the test platform only to Windows in @requires
> tag in the test. Also, I would see the test case using some supplementary
> characters.
Done.
-
PR: https://git.openjdk.java.net/jdk/pull/4169
On Thu, 3 Jun 2021 21:43:19 GMT, Sandhya Viswanathan
wrote:
>> The Vector API toShuffle method can be optimized using existing vector
>> conversion intrinsic.
>>
>> The following changes are made:
>> 1) vector.toShuffle java implementation is changed to call
>> VectorSupport.convert.
>> 2) T
On Fri, 4 Jun 2021 10:06:26 GMT, Nick Gasson wrote:
>> The JEP has been integrated, so we can pick this back up (and handle it as a
>> bug for 17 even after the fork).
>>
>> Thank you for your patience.
>
> Thanks @JornVernee! I noticed VaListTest has started failing on Windows with
> this err
On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore
wrote:
> This patch overhauls the library loading mechanism used by the Foreign Linker
> API. We realized that, while handy, the *default* lookup abstraction
> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>
> T
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on the stack following the normal calling
> convention. To h
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either registers or on the stack following the normal calling
> convention. To h
> There is a few JDK classes duplicating the contents of Long.hashCode() for
> hash code calculation. They should explicitly delegate to Long.hashCode().
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated c
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains seven commits:
On Thu, 3 Jun 2021 03:28:56 GMT, Nick Gasson wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on
On Fri, 4 Jun 2021 11:04:33 GMT, Jorn Vernee wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> No variadic upcalls
>>
>> Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5
>> CustomizedGitHooks: yes
>
> test/
On Thu, 3 Jun 2021 03:28:56 GMT, Nick Gasson wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on
Turns out that adding more timeout is a lost cause here. The root cause of the
slowdown when running the test in debug build is:
https://bugs.openjdk.java.net/browse/JDK-8266074
Which has also caused related test issues:
https://bugs.openjdk.java.net/browse/JDK-8268095
So, the fix (at least te
On Fri, 4 Jun 2021 10:06:26 GMT, Nick Gasson wrote:
>> The JEP has been integrated, so we can pick this back up (and handle it as a
>> bug for 17 even after the fork).
>>
>> Thank you for your patience.
>
> Thanks @JornVernee! I noticed VaListTest has started failing on Windows with
> this err
On Wed, 2 Jun 2021 13:42:22 GMT, Jorn Vernee wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on
> This is a preview of a patch implementing JEP 406: Pattern Matching for
> switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>
> A
On Fri, 4 Jun 2021 09:01:27 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
> This is a preview of a patch implementing JEP 406: Pattern Matching for
> switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> The current draft of the specification is here:
> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html
>
> A
On Fri, 4 Jun 2021 05:14:13 GMT, Joe Wang wrote:
> Revert changes in StreamResult.java made through
> https://github.com/openjdk/jdk/pull/4318 since it was creating a file stream
> on behalf of the Transformer, which resulted in a leaking file handle because
> the Transformer would only close
60 matches
Mail list logo
