On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshing
On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshing
On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshing
On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda wrote:
>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is
>> the target Symbol type. Only targets right now are `TypeSymbol`s,
>> `MethodSymbol`s and
On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda wrote:
>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is
>> the target Symbol type. Only targets right now are `TypeSymbol`s,
>> `MethodSymbol`s and
On Mon, 11 Aug 2025 09:35:09 GMT, Magnus Ihse Bursie wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed makefiles
>
> make/RunTests.gmk line 881:
>
>> 879:
>> 880: ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
>>
On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik wrote:
>> The fix added JVMTI stress testing mode.
>>
>> This mode enables stress agent that could be executed with jtreg test and
>> help to ensure that jvmti functionality doesn't break the other JVM/JDK
>> functionality.
>>
>> I filed few iss
On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshing
On Mon, 11 Aug 2025 11:35:12 GMT, Christian Stein wrote:
>> Please review the change to update to using jtreg 8.
>>
>> The primary change is to the `jib-profiles.js` file, which specifies the
>> version of jtreg to use, for those systems that rely on this file. In
>> addition, the requiredVers
On Mon, 11 Aug 2025 14:23:03 GMT, Magnus Ihse Bursie wrote:
>> I could also create a separate file for each launcher with a name pattern
>> and gather up all these files in StaticLibs.gmk, but then I will get
>> problems with left-over such files, for e.g. if incrementally building after
>> re
On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi wrote:
> In this PR I add an `autoconfigure` check to make sure that `jfr` is not
> built without the feature `services`, which would lead to the following error:
>
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
>
On Mon, 11 Aug 2025 15:49:55 GMT, Magnus Ihse Bursie wrote:
>> Some results:
>>
>> | Features | Time1 (s) | Time2 (s) | Change (s) |
>> |-|--|--|-|
>> | epsilongc | 490.77 | 489.50 | 1.2
On Mon, 11 Aug 2025 14:49:54 GMT, Francesco Andreuzzi wrote:
> * `link-time-opt`
>
> * `opt-size`
I thought these should not really affect the set of files compiled (or
included, which is what matters here)?
-
PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-317548
On Mon, 4 Aug 2025 08:40:13 GMT, Thomas Stuefe wrote:
> A customer reported an error where a well-known system library, upon loading
> into the JVM process (via a longish indirect dependency chain), changed the
> signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited
> d
On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshing
On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi wrote:
> In this PR I add an `autoconfigure` check to make sure that `jfr` is not
> built without the feature `services`, which would lead to the following error:
>
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
>
On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi wrote:
> In this PR I add an `autoconfigure` check to make sure that `jfr` is not
> built without the feature `services`, which would lead to the following error:
>
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
>
On Mon, 11 Aug 2025 14:18:41 GMT, Magnus Ihse Bursie wrote:
>> Hm. I put it there since it was the only place where we could be sure we
>> know *all* launchers for a module. I could have each launcher add itself to
>> the list, but then I either need to check if it is already there, or we will
On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi wrote:
> In this PR I add an `autoconfigure` check to make sure that `jfr` is not
> built without the feature `services`, which would lead to the following error:
>
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
>
On Fri, 1 Aug 2025 14:33:43 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove problemlisting
>
> make/ModuleWrapper.gmk line 82:
>
>> 80: TARGETS += $(LAUNCHERS_LIST)
>> 81: end
On Mon, 11 Aug 2025 14:17:26 GMT, Magnus Ihse Bursie wrote:
>> make/ModuleWrapper.gmk line 82:
>>
>>> 80: TARGETS += $(LAUNCHERS_LIST)
>>> 81: endif
>>> 82: endif
>>
>> I think it would be cleaner if this could be kept in LauncherCommon.gmk and
>> avoid having ModuleWrapper.gmk involved
On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie wrote:
> From the bug description:
>
> There are plans to build libgraal in JDK master using a version of Native
> Image running on a JDK one version behind JDK master. This Native Image
> execution needs to be able to load the JVMCI classes
On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi wrote:
> In this PR I add an `autoconfigure` check to make sure that `jfr` is not
> built without the feature `services`, which would lead to the following error:
>
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
>
On Mon, 11 Aug 2025 13:44:32 GMT, Magnus Ihse Bursie wrote:
>> From the bug description:
>>
>> There are plans to build libgraal in JDK master using a version of Native
>> Image running on a JDK one version behind JDK master. This Native Image
>> execution needs to be able to load the JVMCI cl
On Mon, 11 Aug 2025 13:07:59 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Shorten line lengths
>
> make/common/JavaCompilation.gmk line 42:
>
>> 40: # Create classes that can run on the
> From the bug description:
>
> There are plans to build libgraal in JDK master using a version of Native
> Image running on a JDK one version behind JDK master. This Native Image
> execution needs to be able to load the JVMCI classes as they are built into
> the libgraal image. As such, the JV
On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi wrote:
> In this PR I add an `autoconfigure` check to make sure that `jfr` is not
> built without the feature `services`, which would lead to the following error:
>
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
>
On Mon, 11 Aug 2025 10:55:44 GMT, Francesco Andreuzzi wrote:
> In this PR I add an `autoconfigure` check to make sure that `jfr` is not
> built without the feature `services`, which would lead to the following error:
>
> /jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
>
On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie wrote:
> From the bug description:
>
> There are plans to build libgraal in JDK master using a version of Native
> Image running on a JDK one version behind JDK master. This Native Image
> execution needs to be able to load the JVMCI classes
On Sat, 14 Jun 2025 03:51:28 GMT, SendaoYan wrote:
> Hi all,
>
> The debuginfo file will not ship to customers generally, so I think it's not
> necessary to check the debuginfo files contains absolutive path or not. And I
> can't find why the debuginfo file always contains workspace path info
> In the static JDK image, a single humongous java executable is generated, and
> no other launcher, such as javac. This makes it impossible to run our jtreg
> tests, which assume these are present.
>
> The solution is fortunately simply: we just need to add a bunch of trivial
> launchers, whic
On Fri, 1 Aug 2025 17:12:55 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove problemlisting
>
> make/StaticLibs.gmk line 163:
>
>> 161: # $2: The launcher name
>> 162: define SetupRe
On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 8.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion h
> Please review the change to update to using jtreg 8.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion has been updated in the various `TEST.ROOT`
> files.
Chris
On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda wrote:
>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is
>> the target Symbol type. Only targets right now are `TypeSymbol`s,
>> `MethodSymbol`s and
In this PR I add an `autoconfigure` check to make sure that `jfr` is not built
without the feature `services`, which would lead to the following error:
/jdk/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp: In member function
‘virtual void VM_GC_SendObjectCountEvent::doit()’:
/jdk/src/hotspot/shar
According to https://github.com/openjdk/jdk/pull/26661#issuecomment-3162014034,
we should not build gtest with `/EHsc`.
I can honestly say I don't fully understand the consequences of this change,
but at least it passes building and testing on Oracle CI. And it does seem to
make sense that we
On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie wrote:
> From the bug description:
>
> There are plans to build libgraal in JDK master using a version of Native
> Image running on a JDK one version behind JDK master. This Native Image
> execution needs to be able to load the JVMCI classes
> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is
> the target Symbol type. Only targets right now are `TypeSymbol`s,
> `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s,
>
On Mon, 11 Aug 2025 08:57:10 GMT, Magnus Ihse Bursie wrote:
> An alternative is to disable C4530; I can try that as well.
Well, that built and tested successfully at least. I've opened
[JDK-8365231](https://bugs.openjdk.org/browse/JDK-8365231), so we can continue
further discussion about that
On Tue, 1 Jul 2025 07:46:12 GMT, Magnus Ihse Bursie wrote:
> Add some additional and more fine-grained way in which custom makefiles can
> be integrated.
This pull request has now been integrated.
Changeset: 1fc0b016
Author:Magnus Ihse Bursie
URL:
https://git.openjdk.org/jdk/commit
On Tue, 1 Jul 2025 14:11:32 GMT, Magnus Ihse Bursie wrote:
> From the bug description:
>
> There are plans to build libgraal in JDK master using a version of Native
> Image running on a JDK one version behind JDK master. This Native Image
> execution needs to be able to load the JVMCI classes
On Mon, 28 Jul 2025 21:10:24 GMT, Chen Liang wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reverting runtime checks, as suggested.
>
> make/langtools/tools/flagsgenerator/FlagsGenerator.java line 84:
>
>> 82:
> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is
> the target Symbol type. Only targets right now are `TypeSymbol`s,
> `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s,
>
On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 8.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion h
On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik wrote:
>> The fix added JVMTI stress testing mode.
>>
>> This mode enables stress agent that could be executed with jtreg test and
>> help to ensure that jvmti functionality doesn't break the other JVM/JDK
>> functionality.
>>
>> I filed few iss
On Mon, 11 Aug 2025 09:24:27 GMT, Magnus Ihse Bursie wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed makefiles
>
> make/RunTests.gmk line 882:
>
>> 880: ifneq ($$(JTREG_JVMTI_STRESS_AGENT), )
>> 881:
On Sun, 10 Aug 2025 06:09:00 GMT, Leonid Mesnik wrote:
>> The fix added JVMTI stress testing mode.
>>
>> This mode enables stress agent that could be executed with jtreg test and
>> help to ensure that jvmti functionality doesn't break the other JVM/JDK
>> functionality.
>>
>> I filed few iss
On Mon, 28 Jul 2025 06:50:47 GMT, Jan Lahoda wrote:
>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is
>> the target Symbol type. Only targets right now are `TypeSymbol`s,
>> `MethodSymbol`s and
On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga wrote:
> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609
> (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death
> tests to fail on Windows with the error message "Caught
> std::exception-derived
On Mon, 11 Aug 2025 08:10:09 GMT, Magnus Ihse Bursie wrote:
> > But still need to figure out which files to (conditionally) exclude.
>
> Maybe first make a baseline build with no optional features, and analyze the
> result with this tool. And then enable each individual feature, re-build and
>
On Wed, 6 Aug 2025 18:05:24 GMT, Saint Wesonga wrote:
> https://github.com/openjdk/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609
> (from https://bugs.openjdk.org/browse/JDK-8343756) caused the gtest death
> tests to fail on Windows with the error message "Caught
> std::exception-derived
On Fri, 8 Aug 2025 15:31:18 GMT, Francesco Andreuzzi wrote:
>> You need to modify the comment here, too.
>
> Right, I'll wait just a bit so the discussion on how to approach the problem
> stabilizes :)
This number is based on my original experimentation. If I tried to lower the
bar by lowering
On Thu, 7 Aug 2025 19:55:35 GMT, Francesco Andreuzzi wrote:
> Also, maybe check in the generation script as well? I think a subfolder here
> would be fine: https://github.com/openjdk/jdk/tree/master/src/utils.
@shipilev I'm not sure this is a proper place. The other tools in `src/utils`
are st
On Mon, 11 Aug 2025 07:59:02 GMT, Kim Barrett wrote:
> But still need to figure out which files to (conditionally) exclude.
Maybe first make a baseline build with no optional features, and analyze the
result with this tool. And then enable each individual feature, re-build and
re-analyze, and
On Fri, 8 Aug 2025 06:32:57 GMT, Kim Barrett wrote:
>> Francesco Andreuzzi has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - magic number: 400
>> - inline
>
> src/hotspot/share/precompiled/precompiled.hpp line 70:
>
>> 68: #include "ut
On Mon, 11 Aug 2025 06:26:04 GMT, David Holmes wrote:
> > Other optional features include cds, c1, jfr, and jvmci, so files from
> > those directories also ought to be excluded.
>
> Can't these just be conditionalized with an INCLUDE_xxx check instead of
> being excluded?
Yeah, that might be
On Fri, 8 Aug 2025 22:11:32 GMT, Francesco Andreuzzi wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshing
58 matches
Mail list logo
