On Mon, 1 Feb 2021 22:46:15 GMT, David Holmes wrote:
>> Before RC phase we need to ensure we have the final set of manpage updates
>> published in OpenJDK.
>
> Thanks for doing this Magnus! I had overlooked the fact we would need to
> re-run this in 2021 regardless of whether there were any con
On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote:
> Before RC phase we need to ensure we have the final set of manpage updates
> published in OpenJDK.
This pull request has now been integrated.
Changeset: ed1a7755
Author:Magnus Ihse Bursie
URL: https://git.openjdk.java.net/
On Mon, 1 Feb 2021 18:49:04 GMT, djelinski
wrote:
>> Under certain load, MemoryCache operations take a substantial fraction of
>> the time needed to complete SSL handshakes. This series of patches improves
>> performance characteristics of MemoryCache, at the cost of a functional
>> change: e
On Mon, 1 Feb 2021 22:45:17 GMT, Claes Redestad wrote:
>> Build change looks good, but I would like to hear from @cl4es too.
>
> Adding an `--add-exports` to `JAVAC_FLAGS` is a bit iffy, but should be OK.
> Yes, all benchmarks will now be compiled with that package exported and
> visible, but t
On Mon, 1 Feb 2021 22:17:38 GMT, Sergey Bylokhov wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop module
>
> src/java.desktop/macosx/native/libawt_lwawt/
On Mon, 1 Feb 2021 19:09:59 GMT, Phil Race wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtilities.h to get jni.h
>> definitions - better any
On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote:
> Before RC phase we need to ensure we have the final set of manpage updates
> published in OpenJDK.
Thanks for doing this Magnus! I had overlooked the fact we would need to re-run
this in 2021 regardless of whether there were any cont
On Mon, 1 Feb 2021 19:22:22 GMT, Erik Joelsson wrote:
>> djelinski has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify makefile
>
> Build change looks good, but I would like to hear from @cl4es too.
Adding an `--add-exports` to `JA
On 2/1/21 9:36 AM, Thomas Stüfe wrote:
This does not solve the alignment problem, but I don't like that we
unconditionally print a message here since this is a non-fatal error.
Also, CDS mapping may fail for other reasons, for which we do not
print unconditionally. I think we should make this i
On Mon, 1 Feb 2021 20:29:10 GMT, Gerard Ziemski wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed macos build
>
> src/java.base/share/native/libjava/check_version.c line 33:
>
>> 31: DEF_JNI_OnLoad(JavaVM *vm, void
On Mon, 1 Feb 2021 20:10:58 GMT, Ioi Lam wrote:
>> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which
>> allowed the same JDK library to use different version of HotSpot. However,
>> HSX is no longer supported so this API should be removed.
>> - Implementations of APIs such a
> - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed
> the same JDK library to use different version of HotSpot. However, HSX is no
> longer supported so this API should be removed.
> - Implementations of APIs such as JVM_DTraceActivate, were removed in
> [JDK-8068976]
On Mon, 1 Feb 2021 18:49:04 GMT, djelinski
wrote:
>> Under certain load, MemoryCache operations take a substantial fraction of
>> the time needed to complete SSL handshakes. This series of patches improves
>> performance characteristics of MemoryCache, at the cost of a functional
>> change: e
On 2021-02-01 10:38, Alexey Semenyuk wrote:
On Mon, 1 Feb 2021 18:24:23 GMT, Erik Joelsson wrote:
"common" was perfectly enough until this change. Unfortunately we cant just drop new C
sources in "common" dir because we don't want them to be compiled with g++. That is why
need new common d
I can confirm that the autoconf warning disabling is currently still
needed when building with our standard devkit.
It'll have to be removed at the very end.
In file included from
./open/src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m:27:
.
/System/Library/Fram
> This completes the desktop module JNF removal
>
> * remove -framework JavaNativeFoundation from make files
>
> * remove #import from all
> source files. If needed add import of JNIUtilities.h to get jni.h definitions
> - better anyway since then it gets the current JDK ones not the ones fr
On Sun, 31 Jan 2021 20:14:01 GMT, Anton Kozlov wrote:
>> 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
On Mon, 1 Feb 2021 18:35:56 GMT, djelinski
wrote:
>> Hm, maybe you just misunderstand how this makefile construct works. If you
>> just want to add "--add-exports java.base/sun.security.util=ALL-UNNAMED",
>> then that's all you should put in this assignment.
>
> yeah, I'm new to makefiles. Let
> Under certain load, MemoryCache operations take a substantial fraction of the
> time needed to complete SSL handshakes. This series of patches improves
> performance characteristics of MemoryCache, at the cost of a functional
> change: expired entries are no longer guaranteed to be removed bef
On Mon, 1 Feb 2021 18:31:39 GMT, Erik Joelsson wrote:
>> Adding "--add-exports java.base/sun.security.util=ALL-UNNAMED" is fine, I'm
>> asking about "$(JAVAC_FLAGS)".
>
> Hm, maybe you just misunderstand how this makefile construct works. If you
> just want to add "--add-exports java.base/sun.s
On Mon, 1 Feb 2021 18:24:23 GMT, Erik Joelsson wrote:
>> "common" was perfectly enough until this change. Unfortunately we cant just
>> drop new C sources in "common" dir because we don't want them to be compiled
>> with g++. That is why need new common directory (applauncherlibcommon) for C
>
On Mon, 1 Feb 2021 18:30:14 GMT, Erik Joelsson wrote:
>> I'm trying to benchmark a class that is in a non-exported package
>> `sun.security.util`. Without this line the benchmark doesn't compile. I
>> couldn't find any other benchmarks that access non-exported classes, so I
>> came up with my
On Mon, 1 Feb 2021 18:31:23 GMT, Gerard Ziemski wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> Marked as reviewed by gziemski (Committer).
T
On Fri, 29 Jan 2021 19:53:32 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83:
>>
>>> 81: stringWithFileSystemRepresentation:chs length:len];
>>> 82: return result;
>>> 83: }
>>
>> Why are we doing:
>>
>> `java_string -> chars -> NS
On Mon, 1 Feb 2021 18:24:46 GMT, djelinski
wrote:
>> make/test/BuildMicrobenchmark.gmk line 97:
>>
>>> 95: SRC := $(MICROBENCHMARK_SRC), \
>>> 96: BIN := $(MICROBENCHMARK_CLASSES), \
>>> 97: JAVAC_FLAGS := $(JAVAC_FLAGS) --add-exports
>>> java.base/sun.security.util=ALL-UNNAMED, \
On Fri, 29 Jan 2021 17:24:05 GMT, Phil Race wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtilities.h to get jni.h
>> definitions - better an
On Mon, 1 Feb 2021 16:51:12 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>> libosxkrb5/SCDynamicStoreConfig.m](https://b
On Mon, 1 Feb 2021 18:18:51 GMT, Erik Joelsson wrote:
>> Under certain load, MemoryCache operations take a substantial fraction of
>> the time needed to complete SSL handshakes. This series of patches improves
>> performance characteristics of MemoryCache, at the cost of a functional
>> change
On Mon, 1 Feb 2021 16:17:35 GMT, Alexey Semenyuk wrote:
> "common" was perfectly enough until this change. Unfortunately we cant just
> drop new C sources in "common" dir because we don't want them to be compiled
> with g++. That is why need new common directory (applauncherlibcommon) for C
>
On Wed, 27 Jan 2021 11:32:08 GMT, djelinski
wrote:
> Under certain load, MemoryCache operations take a substantial fraction of the
> time needed to complete SSL handshakes. This series of patches improves
> performance characteristics of MemoryCache, at the cost of a functional
> change: expi
> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>
> The fix splits Linux app launcher in app launcher and launcher shared lib.
> App launcher is pure C and doesn't have C++ code. App launcher lib
> incorporates bulk of C++ code from app launcher.
> At startup app launcher loads launc
This does not solve the alignment problem, but I don't like that we
unconditionally print a message here since this is a non-fatal error. Also,
CDS mapping may fail for other reasons, for which we do not print
unconditionally. I think we should make this info log level:
--- a/src/hotspot/share/mem
On 2/1/21 5:14 PM, Aleksey Shipilev wrote:
> On 2/1/21 4:38 PM, Andrew Haley wrote:
>> but that doesn't work either. Any ideas? I'm really stuck.
>
> Did you "make clean" after changing any of the configure files and/or
> configure arguments? I.e. did
> AWTIcon32_java_icon16_png actually regener
On 2/1/21 4:38 PM, Andrew Haley wrote:
but that doesn't work either. Any ideas? I'm really stuck.
Did you "make clean" after changing any of the configure files and/or configure arguments? I.e. did
AWTIcon32_java_icon16_png actually regenerate?
Prepending the build with "LOG=debug" would tel
On Mon, 1 Feb 2021 11:41:02 GMT, Magnus Ihse Bursie wrote:
>> Weijun Wang has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 15 additional
>> commi
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)
Weijun Wang has up
On Mon, 1 Feb 2021 12:19:56 GMT, Magnus Ihse Bursie wrote:
>> Alexey Semenyuk has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one
Under certain load, MemoryCache operations take a substantial fraction of the
time needed to complete SSL handshakes. This series of patches improves
performance characteristics of MemoryCache, at the cost of a functional change:
expired entries are no longer guaranteed to be removed before live
On Mon, 1 Feb 2021 12:16:09 GMT, Magnus Ihse Bursie wrote:
>> Alexey Semenyuk has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one
Per my comment in the PR I am currently working on updating it to handle
the test update needed.
Once the other in-flight PRs are integrated, my grepping says that the
only remaining build change
needed after that is to remove one disabled warning in
make/autoconf/flags-cflags.m4
I am goin
On Mon, 1 Feb 2021 11:35:22 GMT, Magnus Ihse Bursie wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> Build changes look good for this PR.
> *
I've been unable to get OpenJDK to build on one box because of this message:
[0.013s][error][cds] Unable to map CDS archive --
os::vm_allocation_granularity() expected: 4096 actual: 65536
The problem is that this box is using 64kb pages, and the boostrap
Java was built on a machine with 4k pages
On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote:
> Before RC phase we need to ensure we have the final set of manpage updates
> published in OpenJDK.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk16/pull/142
On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson wrote:
> The build on Windows can fail if certain directory names are present in root
> directory of the workspace. In particular I've observed that the single
> letter 'p' is triggering this problem. This is caused by missing quotes
> around [:u
On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward
wrote:
> > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>
> Unless there's something I'm missing it only requires a few lines of change
> to src/utils/hsdis/makefile (it already has support for macos x86_64)
I agree
On Mon, 1 Feb 2021 11:19:34 GMT, Vladimir Kempik wrote:
> Hello, hsdis is a separate out-of-tree project and is not part of this jep.
Unless there's something I'm missing it only requires a few lines of change to
src/utils/hsdis/makefile (it already has support for macos x86_64)
>support for l
On Fri, 29 Jan 2021 23:06:20 GMT, Alexey Semenyuk wrote:
>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>>
>> The fix splits Linux app launcher in app launcher and launcher shared lib.
>> App launcher is pure C and doesn't have C++ code. App launcher lib
>> incorporates bulk of C+
On Sun, 31 Jan 2021 18:45:19 GMT, Weijun Wang wrote:
>> This fix covers both
>>
>> - [[macOS]: Remove JNF dependency from
>> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
>> - [[macOS]: Remove JNF dependency from
>> libosxkrb5/SCDynamicStoreConfig.m](https://
On Fri, 29 Jan 2021 17:24:05 GMT, Phil Race wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtilities.h to get jni.h
>> definitions - better an
On 2021-01-29 17:41, Phil Race wrote:
But we can just remove it and prove it - but probably a separate PR since it is
nothing to do with the desktop module and the autoconf code needs to be updated
once everything else is in.
Fair enough. Do you have a JBS issue tracking the remaining build sys
On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote:
> Before RC phase we need to ensure we have the final set of manpage updates
> published in OpenJDK.
These updates have been made automatically from the markdown source files
(which unfortunately is still closed-only).
-
On Fri, 29 Jan 2021 19:54:12 GMT, Erik Joelsson wrote:
> The build on Windows can fail if certain directory names are present in root
> directory of the workspace. In particular I've observed that the single
> letter 'p' is triggering this problem. This is caused by missing quotes
> around [:u
On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward
wrote:
> You need add macos arm64 to hsdis. Having it working is fairly essential for
> debugging.
>
> Inside src/utils/hsdis, After cloning binutils
>
> ```
> make; make demo; ./build/macosx-arm64/hsdis-demo
> ```
>
> Results in:
>
> ```
> Hell
Before RC phase we need to ensure we have the final set of manpage updates
published in OpenJDK.
-
Commit messages:
- 8258378: Final nroff manpage update for JDK 16
Changes: https://git.openjdk.java.net/jdk16/pull/142/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=1
On Wed, 27 Jan 2021 14:58:27 GMT, Vladimir Kempik wrote:
>> Build changes per se now looks okay. However, I agree with Erik that unless
>> this PR can wait for the JNF removal, at the very least the build docs needs
>> to be updated to explain how to successfully build for this platform. (I can
55 matches
Mail list logo
