7 ns/op
>
> Patch, -Xint
> Benchmark Mode Cnt Score Error Units
> Wrappers.forBasicType avgt5 1068.096 ? 101.728 ns/op
> Wrappers.forPrimitive avgt5 1146.670 ? 59.142 ns/op
> Wrappers.forPrimitiveType avgt5 998.037 ? 118.
On Thu, 14 Apr 2022 11:19:04 GMT, Claes Redestad wrote:
> This patch examines and optimizes `Wrapper` lookups.
>
> First wrote a few simple microbenchmarks to verify there are actual speedups
> from using perfect hash tables in `sun.invoke.util.Wrapper` compared to
> simpler lo
On Thu, 14 Apr 2022 13:59:57 GMT, Claes Redestad wrote:
>> This patch examines and optimizes `Wrapper` lookups.
>>
>> First wrote a few simple microbenchmarks to verify there are actual speedups
>> from using perfect hash tables in `sun.invoke.util.Wrapper` compar
7 ns/op
>
> Patch, -Xint
> Benchmark Mode Cnt Score Error Units
> Wrappers.forBasicType avgt5 1068.096 ? 101.728 ns/op
> Wrappers.forPrimitive avgt5 1146.670 ? 59.142 ns/op
> Wrappers.forPrimitiveType avgt5 998.037 ? 118.
This patch examines and optimizes `Wrapper` lookups.
First wrote a few simple microbenchmarks to verify there are actual speedups
from using perfect hash tables in `sun.invoke.util.Wrapper` compared to simpler
lookup mechanisms (such as if-else or switch). Turns out there _is_ a speed-up
for
On Wed, 30 Mar 2022 12:25:52 GMT, Aleksey Shipilev wrote:
> JMH 1.35 is released, so we can bump the devkit too.
>
> Additional testing:
> - [x] JMH devkit creation
> - [x] Sample benchmarks
Marked as reviewed by redestad (Reviewer).
-
PR:
On Fri, 14 Jan 2022 17:05:45 GMT, Claes Redestad wrote:
> Change so that jib users pick up and use the latest JMH devkit.
>
> Testing: verified locally
This pull request has now been integrated.
Changeset: 9e536b64
Author: Claes Redestad
URL:
https://git.openjdk.java.net/j
Change so that jib users pick up and use the latest JMH devkit.
Testing: verified locally
-
Commit messages:
- Update jib-profile to use JMH 1.34
Changes: https://git.openjdk.java.net/jdk/pull/7090/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7090=00
Issue:
On Fri, 19 Nov 2021 01:20:43 GMT, Claes Redestad wrote:
> Use most recent devkit.
>
> Testing: staged devkit, built and verified micros locally
This pull request has now been integrated.
Changeset: b1a1bf4e
Author: Claes Redestad
URL:
https://git.openjdk.java.net/j
On Fri, 19 Nov 2021 06:32:20 GMT, Aleksey Shipilev wrote:
>> Use most recent devkit.
>>
>> Testing: staged devkit, built and verified micros locally
>
> Marked as reviewed by shade (Reviewer).
Thanks for reviews, @shipilev and @erikj79
-
PR:
Use most recent devkit.
Testing: staged devkit, built and verified micros locally
-
Commit messages:
- Update jib-profiles to use JMH 1.33 devkit
Changes: https://git.openjdk.java.net/jdk/pull/6468/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6468=00
Issue:
On Wed, 27 Oct 2021 12:28:16 GMT, Aleksey Shipilev wrote:
> Time to update the devkit to the latest JMH.
>
> Additional testing:
> - [x] Devkit generation works
> - [x] Sample benchmarks run
Marked as reviewed by redestad (Reviewer).
-
PR:
On Tue, 12 Oct 2021 21:20:53 GMT, Magnus Ihse Bursie wrote:
>> There are multiple bugs related to hsdis, calling both for added simplicity
>> in building, and allowing for multiple backends.
>>
>> The very first step is getting rid of the stand-alone Makefile and integrate
>> the build using
On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote:
> When the classlist is generated using build.tools.classlist.HelloClasslist,
> its contents may be non-deterministic due to Java thread execution order.
>
> We should sort the generated classlist to make the JDK image's contents more
>
On Mon, 2 Aug 2021 15:04:18 GMT, Aleksey Shipilev wrote:
> Thanks! (and welcome back, Claes)
You're welcome - and thanks! Good to be back..
-
PR: https://git.openjdk.java.net/jdk/pull/4954
On Mon, 2 Aug 2021 10:27:08 GMT, Aleksey Shipilev wrote:
> It is currently at 1.28, and thus misses a bunch of fixes and improvements.
> 1.32 is the latest version, and probably the last version before enabling the
> automatic detection of compiler blackholes (CODETOOLS-7903004), the change
>
On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad wrote:
> I'm not exactly sure what I intended to say in this partial comment. Removing
> it.
This pull request has now been integrated.
Changeset: 9df6cc7c
Author: Claes Redestad
URL:
https://git.openjdk.java.net/jdk/
I'm not exactly sure what I intended to say in this partial comment. Removing
it.
-
Commit messages:
- Incomplete comment in build.tools.generatecharacter.GenerateCharacter
Changes: https://git.openjdk.java.net/jdk/pull/3766/files
Webrev:
On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad wrote:
> This patch changes the otherLowercase / otherUppercase bits to be set if
> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the
> Unicode Other_Lowercase / Other_Uppercase property is set. This s
to a single table lookup,
> which appears to be healthy for performance.
>
> I also took the opportunity to clean up the somewhat dated GenerateCharacter
> utility class.
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
This patch changes the otherLowercase / otherUppercase bits to be set if either
the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode
Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup
in Character.isLowerCase/isUpperCase to a single table
On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad wrote:
> This patch changes the otherLowercase / otherUppercase bits to be set if
> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the
> Unicode Other_Lowercase / Other_Uppercase property is set. This s
On Fri, 5 Mar 2021 16:04:49 GMT, Claes Redestad wrote:
> Currently at 1.26, so there are a few good improvements and a few bug fixes -
> notably resolving a build reproducibility issue.
This pull request has now been integrated.
Changeset: 679faa69
Author: Claes Redestad
URL:
On Mon, 8 Mar 2021 14:18:27 GMT, Erik Joelsson wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Keep jib-profiles in sync
>
> Marked as reviewed by erikj (Reviewer).
Thank yo
On Fri, 5 Mar 2021 17:25:02 GMT, Erik Joelsson wrote:
>> Good!
>> Eric
>
> Should also updated jib-profiles.js Oracle builds get the new version.
Uploaded and verified jib picks up the new version.
-
PR: https://git.openjdk.java.net/jdk/pull/2848
> Currently at 1.26, so there are a few good improvements and a few bug fixes -
> notably resolving a build reproducibility issue.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Keep jib-profiles in sync
-
C
Currently at 1.26, so there are a few good improvements and a few bug fixes -
notably resolving a build reproducibility issue.
-
Commit messages:
- Update JMH devkit to 1.28
Changes: https://git.openjdk.java.net/jdk/pull/2848/files
Webrev:
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
On Mon, 18 Jan 2021 13:02:59 GMT, Aleksey Shipilev wrote:
> Current Windows GH Actions fails with:
>
> configure: using
> /cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat
> configure: Setting extracted environment variables for x86_64
> checking that Visual
On Thu, 5 Nov 2020 22:13:54 GMT, Eric Caspole wrote:
> While profiling an issue I added this sort by code size to LogCompilation,
> using -z
>
> $ java -ea -jar target/LogCompilation-1.0-SNAPSHOT.jar -z 2000-2.log | head
>
> 879 4 com.fee.fi.fo.Fum::foobar (3076 bytes)(code size: 57344)
>
. now I have a clearer
picture for it.
I'm happy to learn that 5-10 minutes for each Benchmark! Let me polish mine.
Thanks,
--lx
On 10/27/20, 3:59 AM, "Claes Redestad" wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments
On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad wrote:
> A microbenchmark with --enable-preview was added in JDK-8248135. This had the
> unintended side effect that we now had to always run with --enable-preview.
>
> With records out of preview, I think the best course o
On Wed, 28 Oct 2020 20:56:55 GMT, Eric Caspole wrote:
>> A microbenchmark with --enable-preview was added in JDK-8248135. This had
>> the unintended side effect that we now had to always run with
>> --enable-preview.
>>
>> With records out of preview, I think the best course of action now is
A microbenchmark with --enable-preview was added in JDK-8248135. This had the
unintended side effect that we now had to always run with --enable-preview.
With records out of preview, I think the best course of action now is to not
build the micros with preview enabled, and leave it for a
Hi lx,
the need to add --enable-preview is known, and it's a bug introduced a
couple of months ago thanks to a suggestion I did (without realizing
that compiling one micro with --enable-preview would poison all of
them..). This issue is tracked by a few bugs, see
Hi,
I think the idea of generating two distinct jars is workable, but I
really don't like the prospect of routinely having to move micros around
as the features they test promote from preview.
Would a manually managed list of which tests use --enable-preview work
for you? Not ideal either, but
On 2020-06-30 22:12, Magnus Ihse Bursie wrote:
Second to that a solution in the build would be preferable - if we can
come up with something that has infinitesimal impact to build times.
Are we talking about many files? Could you consider listing those files
explicitly in the makefile? That
On 2020-06-30 18:40, Magnus Ihse Bursie wrote:
An alternative workaround would be to add
@Fork(jvmArgsAppend = "--enable-preview") to all micros, whether
they use preview features or not. Perhaps that wouldn't be so bad,
actually.
That sounds like a reasonable compromise, yes.
Well, it
On 2020-06-30 17:16, Magnus Ihse Bursie wrote:
On 2020-06-30 16:48, Erik Joelsson wrote:
On 2020-06-30 07:15, Magnus Ihse Bursie wrote:
On 2020-06-30 15:13, Claes Redestad wrote:
Hi Jorn,
On 2020-06-30 14:52, Jorn Vernee wrote:
Hi Claes,
I see what you mean.
I've created a patch
we support running the per-build micro artifacts in our internal
benchmarking system on an adhoc basis, our promotion testing (where this
would have been discovered) is still a bit semi-automatic in regards to
when we roll over to a new benchmarks.jar.
/Claes
Jorn
On 27/06/2020 01:38, Claes Rede
Patch looks fine (although you might want to update the comment).
It's more concerning that I didn't catch this (seems all tests of
mine were with --enable-preview), and we'll still inconvenience users
who need to run the jar file directly. So it seems we should consider
fixing so that only
://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/
Regards, Peter
On 6/23/20 10:23 AM, Claes Redestad wrote:
On 2020-06-23 10:06, Claes Redestad wrote:
Hi,
On 2020-06-23 09:49, Peter Levart wrote:
Hi Chris, Claes,
Ok then, here's with benchmark included:
http
Hi Erik,
looks good - and a great improvement!
By my measures this removes about 12% of the total JVM cpu use when
running a Hello World with -XX:StartFlightRecording - or roughly 35ms
off the total runtime[1]
/Claes
[1]
perf stat -r 25 java -XX:StartFlightRecording HelloWorld
Before:
On 2020-06-09 00:12, Sergey Bylokhov wrote:
On 6/8/20 3:06 pm, Claes Redestad wrote:
Right, -O3 is now likely the default for most files.
I'm not sure you suggest the reported ~2% difference between -Os and
-O2/-O3 as an argument against changing to -O3 by default. It might be
statistically
On 2020-06-08 23:25, Sergey Bylokhov wrote:
On 6/8/20 2:17 pm, Claes Redestad wrote:
Not too similar, since that involves a compiler bug that basically
forced applying the -O1 flag to a critical piece of the runtime.>
Obviously there needs to be a pragmatic approach when hitting a compi
Hi!
On 2020-06-08 21:52, Sergey Bylokhov wrote:
On 6/8/20 10:45 am, Magnus Ihse Bursie wrote:
On 2020-06-08 19:31, Sergey Bylokhov wrote:
One of the reasons why -0s was used from the beginning is the
performance of the client related libraries, especially java2d.
Does anybody run or plan to
On 2020-06-04 14:39, Magnus Ihse Bursie wrote:
On 2020-06-04 11:56, Claes Redestad wrote:
Hi,
sponsoring this patch for Jorn, which ensures the -Djava.library.path
argument is always passed in when running microbenchmarks via make.
Bug: https://bugs.openjdk.java.net/browse/JDK-8246572
Hi,
sponsoring this patch for Jorn, which ensures the -Djava.library.path
argument is always passed in when running microbenchmarks via make.
Bug:https://bugs.openjdk.java.net/browse/JDK-8246572
Webrev: http://cr.openjdk.java.net/~redestad/8246572/open.00/
Testing: tier1 ongoing
Thanks!
Hi Jorn,
looks reasonable to me, and I can sponsor. A review from one of the
build maintainers would be appreciated.
/Claes
On 2020-06-03 22:01, Jorn Vernee wrote:
Hi,
Please sponsor the following patch that correctly passes
java.library.path when running micro benchmarks [1].
As a little
On 2020-06-01 20:38, Magnus Ihse Bursie wrote:
http://cr.openjdk.java.net/~redestad/8246256/open.01/
Yes, looks good.
Thanks!
/Claes
Thanks, Erik!
/Claes
On 2020-06-01 18:04, Erik Joelsson wrote:
Looks good!
/Erik
On 2020-06-01 08:54, Claes Redestad wrote:
On 2020-06-01 17:26, Magnus Ihse Bursie wrote:
On 2020-06-01 16:37, Claes Redestad wrote:
Hi,
the classlist generation mutates the interim JDK, which is usually
On 2020-06-01 17:26, Magnus Ihse Bursie wrote:
On 2020-06-01 16:37, Claes Redestad wrote:
Hi,
the classlist generation mutates the interim JDK, which is usually
part of the things we build, but can also be an external bootstrap JDK
that we shouldn't write to. Fix is to explicitly generate
as I know there is no bug for described problem yet
Thanks,
Fedor
On 01.06.2020 16:29, Erik Joelsson wrote:
Fix looks good to me then.
Do you need sponsoring help? Is there a bug number for this yet?
/Erik
On 2020-06-01 01:53, Claes Redestad wrote:
Hi Fedor,
thanks for verifying!
/Claes
Hi,
the classlist generation mutates the interim JDK, which is usually
part of the things we build, but can also be an external bootstrap JDK
that we shouldn't write to. Fix is to explicitly generate the files to
explicit locations in the build directory.
Sponsoring the fix Fedor suggested
le=$@.jsa \
-Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true \
-Duser.language=en -Duser.country=US \
--module-path $(SUPPORT_OUTPUTDIR)/classlist.jar \
Thanks,
Fedor
On 26.05.2020 18:39, Claes Redestad wrote:
Hi,
I think the proposed flags should do
Hi,
I think the proposed flags should do the right thing here. It should be
straightforward to verify since the contents of the generated files
should ideally not change at all on a standard build.
/Claes
On 2020-05-26 17:25, Erik Joelsson wrote:
Hello,
On 2020-05-26 08:00, Magnus Ihse
Looks good, Erik,
Thanks!
/Claes
On 2020-04-30 21:10, Erik Joelsson wrote:
Hello,
A minor mistake in JDK-8244036 is causing the javac server to never be
used, which is rather severly increasing build times.
Before that change, the global variable ENABLE_SJAVAC was used to
determine if
I've looked at the benchmarks that move from explicit constructors to
autoboxing and don't think we'll see any difference in behavior: all
usage during setup, and benchmarks don't seem to accidentally depend on
identity.
LGTM.
/Claes
On 2020-04-20 15:01, Erik Joelsson wrote:
This looks good to
Hi,
I took this for a spin on my setup, and see a ~500k increase in both
instructions and cycles - I guess one of your runs saw more
interference than the other.
From a startup performance point of view the advertised cost seems
more or less negligible. (For context we've optimized away 10M
Looks good to me, Magnus!
/Claes
On 2020-02-21 09:44, Magnus Ihse Bursie wrote:
Running gtest on Solaris broke with JDK-8239450, with a message like:
ld.so.1: gtestLauncher: fatal: libstlport.so.1: open failed: No such
file or directory
This breaks our CI builds.
The problem is that the
On 2020-02-05 11:43, Magnus Ihse Bursie wrote:
I'm fine with the fix.
Me too, looks good and more consistent.
/Claes
Hi Ioi,
On 2020-01-28 02:09, Ioi Lam wrote:
Hi Claes,
This looks OK to me. One thing I noticed is when running
-XX:DumpLoadedClassList from the "real" JDK image, with CDS enabled, I
get more classes such as these:
> java/lang/invoke/BoundMethodHandle$Species_LJ
>
Hi,
when generating the default classlist, doing an extra pass with a
-Xshare:dump between means the final classlist will be more in line
with what will be used at runtime.
Webrev: http://cr.openjdk.java.net/~redestad/8236272/open.00/
Bug:https://bugs.openjdk.java.net/browse/JDK-8236272
Hi,
I don't think another review is needed, but FWIW this looks good to
me!
/Claes
On 2019-12-20 11:03, Baesken, Matthias wrote:
Hi Erik, thanks for the review ! I'll remove the comment line .
May I get a second review ?
Best regards, Matthias
Hello Matthias,
Looks good except for
Thanks, Erik!
/Claes
On 2019-12-17 12:32, Erik Joelsson wrote:
Looks good.
/Erik
On 2019-12-16 04:27, Claes Redestad wrote:
Hi,
please review this patch[1] which makes the JMH behave more
in line with expectations when adding multiple flags using
the VM_OPTIONS and JAVA_OPTIONS control
Hi,
please review this patch[1] which makes the JMH behave more
in line with expectations when adding multiple flags using
the VM_OPTIONS and JAVA_OPTIONS control variables.
E.g., these fail before the patch:
make test TEST=... MICRO="VM_OPTIONS=-Xmx4g -Xms4g"
make test TEST=...
Hi Martin,
On 2019-11-27 19:03, Doerr, Martin wrote:
Hi Claes,
that kind of surprises me. I'd expect files which rather benefit from -O3 to be
far less than those which benefit from -Os.
Most performance critical code lives inside the code cache and is not dependent
on C++ compiler
Hi,
we discussed doing the opposite for Mac OS X recently, where builds are
currently set to -Os by default. -O3 helped various networking
(micro)benchmarks by up to 20%.
Rather than doing -Os by default and then cherry-pick things over to -O3
on a case-by-case basis, I'd suggest the opposite:
On 2019-11-25 18:30, Florian Weimer wrote:
That being said, relocation processing for libjvm.so adds a couple of
milliseconds to startup, and it looks like their number is growing with
each release.
This piqued my interest, so I took a quick look:
readelf --relocs libjvm.so | wc -l
8:
Hi David,
On 2019-08-26 07:12, David Holmes wrote:
Hi Claes,
This cleanup all appears fine to me.
The unused Mutex declarations might be better handled in a separate RFE
but I don't insist. You could file the RFE and still fix together in
this one changeset.
fair enough:
On 2019-08-23 17:29, Erik Joelsson wrote:
Build change looks good.
/Erik
Thanks for reviewing!
/Claes
Hi,
please review this cleanup to untangle the old bytecode verifier
(libverify). It's currently linked and loaded eagerly and early during
bootstrap.
Webrev: http://cr.openjdk.java.net/~redestad/8230043/webrev.00/
Bug:https://bugs.openjdk.java.net/browse/JDK-8230043
- removes dependency
Hi Erik,
On 2019-05-22 22:38, Erik Joelsson wrote:
This patch adds running of the Indify tool on the microbenchmark classes
after building them. The Indify tool is already present in the repo in
the java/lang/invoke test sources, so I'm building it from there.
Claes, could you take this for
) $$($1_MICRO_FORK) $$($1_MICRO_TIME) \
$$($1_MICRO_WARMUP_ITER) $$($1_MICRO_WARMUP_TIME) \
$$($1_MICRO_VM_OPTIONS) $$($1_MICRO_BASIC_OPTIONS)
$$(MICRO_OPTIONS) \
/Erik
On 2019-02-18 14:20, Claes Redestad wrote:
http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February
Pushed here: http://hg.openjdk.java.net/jdk/jdk/rev/1b40a0178b2a
/Claes
On 2019-02-19 22:41, Jorn Vernee wrote:
Great! Thanks for picking this up.
Jorn
Hi Jorn,
I'll sponsor this for jdk/jdk. I'll file a RFE, test it and push it
seeing it's already reviewed.
Thanks!
/Claes
On 2019-02-19 19:35, Jorn Vernee wrote:
Hi Erik,
I have included your suggestions:
http://cr.openjdk.java.net/~jvernee/micronative/webrev.01
I'm a committer on project
http://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002624.html>
Hi,
On 2019-02-18 22:34, Jorn Vernee wrote:
Hi Claes,
1. Does running make test rather than make test-only work?
No. Same error there. Sorry, I tried that first and then re-ran with
`test-only`. I also tried with a
Looks good, ship it!
/Claes
On 2019-02-11 11:23, Magnus Ihse Bursie wrote:
Unfortunately I introduced a build error in JDK-8218431 (Improved
platform checking). This resulted in the following error message:
lib/JvmFlags.gmk:77: extraneous text after 'ifeq' directive
This only happens for
Looks great, thanks for fixing!
Nit: I'd drop this comment "Ubuntu does this when building binutils so
should be safe."
/Claes
On 2019-01-28 23:17, Erik Joelsson wrote:
Hello,
While investigating performance with different linkers and linker
configuration, we discovered that the devkit
Looks good!
/Claes
Erik Joelsson skrev: (10 januari 2019 18:14:51 CET)
>The incremental build of exploded-image-optimize is broken. This is
>caused by a small typo in the prerequisites declaration for the recipe.
>
>Bug: https://bugs.openjdk.java.net/browse/JDK-8216489
>
>Webrev:
Thanks!
/Claes
On 2019-01-07 16:52, Erik Joelsson wrote:
Looks good.
/Erik
On 2019-01-07 16:02, Claes Redestad wrote:
Hi,
current use of -Xlint makes the build-microbenchmark fail if one
attempts to add a microbenchmark that uses non-JMH annotations.
Patch selectively disable
Hi,
current use of -Xlint makes the build-microbenchmark fail if one
attempts to add a microbenchmark that uses non-JMH annotations.
Patch selectively disable the processing lint option without disabling
other linters.
Bug: https://bugs.openjdk.java.net/browse/JDK-8216275
Patch:
diff -r
Looks good to me, and thanks for fixing!
/Claes
On 2018-12-12 01:01, Erik Joelsson wrote:
If something goes wrong in the recipe for creating the jdk image, make
will automatically delete the target of the recipe, which happens to be
bin/java in the image. This is unfortunate, because
Hi,
we're seeing a few rare, intermittent build failures on some older
machines due missing explicit dependencies on some modules (such as
java.xml). While more fine-grained option exists, we might as well
depend on exploded-image to ensure that microbenchmarks are always free
to compile
run the
benchmarks with JDK n and JDK n-1 and compare the result (is there a
build target to do this)? We can reference this JEP to get started
running the microbenchmark and refer to JMH and other documentation
for other details like developing a JMH benchmark.
Mandy
On 10/18/18 2:03
2018-10-19 13:57, Claes Redestad wrote:
On 2018-10-18 18:03, Erik Joelsson wrote:
Note that if the AOT support goes in first, we probably want to
extend that support to running micros as well.
We can do that as a follow up, depending on how much work it is.
In the meantime, I updated the patch t
On 2018-10-18 18:03, Erik Joelsson wrote:
Note that if the AOT support goes in first, we probably want to extend
that support to running micros as well.
We can do that as a follow up, depending on how much work it is.
In the meantime, I updated the patch to use JAVA rather than JAVA_SMALL
Hi,
added documentation of the new build targets, and synced up with recent
changes (thanks Erik for help dealing with some tricky merge conflicts):
http://cr.openjdk.java.net/~redestad/8061281/jdk.01/
Thanks!
/Claes
On 2018-10-09 15:15, Claes Redestad wrote:
Hi,
please review
errors down the line instead
of failing fast..
/Claes
On 2018-10-15 21:10, Claes Redestad wrote:
Hi,
please review this patch to build HelloClasslist / classlist.jar
targetting the latest bytecode version, to ensure the classlist
generation uses all recent features, e.g., indified string
Thanks!
/Claes
On 2018-10-15 22:43, Erik Joelsson wrote:
Looks good.
/Erik
On 2018-10-15 12:10, Claes Redestad wrote:
Hi,
please review this patch to build HelloClasslist / classlist.jar
targetting the latest bytecode version, to ensure the classlist
generation uses all recent features
Hi,
please review this patch to build HelloClasslist / classlist.jar
targetting the latest bytecode version, to ensure the classlist
generation uses all recent features, e.g., indified string concat (as
intended)
Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/
Bug:
Hi,
On 2018-10-09 18:50, Erik Joelsson wrote:
Hello,
In JarArchive.gmk, I would suggest using the MakeTargetDir/MakeDir
macros. If my patch goes in first, you will likely get a conflict there.
none of this will go in until the JEP is targetted, so feel free to move
ahead and we'll follow
Hi,
please review the initial build support for JEP 230: Microbenchmark
Suite[1].
Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8061281
There are some added steps to be able to build the microbenchmark suite:
export
On 2018-05-25 12:06, Magnus Ihse Bursie wrote:
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8200867-remove-jdk9-references/webrev.01
Looks good to me!
/Claes
Looks like this one: https://bugs.openjdk.java.net/browse/JDK-8201508
On 2018-04-17 17:55, Jim Laskey wrote:
cp:
/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist:
No such file or directory
make[3]: ***
Erik, Mandy, thanks for reviewing!
/Claes
On 2018-03-12 19:28, Erik Joelsson wrote:
Looks good, thanks for finding and fixing this!
Hi,
during build we use an interim image to generate some optimization
information,
e.g., the input for generate-jli-classes jlink plugin for the real
build. Turns out
jlinking the interim-image picks up the output from such training runs,
which adds
to the build time when we run incremental
I think the tool to generate these reorder files exist under
src/utils/reorder, but looking at
src/utils/reorder/Makefile it seems to have bit-rotted over the years..
the bootclasspath tricks
with rt.jar etc likely won't even work today:
# This Makefile is intended to produce new reordering
Ship it!
/Claes
On 2017-11-20 23:12, Erik Joelsson wrote:
If I run autogen.sh I get a pretty big diff. It seems some merge or
other have failed to update generated-configure.sh. This patch is just
a pure rerun of autogen.sh on the latest change.
Bug:
On 2017-10-05 11:35, Magnus Ihse Bursie wrote:
Using -Xshare:auto should mean any case where a CDS archive can't be
used (for whatever reason) should be silently ignored. I'd be more
worried if -Xshare:on didn't fail in this case!
But we're actively disabling verification of the CDS
1 - 100 of 134 matches
Mail list logo
