On Wed, 27 Jul 2022 14:29:26 GMT, Jorn Vernee wrote:
> startThread and joinThread is not the functionality that the tests need.
But it is the functionality the tests are already using.
> now the context passed to CreateThread and pthread_create has to outlive the
> function
That's not an issu
What would be a good way to test for the strip executable? The easiest
solution off the top of my head is to assume a particular compiler uses a
particular strip, but that sounds a little too inflexible.
best regards,
Julian
On Wed, Jul 27, 2022 at 1:04 AM wrote:
> I'm not very familiar with th
On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote:
> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
> came from the mapping difference between MS and IBM.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9661
Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
came from the mapping difference between MS and IBM.
-
Commit messages:
- Fix 0x25 c2b in IBM864
Changes: https://git.openjdk.org/jdk/pull/9661/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9661&
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
On Wed, 27 Jul 2022 06:43:45 GMT, David Holmes 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 `FutureTas
> 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 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
>>
On Mon, 25 Jul 2022 17:21:27 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
> is m
Hi Erik,
Thanks for replying to this thread.
> Are you sure you can't configure the plugin to not add this parameter?
The configuration can be changed and I fixed it locally just now. But it
needs more time to dive into the extension and its configuration.
Maybe it is good to provide some inform
On Wed, 27 Jul 2022 12:06:51 GMT, Weijun Wang wrote:
>> The DLL should be built no matter what `BUILD_CRYPTO` is.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> indentation change
Looks good.
Minor style nit. We like to h
> The DLL should be built no matter what `BUILD_CRYPTO` is.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
indentation change
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9647/files
- new: https://git.openjdk.o
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
>>
Hello,
Building with --always-make seems like a bad idea and I would say not
recommended with the OpenJDK build. We try very hard to keep the
incremental build correct and reliable. While this particular problem
could be fixed, I wouldn't be surprised if there is more build logic
that relies
On Tue, 26 Jul 2022 19:11:23 GMT, Andrey Turbanov wrote:
>> Sacha Coppey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Avoid using set_destination when call is not jal
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.riscv64/src/jdk/
> 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 packages, as
> well as implements a part of jvmciCodeInstalle
Hi all,
When using the command `make images --always-make CONF_CHECK=ignore JOBS=4`
to build the JDK,
it doesn't succeed and returns the error message (See below for detail).
It seems that two or more processes concurrently process the target
`module-deps.gmk` which exists in the file `make/common
17 matches
Mail list logo
