There are 3 nodes involving in the construction of a java.lang.String object.
1. Allocate of itself, aka. alloc
2. AllocateArray of a byte array, which is value:byte[], aka. aa
3. ArrayCopyNode which copys in the contents of value, aka. ac
Lemma
When a String object `alloc` is scalar replaced, C2
Hi,
Please review this fix for JDK-8252883. This handles the case when an
AccessDeniedException is being thrown on Windows, due to a delay in deleting
the lock file it is trying to write to.
This fix passes all testing.
Kind regards,
Evan
-
Commit messages:
- 8252883: AccessDeni
On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov
wrote:
>> This fours tests pass without problems, when I run them separately.
>>
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.ja
On Thu, 11 Feb 2021 19:30:02 GMT, Kevin Rushforth wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set
>
> Looks good.
Thanks for the fix! This is probably the bes
On Mon, 15 Feb 2021 10:39:32 GMT, Evan Whelan wrote:
> Hi,
>
> Please review this fix for JDK-8252883. This handles the case when an
> AccessDeniedException is being thrown on Windows, due to a delay in deleting
> the lock file it is trying to write to.
>
> This fix passes all testing.
>
> K
After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
still fails on BigSur versions that have a patch version (> 1), e.g. on macOS
Big Sur 11.2.1, and where the JDK was built with xcode < 12.
java.lang.Error: 11.2 != 11.2.1
This is a proposal to relax the test and throw a
On Mon, 15 Feb 2021 13:27:36 GMT, Christoph Langer wrote:
> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
> still fails on BigSur versions that have a patch version (> 1), e.g. on macOS
> Big Sur 11.2.1, and where the JDK was built with xcode < 12.
>
> java.lang.E
Hello,
I wonder if there has already been some discussion to provide
a System.getEnv(String name, String def) method that allows to return a
default value in case the env variable didn't exist.
When using system properties instead of env variable, we do have a
System.getProperty(String key, Strin
Hi Loic,
You can use Optional.OfNullable() which is a kind of the general bridge between
the nullable world and the non-nullable one.
var fooOptional = Optional.ofNullable(System.getenv("FOO"));
var fooValue = fooOptional.orElse(defaultValue);
regards,
Rémi Forax
- Mail original -
On Mon, 15 Feb 2021 13:40:26 GMT, Christoph Langer wrote:
>> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
>> still fails on BigSur versions that have a patch version (> 1), e.g. on
>> macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12.
>>
>> java.l
Hi,
An alternative to a new API is to use the general purpose
java.util.Objects.requireNonNull(T,T);
Objects.requireNonNullElse(System.getEnv(String key), "n/a"));
But a defaulting overload is straightforward.
Regard, Roger
On 2/15/21 8:59 AM, Loïc MATHIEU wrote:
Hello,
I wonder if there
On Mon, 15 Feb 2021 14:06:31 GMT, Roger Riggs wrote:
> Given the lack of veracity from the os...
> Perhaps check that `swVersion.startsWith(osVersion) == true` (if the whole
> string doesn't match).
>
> I'm hopeful that when JDK 17 is released the toolchain has been upgraded and
> this patch w
On Mon, 15 Feb 2021 11:22:10 GMT, Claes Redestad wrote:
> This patch exposes a couple of intrinsics used by String to speed up ASCII
> checking and byte[] -> char[] inflation, which can be used by latin1 and
> ASCII-compatible CharsetDecoders to speed up decoding operations.
>
> - Fast-path im
This patch exposes a couple of intrinsics used by String to speed up ASCII
checking and byte[] -> char[] inflation, which can be used by latin1 and
ASCII-compatible CharsetDecoders to speed up decoding operations.
- Fast-path implemented for all standard charsets, with up to 10x performance
imp
> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
> still fails on BigSur versions that have a patch version (> 1), e.g. on macOS
> Big Sur 11.2.1, and where the JDK was built with xcode < 12.
>
> java.lang.Error: 11.2 != 11.2.1
>
> This is a proposal to relax the te
On Mon, 15 Feb 2021 15:07:55 GMT, Christoph Langer wrote:
>> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
>> still fails on BigSur versions that have a patch version (> 1), e.g. on
>> macOS Big Sur 11.2.1, and where the JDK was built with xcode < 12.
>>
>> java.l
> This patch exposes a couple of intrinsics used by String to speed up ASCII
> checking and byte[] -> char[] inflation, which can be used by latin1 and
> ASCII-compatible CharsetDecoders to speed up decoding operations.
>
> - Fast-path implemented for all standard charsets, with up to 10x perfor
On Fri, 12 Feb 2021 12:22:09 GMT, Vladimir Kempik wrote:
>> Where did this come from - some snippet/example/tech note code? Maybe other
>> people can help figure it out if we provide more info.
>
> This is the version of w^x on-demand switch implemented by microsoft guys.
> This is enabled only
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
On Sun, 31 Jan 2021 20:08:01 GMT, Vladimir Kempik wrote:
>> I'm not sure it can wait. This change turns already-messy code into
>> something significantly messier, to the extent that it's not really good
>> enough to go into mainline.
>
> Hello
> Does this look like something in the right direc
On Fri, 12 Feb 2021 20:27:00 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my changeset for JDK-8252399: 'Update mapMulti
>> documentation to use type test pattern instead of instanceof once JEP 375
>> exits preview' ?
>>
>> This change updates the example code displ
On Tue, 2 Feb 2021 21:52:47 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810:
>
>> 808: #ifdef
On Wed, 3 Feb 2021 20:08:41 GMT, Anton Kozlov wrote:
> I'm going to do as much refactoring as needed before this patch under
> JDK-8261071
The recent merge resolves inconsitency between pass_byte/pass_short and other
methods.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
On Mon, 1 Feb 2021 18:44:48 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 62 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> - Update copyright year for BsdAARCH64ThreadContext
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov
wrote:
>> This fours tests pass without problems, when I run them separately.
>>
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.ja
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
revert
On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272: Ref
On Mon, 15 Feb 2021 18:00:50 GMT, Vladimir Kempik wrote:
>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839:
>>
>>> 837: // The code unable to handle this, bailout.
>>> 838: return -1;
>>> 839: #endif
>>
>> This looks like a bug to me. The caller doesn't necessari
On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis
wrote:
>>> Hi Claes,
>>> Would flattening the state of MD5 bring any further improvements?
>>> [plevart@92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083)
>>
>> I think it might, marginally, but it seemed to m
On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272: Ref
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
remove
On Mon, 15 Feb 2021 19:23:16 GMT, Alan Bateman wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>> revert changes from MimeLauncher
>
>
On Mon, 15 Feb 2021 11:30:54 GMT, Claes Redestad wrote:
>> This patch exposes a couple of intrinsics used by String to speed up ASCII
>> checking and byte[] -> char[] inflation, which can be used by latin1 and
>> ASCII-compatible CharsetDecoders to speed up decoding operations.
>>
>> - Fast-pa
On Mon, 15 Feb 2021 19:56:32 GMT, Philippe Marschall
wrote:
> Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[],
> int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem
very reaso
On Mon, 15 Feb 2021 19:07:40 GMT, Andrew Haley wrote:
>> Hello, we have updated PR, now this bailout is used only by the code which
>> can handle it (native wrapper generator), for the rest it will cause
>> guarantee failed if this bailout is triggered
>
> This is when passing a float, yes? In
On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272: Ref
39 matches
Mail list logo
