On Mon, 10 Jun 2024 13:48:08 GMT, Roger Riggs wrote:
>> I don't have a test or counter example and don't have a detailed
>> understanding of the blocking needs of Hotspot.
>
> Another reason to retain the checking of GetThreadInterruptEvent is to be
> belt and suspenders against the Java code
problem is
> important enough to justify an extra JNI call in the (probably typical)
> still-alive case.
>
> Tier1-3 testing clean. I modified the existing OnExitTest to cover this case.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the la
On Fri, 7 Jun 2024 20:36:45 GMT, Roger Riggs wrote:
>> I only left it here because the wait for interrupt event was already
>> present. Is being stuck in a blocking os call a bad thing? If not, I can
>> drop the interrupt event, and wait on the process handle only.
>
> I think waiting on
On Fri, 7 Jun 2024 20:35:00 GMT, Roger Riggs wrote:
>> I don't follow. Could you explain?
>
> The `WaitForSingleObject(handle, 0)` seems like an indirect way to determine
> if the process is alive.
> Whereas `isProcessAlive(handle)` seems to directly answer the question.
sorry, I still don't
On Fri, 7 Jun 2024 14:58:30 GMT, Roger Riggs wrote:
>> `GetExitCodeProcess` method is not reliable for checking if a process exited
>> already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but
>> the same value is returned when the process exited with code 259. In order
>>
`GetExitCodeProcess` method is not reliable for checking if a process exited
already; it returns 259 (STILL_ACTIVE) if the process hasn't exited yet, but
the same value is returned when the process exited with code 259. In order to
check if the process exited, we need to check if its handle is
On Sun, 26 May 2024 07:24:16 GMT, SendaoYan wrote:
>> Hi all,
>> When there is no `/usr/bin/expect` in system, `throw new SkippedException`
>> will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
>> this testcase run failed. So I make change from `throw new
On Sun, 26 May 2024 07:24:16 GMT, SendaoYan wrote:
>> Hi all,
>> When there is no `/usr/bin/expect` in system, `throw new SkippedException`
>> will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
>> this testcase run failed. So I make change from `throw new
On Fri, 24 May 2024 18:37:13 GMT, Vladimir Kozlov wrote:
>> Changed to `lea` with `InternalAddress()`. Generates the exact same code,
>> but makes more sense. I looked at `movdqu` and see no code that generates
>> RIP-relative loads. It merely checks `reachable()` and adds an intermediate
On Sun, 26 May 2024 02:58:02 GMT, SendaoYan wrote:
> Hi all,
> When there is no `/usr/bin/expect` in system, `throw new SkippedException`
> will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
> this testcase run failed. So I make change from `throw new
On Fri, 24 May 2024 14:19:13 GMT, Scott Gibbons wrote:
>> the RIP-relative lea should have a shorter encoding. I think something like
>> `lea(r15, ExternalAddress(small_jump_table))` should produce it (untested)
>
> Just did the experiment and it turns out that `mov64(r15,
>
On Thu, 23 May 2024 19:26:10 GMT, Scott Gibbons wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 268:
>>
>>> 266: __ cmpq(needle_len_p, 0);
>>> 267: __ jg_b(L_nextCheck);
>>> 268: __ xorq(rax, rax);
>>
>> out of curiosity, is there any advantage to using `xorq` instead
On Thu, 23 May 2024 17:25:34 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 Wed, 8 May 2024 08:19:54 GMT, Daniel Jeliński wrote:
> Replace the custom unsigned divide / remainder functions with the
> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>
> No new tests. Existing tier1-3 tests continue to pass.
>
> I added a new set of
On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
the BigDecimal.toString benchmarks. They no longer serve their
> purpose - toString caches the returned value, so we were only benchmarking
> the cache access time.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Integer
the BigDecimal.toString benchmarks. They no longer serve their
> purpose - toString caches the returned value, so we were only benchmarking
> the cache access time.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision
On Fri, 10 May 2024 13:39:42 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
the BigDecimal.toString benchmarks. They no longer serve their
> purpose - toString caches the returned value, so we were only benchmarking
> the cache access time.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 8 May 2024 08:19:54 GMT, Daniel Jeliński wrote:
> Replace the custom unsigned divide / remainder functions with the
> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>
> No new tests. Existing tier1-3 tests continue to pass.
>
> I added a new set of
Replace the custom unsigned divide / remainder functions with the
compiler-optimized Long.divideUnsigned / remainderUnsigned.
No new tests. Existing tier1-3 tests continue to pass.
I added a new set of divide benchmarks. Results in thread.
I also removed the BigDecimal.toString benchmarks.
On Mon, 22 Jan 2024 18:52:32 GMT, fabioromano1 wrote:
>> As you note, that would probably require two divisions. I don't know if the
>> JIT compiler can detect that the arguments are the same and emit just one
>> division instead.
>> I think your code is good enough for the purpose of
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote:
> Please help review this trivial change. This was branched from
> https://github.com/openjdk/jdk/pull/18013, based on discussion with
> @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks
LGTM
-
Marked
On Thu, 22 Feb 2024 01:42:17 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Thu, 22 Feb 2024 12:04:05 GMT, Daniel Jeliński wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Cleaner thread dequeue happens-before running cleaning action
>
> src/java.ba
On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeliński wrote:
> The recent cdb versions do not support `.dump /f`:
>
> *
> * .dump /f is not supported on a user
On Fri, 24 Nov 2023 09:58:17 GMT, Daniel Jeliński wrote:
>> The recent cdb versions do not support `.dump /f`:
>>
>> *
>> * .dump /f is not supporte
On Fri, 24 Nov 2023 11:36:27 GMT, Alan Bateman wrote:
>> It's ignoring the rest of the command line after `/f`, which means it
>> ignores the `;qd` (quit and detach) part and enters the interactive mode.
>
>> It's ignoring the rest of the command line after `/f`, which means it
>> ignores the
On Fri, 24 Nov 2023 10:28:30 GMT, Alan Bateman wrote:
>> good point, 10 minutes should be more than enough. I'll update.
>
> Out of curiosity, do we know why it takes more than an hour? Is it attempting
> to connect to the Microsoft symbol server?
It's ignoring the rest of the command line
On Fri, 24 Nov 2023 09:09:03 GMT, Alan Bateman wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> test/failure_handler/src/share/conf/windows.proper
gt; This PR updates the dump command to use the recommended `/ma` parameter. This
> allows the command to produce a dump and complete in a timely manner.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Address review comments
On Fri, 24 Nov 2023 09:17:47 GMT, Jaikiran Pai wrote:
>> test/failure_handler/src/share/conf/windows.properties line 61:
>>
>>> 59: native.core.app=cdb
>>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p
>>> 61: native.core.params.timeout=360
>>
>> Hello Daniel, I found it surprising
The recent cdb versions do not support `.dump /f`:
*
* .dump /f is not supported on a user mode process. *
* *
* .dump /ma
On Mon, 20 Nov 2023 10:09:36 GMT, Daniel Jeliński wrote:
> The direct-register test variant was removed in
> c099cf53f25496c99629dc578045aa5186e1109d. The failing test case was also
> modified - the socket timeout is much shorter now, so even if the receive
> operation gets stuck
On Mon, 20 Nov 2023 10:09:36 GMT, Daniel Jeliński wrote:
> The direct-register test variant was removed in
> c099cf53f25496c99629dc578045aa5186e1109d. The failing test case was also
> modified - the socket timeout is much shorter now, so even if the receive
> operation gets stuck
The direct-register test variant was removed in
c099cf53f25496c99629dc578045aa5186e1109d. The failing test case was also
modified - the socket timeout is much shorter now, so even if the receive
operation gets stuck for the full duration, the test will still pass.
-
Commit
Hi Birke,
You can find the unsubscribe button on the subscription management page here:
https://mail.openjdk.org/mailman/listinfo/core-libs-dev
Cheers,
Daniel
wt., 14 lis 2023 o 17:26 Birke Heeren napisał(a):
>
> please post the message:
>
> development of irk is my new goal
>
> watch at:
On Tue, 24 Oct 2023 22:57:59 GMT, Brian Burkhalter wrote:
>> Windows 11 does not reserve as many names as prior versions of Windows so do
>> not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last
On Tue, 19 Sep 2023 21:55:24 GMT, Brian Burkhalter wrote:
>> Windows 11 does not reserve as many names as prior versions of Windows so do
>> not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last
On Mon, 23 Oct 2023 11:37:08 GMT, Jorn Vernee wrote:
> See JBS issue. We don't need to save xmm16+ on x64 platforms (which are
> currently saved in FFM upcall stubs). This is achieved simply by adding these
> registers to the volatile register lists of both ABIs.
>
> Related:
On Thu, 21 Sep 2023 15:35:16 GMT, Brian Burkhalter wrote:
>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8315960: Use assertEquals
LGTM. Thanks!
-
On Thu, 21 Sep 2023 06:08:27 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes java.dll load shell32.dll earlier.
>> Delay-loading requires some additional code (delayimp.lib), and offers no
>> benefits since we always load shell32 during JVM startup.
On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeliński wrote:
> Please review this patch that makes java.dll load shell32.dll earlier.
> Delay-loading requires some additional code (delayimp.lib), and offers no
> benefits since we always load shell32 during JVM startup.
>
> Othe
On Wed, 20 Sep 2023 14:42:40 GMT, Jorn Vernee wrote:
>> src/java.base/windows/native/libjava/java_props_md.c line 214:
>>
>>> 212: HRESULT hr;
>>> 213: WCHAR *tmpPath = NULL;
>>> 214: hr = SHGetKnownFolderPath(_Profile,
>>> KF_FLAG_DONT_VERIFY, NULL, );
>>
>> I'd say
ll by 2KB on my
> machine.
> No new tests. Existing tier1-2 tests continue to pass.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Inline variable declaration
-
Changes:
- all: https://git.openjdk.org/jdk/pull/
On Wed, 20 Sep 2023 21:51:19 GMT, Brian Burkhalter wrote:
>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8315960: Address additional reviewer comments
Now that
On Tue, 19 Sep 2023 21:45:13 GMT, Brian Burkhalter wrote:
>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8315960: Fix indentation
On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes java.dll load shell32.dll earlier.
>> Delay-loading requires some additional code (delayimp.lib), and offers no
>> benefits since we always load shell32 during JVM startup.
d tier2 tests still pass
> - the same system proxies are returned with and without this patch
> - WinHTTP is not loaded unless DefaultProxySelector is used
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Revert test changes
-
On Tue, 19 Sep 2023 06:41:11 GMT, Alan Bateman wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert test changes
>
> test/jdk/java/net/ProxySelector/SystemProxies.java line 26
WinHTTP functions are only used when an application:
- uses DefaultProxySelector to resolve proxies, and
- is run with -Djava.net.useSystemProxies=true
In all other cases, loading winhttp.dll is a waste of resources.
Verified that:
- existing tier1 and tier2 tests still pass
- the same system
ll by 2KB on my
> machine.
> No new tests. Existing tier1-2 tests continue to pass.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Remove unused define
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15789/files
On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeliński wrote:
> Please review this patch that makes java.dll load shell32.dll earlier.
> Delay-loading requires some additional code (delayimp.lib), and offers no
> benefits since we always load shell32 during JVM startup.
>
> Othe
On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeliński wrote:
> Please review this patch that makes java.dll load shell32.dll earlier.
> Delay-loading requires some additional code (delayimp.lib), and offers no
> benefits since we always load shell32 during JVM startup.
>
> Othe
Please review this patch that makes java.dll load shell32.dll earlier.
Delay-loading requires some additional code (delayimp.lib), and offers no
benefits since we always load shell32 during JVM startup.
Other than removing the delayload clause, the patch also cleans up the
`getHomeFromShell32`
On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request
On Fri, 7 Jul 2023 15:27:29 GMT, Brian Burkhalter wrote:
> Was it actually verified that things are not split up into two or more
> packets? It seems that `write(2)` could in fact return a value less than the
> number of bytes requested.
Yes, the test case included in JBS sends all 4 bytes in
On Thu, 6 Jul 2023 21:40:38 GMT, Brian Burkhalter wrote:
> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no
> guarantee as to how the underlying output stream actually writes the bytes
> provided to it.
This issue is reported against JDK 8 and 9. It was fixed in
On Wed, 5 Jul 2023 10:21:51 GMT, Daniel Jeliński wrote:
> The methods declared in dirent_md are not used in libjava and not exported.
> They should be removed.
This pull request has now been integrated.
Changeset: 356067d0
Author:Daniel Jeliński
URL:
https://git.openjdk.o
The methods declared in dirent_md are not used in libjava and not exported.
They should be removed.
-
Commit messages:
- Remove dirent_md
Changes: https://git.openjdk.org/jdk/pull/14772/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=14772=00
Issue:
On Fri, 23 Jun 2023 08:03:45 GMT, Artem Semenov wrote:
>> When using the clang compiler to build OpenJDk on Linux, we encounter
>> various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional
> commit
On Fri, 23 Jun 2023 02:38:13 GMT, Julian Waters wrote:
>> On Windows, the basic Java Integer types are defined as long and __int64
>> respectively. In particular, the former is rather problematic since it
>> breaks compilation as the Visual C++ becomes stricter and more compliant
>> with
On Thu, 22 Jun 2023 09:58:19 GMT, Daniel Jeliński wrote:
>> Artem Semenov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update
>
> make/modules/java.desktop/lib/Awt2dLib
On Thu, 22 Jun 2023 14:40:23 GMT, Julian Waters wrote:
>> On Windows, the basic Java Integer types are defined as long and __int64
>> respectively. In particular, the former is rather problematic since it
>> breaks compilation as the Visual C++ becomes stricter and more compliant
>> with
On Thu, 22 Jun 2023 14:23:25 GMT, Julian Waters wrote:
>> On Windows, the basic Java Integer types are defined as long and __int64
>> respectively. In particular, the former is rather problematic since it
>> breaks compilation as the Visual C++ becomes stricter and more compliant
>> with
On Thu, 22 Jun 2023 13:48:53 GMT, Julian Waters wrote:
>> src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line
>> 547:
>>
>>> 545: snprintf( s, sizeof(s),
>>> 546: "ERROR calling GetAccessibleContextInfo; vmID = %lX,
>>> context = %p",
>>> 547:
On Thu, 22 Jun 2023 03:00:16 GMT, Julian Waters wrote:
>> On Windows, the basic Java Integer types are defined as long and __int64
>> respectively. In particular, the former is rather problematic since it
>> breaks compilation as the Visual C++ becomes stricter and more compliant
>> with
On Thu, 22 Jun 2023 09:13:21 GMT, Artem Semenov wrote:
>> When using the clang compiler to build OpenJDk on Linux, we encounter
>> various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional
> commit
On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters wrote:
>> On Windows, the basic Java Integer types are defined as long and __int64
>> respectively. In particular, the former is rather problematic since it
>> breaks compilation as the Visual C++ becomes stricter and more compliant
>> with every
On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov wrote:
>> When using the clang compiler to build OpenJDk on Linux, we encounter
>> various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request with a new target base due to a
> merge or a
On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun wrote:
>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp"
>> TEST=gc/TestAllocHumongousFragment.java
>> error info:
>>
>> Caused by: java.lang.NullPointerException: Cannot invoke
>> "sun.util.locale.BaseLocale.getVariant()" because
On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote:
> When using the clang compiler to build OpenJDk on Linux, we encounter various
> "warnings as errors".
> They can be fixed with small changes.
According to our docs, [clang is a supported compiler for
On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke wrote:
>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io
>> files to specify `Locale.ROOT` to ensure that case conversion issues don't
>> occur,
>>
>> I didn't add any new tests but ran tier 1-3 with no issues
>
>
On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke wrote:
> Updated instances of `toLowerCase` and `toUpperCase` in several net and io
> files to specify `Locale.ROOT` to ensure that case conversion issues don't
> occur,
>
> I didn't add any new tests but ran tier 1-3 with no issues
On Tue, 9 May 2023 13:20:28 GMT, Aleksei Efimov wrote:
>> JNDI `DnsClient` has a finalize method to close its internal datagram
>> channel selector.
>> The change proposed here replaces it with a cleaner to close the selector
>> once the `DnsClient`
>> instance becomes phantom reachable.
On Mon, 13 Mar 2023 15:55:27 GMT, Daniel Jeliński wrote:
>> This patch modifies the `getLastErrorString` method to return a `jstring`.
>> Thanks to that we can avoid unnecessary back and forth conversions between
>> Unicode and other charsets on Windows.
>>
On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeliński wrote:
> This patch modifies the `getLastErrorString` method to return a `jstring`.
> Thanks to that we can avoid unnecessary back and forth conversions between
> Unicode and other charsets on Windows.
>
> Other changes include:
On Mon, 13 Mar 2023 15:05:04 GMT, Roger Riggs wrote:
>> Daniel Jeliński has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Address review comments
>> - Mention that the returned text is static and thread
t;nonexistent.local");` starts with
> `"不知道这样的主机。"` (or
> `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the
> change, the exception message started with a row of question marks.
Daniel Jeliński has updated the pull request incrementally wi
On Thu, 9 Mar 2023 18:08:32 GMT, Naoto Sato wrote:
>> Daniel Jeliński has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Address review comments
>> - Mention that the returned text is static and thread
On Fri, 10 Mar 2023 21:47:45 GMT, Roger Riggs wrote:
>> Daniel Jeliński has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Address review comments
>> - Mention that the returned text is static and thread
t;nonexistent.local");` starts with
> `"不知道这样的主机。"` (or
> `"\u4e0d\u77e5\u9053\u8fd9\u6837\u7684\u4e3b\u673a\u3002"`). Without the
> change, the exception message started with a row of question marks.
Daniel Jeliński has updated the pull request incrementally with th
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
On Thu, 9 Mar 2023 00:17:42 GMT, Naoto Sato wrote:
On Wed, 8 Mar 2023 23:23:33 GMT, Chris Plummer wrote:
>> This patch modifies the `getLastErrorString` method to return a `jstring`.
>> Thanks to that we can avoid unnecessary back and forth conversions between
>> Unicode and other charsets on Windows.
>>
>> Other changes include:
>> - the
On Wed, 8 Mar 2023 11:30:27 GMT, Daniel Jeliński wrote:
> This patch modifies the `getLastErrorString` method to return a `jstring`.
> Thanks to that we can avoid unnecessary back and forth conversions between
> Unicode and other charsets on Windows.
>
> Other changes include:
This patch modifies the `getLastErrorString` method to return a `jstring`.
Thanks to that we can avoid unnecessary back and forth conversions between
Unicode and other charsets on Windows.
Other changes include:
- the Windows implementation of `getLastErrorString` no longer checks `errno`.
I
On Thu, 16 Feb 2023 14:42:52 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which fixes the usage of
> `Preconditions.checkFromIndexSize`? This addresses
> https://bugs.openjdk.org/browse/JDK-8302664.
>
> There was an oversight when these changes were introduced in
>
On Fri, 10 Feb 2023 02:11:35 GMT, Brian Burkhalter wrote:
> Replace the two occurrences of `character` with `byte`.
There are similar incorrect comments in SequenceInputStream and
BufferedInputStream. There could be others, but "character" is a very popular
word, so they are hard to spot.
On Mon, 30 Jan 2023 11:06:05 GMT, Daniel Jeliński wrote:
> Please review this patch that reduces the socket timeout used in
> HandshakeTimeout test to its minimum value of 1 millisecond.
>
> This change makes the test complete 10 seconds faster; before this change it
>
On Tue, 7 Feb 2023 09:38:13 GMT, Daniel Jeliński wrote:
>> Please review this patch that reduces the socket timeout used in
>> HandshakeTimeout test to its minimum value of 1 millisecond.
>>
>> This change makes the test complete 10 seconds faster; before this chan
2
> handshakes.
>
> The change also makes the test more likely to pass when it has to compete
> with other tests for CPU time.
Daniel Jeliński has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
bro
On Mon, 30 Jan 2023 12:54:34 GMT, Vyom Tewari wrote:
> I can see that this test uses "TIMEOUT" down in test
Right, this is why I didn't remove the TIMEOUT constant
> i will suggest you to reduce the "TIMEOUT" constant instead of hard coding it
> to "1" second.
I can't; this would make the
Please review this patch that reduces the socket timeout used in
HandshakeTimeout test to its minimum value of 1 millisecond.
This change makes the test complete 10 seconds faster; before this change it
took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
The change
On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev wrote:
>> This should help to speed up tests significantly. Currently, if we run "make
>> test" with a subset of tests, JTReg would still read the entirety of test
>> root to report on tests that were not run. Even with current suite of tests
On Tue, 3 Jan 2023 13:35:32 GMT, Daniel Jeliński wrote:
> This patch introduces a time limit for establishing a secure connection to a
> RMI server.
>
> The existing implementation uses the configured
> `sun.rmi.transport.tcp.handshakeTimeout` during RMI handshake only; the
This patch introduces a time limit for establishing a secure connection to a
RMI server.
The existing implementation uses the configured
`sun.rmi.transport.tcp.handshakeTimeout` during RMI handshake only; there's no
time limit for SSL handshake.
With this patch, the configuration option
On Fri, 2 Dec 2022 08:31:25 GMT, Daniel Jeliński wrote:
> Please review this patch that removes progress monitoring classes used by
> UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from
> java.base. If anyone was still using them, reimple
On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeliński wrote:
>> Please review this patch that removes progress monitoring classes used by
>> UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported
>> from java.base. If anyone was still us
1 - 100 of 124 matches
Mail list logo
