On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov wrote:
> Hi, please consider the following changes:
>
> this PR addresses the issue of stringop-overflow warnings produced by GCC.
> The compiler does think that the thread pointer returned by
> `JavaThread::current()` can be null, though it cant.
On Tue, 1 Jul 2025 07:25:35 GMT, Alan Bateman wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Some tidying up relating to the state objects.
>
> test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmar
Hi, please consider the following changes:
this PR addresses the issue of stringop-overflow warnings produced by GCC. The
compiler does think that the thread pointer returned by `JavaThread::current()`
can be null, though it cant. The thread pointer ends up being an argument in
`__atomic_load`,
>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 JVMCI classes
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase. The pull request
On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote:
> Refactoring `ImageReader` to make it easy to add preview mode functionality
> for Valhalla.
>
> This PR is a large change to `ImageReader` (effectively a rewrite) but
> reduces the surface area of the API significantly, reduces code com
On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote:
> Refactoring `ImageReader` to make it easy to add preview mode functionality
> for Valhalla.
>
> This PR is a large change to `ImageReader` (effectively a rewrite) but
> reduces the surface area of the API significantly, reduces code com
On Tue, 1 Jul 2025 14:02:11 GMT, David Beaumont wrote:
>> Refactoring `ImageReader` to make it easy to add preview mode functionality
>> for Valhalla.
>>
>> This PR is a large change to `ImageReader` (effectively a rewrite) but
>> reduces the surface area of the API significantly, reduces code
On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov wrote:
> Hi, please consider the following changes:
>
> this PR addresses the issue of stringop-overflow warnings produced by GCC.
> The compiler does think that the thread pointer returned by
> `JavaThread::current()` can be null, though it cant.
> Initial benchmark to capture at least some comparative measures of
> ImageReader performance.
>
> Current results on my laptop:
>
> Benchmark Mode Cnt ScoreError
> Units
> NewImageBenchmark.warmCache_CountAllNodes avgt5 0.785 ± 0.
On Mon, 2 Jun 2025 17:00:32 GMT, Doug Simon wrote:
>> There are plans to have libgraal be built for JDK master using a version of
>> Native Image running on a JDK one version behind the current JDK. This
>> Native Image execution needs to be able to load the JVMCI classes. As such,
>> the JVMC
Refactoring `ImageReader` to make it easy to add preview mode functionality for
Valhalla.
This PR is a large change to `ImageReader` (effectively a rewrite) but reduces
the surface area of the API significantly, reduces code complexity and
increases performance/memory efficiency. The need for t
On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote:
> Refactoring `ImageReader` to make it easy to add preview mode functionality
> for Valhalla.
>
> This PR is a large change to `ImageReader` (effectively a rewrite) but
> reduces the surface area of the API significantly, reduces code com
On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie wrote:
>> 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 fortunatel
On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont wrote:
> Added jimage and jrtfs exports.
> FWIW I think these changes to the makefiles are routine enough at this point
> that we don't need to involve someone from the build team, but they can be
> approved by any reviewer.
I agree. Just addin
On Mon, 30 Jun 2025 07:02:31 GMT, Matthias Baesken wrote:
>> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like
>> runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special
>> addresses like 0 to provoke crashs.
>> However this does not work well with ubsan-en
On Mon, 30 Jun 2025 07:02:31 GMT, Matthias Baesken wrote:
>> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like
>> runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special
>> addresses like 0 to provoke crashs.
>> However this does not work well with ubsan-en
On Mon, 2 Jun 2025 17:21:21 GMT, Joe Darcy wrote:
>> I don't think this is a good way. We should not call to shell to make
>> calculations in the makefiles; if that were needed, it should be done in
>> configure. However, we are already doing this, or at least something very
>> similar. Have a
On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont wrote:
>> Initial benchmark to capture at least some comparative measures of
>> ImageReader performance.
>>
>> Current results on my laptop:
>>
>> Benchmark Mode Cnt ScoreError
>> Units
>> NewImag
On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote:
> Refactoring `ImageReader` to make it easy to add preview mode functionality
> for Valhalla.
>
> This PR is a large change to `ImageReader` (effectively a rewrite) but
> reduces the surface area of the API significantly, reduces code com
On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote:
> Refactoring `ImageReader` to make it easy to add preview mode functionality
> for Valhalla.
>
> This PR is a large change to `ImageReader` (effectively a rewrite) but
> reduces the surface area of the API significantly, reduces code com
On Fri, 27 Jun 2025 09:30:19 GMT, Matthias Baesken wrote:
> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like
> runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special
> addresses like 0 to provoke crashs.
> However this does not work well with ubsan-enable
Add some additional and more fine-grained way in which custom makefiles can be
integrated.
-
Commit messages:
- Missed hook for cleaning
- Turns out these were needed after all...
- 8361142: Improve custom hooks for makefiles
Changes: https://git.openjdk.org/jdk/pull/26060/files
23 matches
Mail list logo
