On Tue, 26 Jul 2022 13:10:00 GMT, Jorn Vernee wrote:
> Does run_in_new_thread seem good enough?
No, sorry, the fact it both runs and joins is a critical aspect. `run_async`
in `CompleteableFuture` just does the "run in new thread" part, whereas the
`get()` on the returned `FutureTask` provide
On Tue, 26 Jul 2022 19:53:10 GMT, Harold Seigel wrote:
>> Please review this fix for JDK-8285792. The fix removes print statements
>> from check_signal_handler() so that it doesn't print all the handlers every
>> time it finds one that is modified. Instead, it returns true if the handler
>>
Ok, will do that.
On Wed, 27 Jul 2022, 11:42 David Holmes, wrote:
> Hi,
>
> Please take this core core-libs-dev as this is not a build issue.
>
> Thanks,
> David
>
> On 27/07/2022 1:50 am, Ananya Nayak wrote:
> > After analysing the method declaration carefully I realized some bugs in
> > the co
Hi,
Please take this core core-libs-dev as this is not a build issue.
Thanks,
David
On 27/07/2022 1:50 am, Ananya Nayak wrote:
After analysing the method declaration carefully I realized some bugs in
the code:
1. the if condition on seeing min length as less than 0 returns out
of memo
On Tue, 26 Jul 2022 18:12:33 GMT, Weijun Wang wrote:
> The DLL should be built no matter what `BUILD_CRYPTO` is.
Looks good to me.
-
Marked as reviewed by valeriep (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9647
On Tue, 26 Jul 2022 18:12:33 GMT, Weijun Wang wrote:
> The DLL should be built no matter what `BUILD_CRYPTO` is.
Your fix looks good to me. I'm assuming sspi_bridge.dll is useful regardless of
the value of BUILD_CRYPTO.
-
PR: https://git.openjdk.org/jdk/pull/9647
> Please review this fix for JDK-8285792. The fix removes print statements
> from check_signal_handler() so that it doesn't print all the handlers every
> time it finds one that is modified. Instead, it returns true if the handler
> is modified, false otherwise. Its caller, user_handler(), th
On Mon, 25 Jul 2022 14:38:26 GMT, Sacha Coppey wrote:
>> This patch adds a partial JVMCI implementation for RISC-V, to allow using
>> the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for
>> code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 pa
The DLL should be built no matter what `BUILD_CRYPTO` is.
-
Commit messages:
- the fix
Changes: https://git.openjdk.org/jdk/pull/9647/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9647&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8290920
Stats: 25 lines in 1 fil
On Mon, 25 Jul 2022 21:45:30 GMT, David Holmes wrote:
>> Harold Seigel has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> SIGFPE change
>
> src/hotspot/os/posix/signals_posix.cpp line 843:
>
>> 841: // Compare both sigaction structures (
> Please review this fix for JDK-8285792. The fix removes print statements
> from check_signal_handler() so that it doesn't print all the handlers every
> time it finds one that is modified. Instead, it returns true if the handler
> is modified, false otherwise. Its caller, user_handler(), th
On Mon, 25 Jul 2022 21:52:26 GMT, David Holmes wrote:
>> Please review this fix for JDK-8285792. The fix removes print statements
>> from check_signal_handler() so that it doesn't print all the handlers every
>> time it finds one that is modified. Instead, it returns true if the handler
>> i
On Tue, 26 Jul 2022 12:28:41 GMT, Aleksey Shipilev wrote:
> See the bug for symptoms and rationale.
>
> In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396)
> moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every
> build, we get Hotspot recompilation
I'm not very familiar with this, but it looks like clang/llvm does come
with its own strip utility, which would make this comment wrong.
On Linux, it's likely common to find the gnu binutils strip on the path
even when trying to use clang to compile OpenJDK. Ideally we should
setup STRIPFLAGS
After analysing the method declaration carefully I realized some bugs in
the code:
1. the if condition on seeing min length as less than 0 returns out of
memory error with a message that "required length is too large" which is
contradictory to what we are checking in the condition.
2.
On Mon, 25 Jul 2022 21:58:00 GMT, David Holmes wrote:
>> Harold Seigel has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Consolidate java test files, change tested signals
>
> test/hotspot/jtreg/runtime/posixSig/TestPsig.java line 28:
>
>
> Please review this fix for JDK-8285792. The fix removes print statements
> from check_signal_handler() so that it doesn't print all the handlers every
> time it finds one that is modified. Instead, it returns true if the handler
> is modified, false otherwise. Its caller, user_handler(), th
On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
> This patch removes the use of std::thread from the `java.lang.foreign` tests,
> and switches to the OS specific thread APIs, in order to change things such
> as the stack size on some platforms where this is required in the future (see
> the JBS issue).
>
> This is done by adding a small head
> This patch removes the use of std::thread from the `java.lang.foreign` tests,
> and switches to the OS specific thread APIs, in order to change things such
> as the stack size on some platforms where this is required in the future (see
> the JBS issue).
>
> This is done by adding a small head
On Mon, 25 Jul 2022 20:50:07 GMT, Phil Race wrote:
>> So the VM warnings are something of a mild annoyance that we've worked
>> around in this test but it never made sense to me what this has to do with
>> JNI ?
At some point it was decided that checkJNI should check for certain user
defined
On Tue, 26 Jul 2022 13:39:50 GMT, Jorn Vernee wrote:
>> The intent was to exit the test with a non-zero exit code, in order to avoid
>> any accidental false positives.
>>
>> I could return the error code from `GetLastError` and from the respective
>> pthread apis as an exit code instead. Is th
On Tue, 26 Jul 2022 12:58:09 GMT, Jorn Vernee wrote:
>> test/lib/native/testlib_threads.h line 50:
>>
>>> 48: static void fatal(const char* message) {
>>> 49: perror(message);
>>> 50: exit(-1);
>>
>> Won't work as intended for Windows APIs. I would print the result of
>> `GetLastError(
On Mon, 25 Jul 2022 01:15:31 GMT, David Holmes wrote:
> > I propose that when a patch touches a file with lossy conversion warnings
> > disabled, it should also enable the warnings and fix them for that file.
>
> This contradicts other common recomendations of not mixing unrelated issues
> in
On Sat, 23 Jul 2022 05:58:42 GMT, David Holmes wrote:
> `run_async` is an odd name for this, especially as the fact you create then
> join mean it doesn't run asynchronously at all - it runs synchronously in
> another thread.
I took the name from the CompleteableFuture API [1], although in th
On Fri, 22 Jul 2022 18:37:02 GMT, Thomas Stuefe wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes
>
> test/lib/native/testlib_threads.h line 61:
>
>> 59: helper->proc(helper->context);
>> 60: return 0;
On Fri, 22 Jul 2022 18:32:56 GMT, Thomas Stuefe wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes
>
> test/lib/native/testlib_threads.h line 50:
>
>> 48: static void fatal(const char* message) {
>> 49: perr
See the bug for symptoms and rationale.
In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396)
moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every
build, we get Hotspot recompilation every time, even when Hotspot is not
modified.
I believe current beh
On Mon, 27 Jun 2022 09:25:58 GMT, Adam Sotona wrote:
>> Please review this patch adding new lint option, **lossy-conversions**, to
>> javac to warn about type casts in compound assignments with possible lossy
>> conversions.
>>
>> The new lint warning is shown if the type of the right-hand ope
29 matches
Mail list logo
