Hi Mandy, Christoph,
The code changes here all look okay to me. The idea of introducing the
notion of "trusted final fields" seems quite reasonable.
I made one editorial comment on the CSR request.
I'm unclear if the new TEST.properties file needs a copyright notice and
header. We have 706 s
@David, Erik, Magnus,
please find the answers to your comments at the bottom of this email.
@all,
David's and Erik's comments made me realize that some parts of the original
patch were stashed away and didn't make it to webrev.00. I'm truly sorry for
the confusion and inconvenience. I also agr
This patch is joint contribution from Christoph Dreis [1] and me.
Webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8247444/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8247517
This proposes to make final fields in records notmodifiable via
reflection. Field::set throws IAE
On 2020-06-15 08:12, Magnus Ihse Bursie wrote:
A few comments:
This seems like code copied from elsewhere:
57 # This evaluation is expensive and should only be done if this
target was
58 # explicitly called.
59 ifneq ($(filter build-test-libtest-jtreg-native, $(MAKECMDGOALS)), )
I do
Alan,
Indeed! Thanks for the instruction. Running
$ make test-image
and adding
-nativepath:build/linux-$(arch)-server-release/images/test/jdk/jtreg/native
to my jtreg command line allows me to pass all tests that had errors, on
aarch64 and x86_64, with and without the proposed patch.
Hi Tagir,
changes looks good to me.
Thanks!
/Claes
On 2020-06-15 18:45, Tagir Valeev wrote:
Hello!
Please review the following small change in StringConcatHelper::simpleConcat
https://bugs.openjdk.java.net/browse/JDK-8247605
https://cr.openjdk.java.net/~tvaleev/webrev/8247605/r1/
This chang
Hello!
Please review the following small change in StringConcatHelper::simpleConcat
https://bugs.openjdk.java.net/browse/JDK-8247605
https://cr.openjdk.java.net/~tvaleev/webrev/8247605/r1/
This change improves the concatenation of empty string and non-empty
string/object by reusing the internal b
+1
-Joe
On 6/15/2020 7:09 AM, Roger Riggs wrote:
Please review a test change of the test library HexPrinter.
It should be comparing against the System.lineSeparator.
diff --git a/test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
b/test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
A few comments:
This seems like code copied from elsewhere:
57 # This evaluation is expensive and should only be done if this target was
58 # explicitly called.
59 ifneq ($(filter build-test-libtest-jtreg-native, $(MAKECMDGOALS)), )
I don't agree that this is an expensive evaluation. Furt
Hi Roger,
LGTM,
Thanks,
— Igor
> On Jun 15, 2020, at 7:10 AM, Roger Riggs wrote:
>
> Roger
Please review a test change of the test library HexPrinter.
It should be comparing against the System.lineSeparator.
diff --git a/test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
b/test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
--- a/test/lib-test/jdk/test/lib/hexdump/HexPrinterT
Hello Igor,
In JtretNativeLibTest.gmk, lines 51-55 should probably be removed (or
adjusted if linking to libjvm is actually needed).
/Erik
On 2020-06-12 21:10, Igor Ignatyev wrote:
testing revealed that LingeredAppTest.java required some love, incremental
webrev w/ the fixes for LingeredApp
> On 15 Jun 2020, at 10:06, Peter Levart wrote:
>
> Hi Chris,
>
> Maybe I stamped "Enchancement" just because it does not represent a logical
> bug, but 16x regression compared to the same feature with classes could be
> characterized as performance "bug", right?
That would be the categori
> On Jun 14, 2020, at 12:45 AM, Philip Race wrote:
>
> Kim,
>
>
> Until it says in "the JDK" and not "in HotSpot" you have not addressed my
> main point.
> Please rename the JEP.
I think this JEP is primarily about updating the HotSpot-specific
subset of C++ and usage guidance to include some
Hi Chris,
Maybe I stamped "Enchancement" just because it does not represent a
logical bug, but 16x regression compared to the same feature with
classes could be characterized as performance "bug", right?
Peter
On 6/15/20 10:37 AM, Chris Hegarty wrote:
Hi Peter,
Thank you for doing this, it
Hi Peter,
Thank you for doing this, it is really appreciated. I’m going to take this
patch and run it in my local environment, after which I’ll post a reply here.
> So WDYT? Since this is still a preview feature in JDK15, is it possible to
> squeeze it into JDK15?
I think that such a change is
Hi Tagir,
On 2020-06-15 05:57, Tagir Valeev wrote:
Hello, Peter and Claes!
Cache locality might suffer a bit down the line since
String and byte[] becomes less likely to reside in the same slice
of heap memory.
There's a JEP 192 String Deduplication in G1 that does similar
optimization insid
Hi , thanks for the reviews !
Best regards, Matthias
>Look good to me.
>
>Bob.
18 matches
Mail list logo
