On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the
On Tue, 18 Jun 2024 17:57:29 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie 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 seven
>>
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
>
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
>
On Thu, 20 Jun 2024 16:13:04 GMT, Alan Bateman wrote:
> Another thing is that using joptsimple gives up a bit of control, e.g. the
> help output shows the parameter for --class-path as `` where the java
> launcher and other tools will show "path" or "class path". Same thing with
> `--release`
On Thu, 20 Jun 2024 17:40:25 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update man page header to be consisten with the others
>
>
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Wed, 19 Jun 2024 21:13:33 GMT, Maurizio Cimadamore
wrote:
>> What do you suggest? Just a note in the error message that exploded
>> modules/class paths are not supported?
>
> Something like that yes
An altermative is to use ResolvedModule::reference to get a ModuleReference,
then use its
On Tue, 18 Jun 2024 16:35:10 GMT, Jorn Vernee wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update man page header to be consisten with the others
>
>
On Wed, 12 Jun 2024 22:38:37 GMT, Zhao Song wrote:
> @kevinrushforth said in
> [SKARA-2289](https://bugs.openjdk.org/browse/SKARA-2289), 'In general, our
> repositories contain source code and not binary files. There are exceptions
> to this for images and other similar resources, but
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Thu, 20 Jun 2024 11:38:26 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/man/jnativescan.1 line 121:
>>
>>> 119: .TP
>>> 120: \f[V]--release\f[R] \f[I]version\f[R]
>>> 121: Used to specify the Java SE release that specifies the set of
>>> restricted
>>
>> In principle, the release could
On Thu, 20 Jun 2024 12:48:40 GMT, Matthias Baesken wrote:
>> Sometimes it would be helpful to have configure-support for adding
>> additional ubsan check options.
>> E.g. support new configure option
>> '--with-additional-ubsan-checks=' .
>
> Matthias Baesken has updated the pull request
On Thu, 20 Jun 2024 12:51:22 GMT, Evemose wrote:
> wouldn't it be better to create one uniform tool
See my reply here:
https://github.com/openjdk/jdk/pull/19774#issuecomment-2179078565
-
PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2180653743
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Thu, 20 Jun 2024 11:31:05 GMT, Matthias Baesken wrote:
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
Thanks for the advice, UTIL_ARG_WITH makes the change much
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
On Thu, 20 Jun 2024 11:31:05 GMT, Matthias Baesken wrote:
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
I'm not very fond of adding new configure options, but I
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
>
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
>
On Wed, 19 Jun 2024 21:35:07 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativescan.1 line 166:
>
>> 164: .fi
>> 165:
On Thu, 20 Jun 2024 11:42:04 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/man/jnativescan.1 line 127:
>>
>>> 125: This option should be set to the version of the runtime under which the
>>> 126: application is eventually intended to be run.
>>> 127: If this flag is omitted, the version of
On Wed, 19 Jun 2024 21:30:49 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativescan.1 line 121:
>
>> 119: .TP
>> 120:
Sometimes it would be helpful to have configure-support for adding additional
ubsan check options.
E.g. support new configure option
'--with-additional-ubsan-checks=' .
-
Commit messages:
- JDK-8334618
Changes: https://git.openjdk.org/jdk/pull/19802/files
Webrev:
Many thanks Erik and Julian for the pointers,
I'll explore the --with-build-jdk suggestion, and opened a bug report:
- https://bugs.openjdk.org/browse/JDK-8334617
On Thu, Jun 20, 2024 at 9:53 AM wrote:
>
> On 6/20/24 01:01, Sanne Grinovero wrote:
> > Hi all,
> >
> > I was hoping to build a
On 6/20/24 01:01, Sanne Grinovero wrote:
Hi all,
I was hoping to build a custom JVM which would only have G1GC as a
garbage collector, for some experiments.
Essentially I'm running:
bash configure --with-jvm-variants=custom
Hi Sanne,
The reason the build fails when disabling SerialGC is due to the build
process explicitly calling the newly compiled Java with
-XX:+UseSerialGC to do small workloads. This is not a bug in the JVM,
but rather an unfortunate consequence of the way the build system is
structured. I believe
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the
On Wed, 12 Jun 2024 22:38:37 GMT, Zhao Song wrote:
> @kevinrushforth said in
> [SKARA-2289](https://bugs.openjdk.org/browse/SKARA-2289), 'In general, our
> repositories contain source code and not binary files. There are exceptions
> to this for images and other similar resources, but
Hi all,
I was hoping to build a custom JVM which would only have G1GC as a
garbage collector, for some experiments.
Essentially I'm running:
> bash configure --with-jvm-variants=custom
>
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were
On Wed, 19 Jun 2024 14:53:27 GMT, Viktor Klang wrote:
>> yeah, it's the C++ construction where the constructor and the destructor
>> have side effects. It increases the system timer resolution, unless
>> `ForceTimeHighResolution` is set. `ForceTimeHighResolution`, contrary to its
>> name and
37 matches
Mail list logo
