On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
>
On Mon, 15 Jan 2024 22:16:13 GMT, Glavo wrote:
> In the early development stage of JApp, I used 32-bit integers to store
> metadata such as resource size. But after using zstd to compress the
> metadata, I was surprised to find that storing them as 64-bit integers can
> actually reduce the
On Mon, 15 Jan 2024 16:08:35 GMT, Claes Redestad wrote:
> I'd very much welcome support for zstd, both for resource content and
> metadata. A larger JEP-sized project, that.
>
> I have run a quick experiment with adding a more compact header format
> (16-bit sizes for the four fields) and on
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
>
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
>
On Sun, 14 Jan 2024 17:16:37 GMT, Claes Redestad wrote:
> Pre-existing issue here is that it seems we don't handle compressed resources
> that can't fit in a single byte[], yet we take the overhead of storing
> uncompressed/compressed size as longs (4+4 byte overhead per entry). I guess
> we
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
>
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
>
On Fri, 12 Jan 2024 18:45:39 GMT, Glavo wrote:
> I generated runtime images using `jlink --compress 2 --add-modules
> java.se,jdk.unsupported,jdk.management` and then ran the following JMH
> benchmark:
>
>
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
>
I generated runtime images using `jlink --compress 2 --add-modules
java.se,jdk.unsupported,jdk.management` and then ran the following JMH
benchmark:
@Warmup(iterations = 10, time = 2)
@Measurement(iterations = 5, time = 3)
@Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g",
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Fri, 12 Jan 2024 18:17:23 GMT, Mandy Chung wrote:
> The plan [1] is to remove the old compression values `0`, `1`, `2` in the
> future and only support the zip compression `--compress zip-[0-9]`, i.e. the
> string sharing plugin will be removed as there isn't any known customer usage
> of
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Fri, 8 Dec 2023 22:38:56 GMT, Claes Redestad wrote:
>> Does anyone want to take a look at this PR?
>
>> Does anyone want to take a look at this PR?
>
> RFE: https://bugs.openjdk.org/browse/JDK-8321620 - update the bug ID and this
> should PR should reach a wider audience. I'll have some
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Mon, 20 Nov 2023 17:18:11 GMT, Per Minborg wrote:
> Can we use `Objects::checkIndex` here instead?
No, because these classes need to be compiled with `--release 8`.
Javadoc:
/**
* @implNote This class needs to maintain JDK 8 source compatibility.
*
* It is used internally in the JDK to
On Fri, 8 Dec 2023 21:35:34 GMT, Glavo wrote:
> Does anyone want to take a look at this PR?
RFE: https://bugs.openjdk.org/browse/JDK-8321620 - update the bug ID and this
should PR should reach a wider audience. I'll have some time next week to help
review.
-
PR Comment:
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
This PR significantly speeds up decompressing resources in Jimage while
significantly reducing temporary memory allocations in the process.
This will improve startup speed for runtime images generated using `jlink
--compress 1` and `jlink --compress 2` .
I generated a runtime image containing
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Thu, 9 Nov 2023 02:07:57 GMT, Chen Liang wrote:
>> This PR significantly speeds up decompressing resources in Jimage while
>> significantly reducing temporary memory allocations in the process.
>>
>> This will improve startup speed for runtime images generated using `jlink
>> --compress 1`
On Wed, 8 Nov 2023 11:55:22 GMT, Glavo wrote:
> This PR significantly speeds up decompressing resources in Jimage while
> significantly reducing temporary memory allocations in the process.
>
> This will improve startup speed for runtime images generated using `jlink
> --compress 1` and
On Mon, 20 Nov 2023 17:39:19 GMT, Glavo wrote:
>> src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java
>> line 94:
>>
>>> 92:int offset, long originalSize)
>>> throws IOException {
>>> 93: if (originalSize >
On Mon, 20 Nov 2023 23:36:51 GMT, Claes Redestad wrote:
> But to make comparisons fair you need to take care to compare apples to
> apples: is the uncompressed baseline a similar jlink image generated without
> --compress? Or the default JDK image (uncompressed, with CDS)?
The uncompressed
27 matches
Mail list logo
