Re: Integrated: 8280413: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on all X64 platforms

2022-01-20 Thread Alexander Zvegintsev 
On Thu, 20 Jan 2022 20:21:17 GMT, Daniel D. Daugherty  
wrote:

> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 
> all X64 platforms.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/7168

Re: RFR: 8279918: Fix various doc typos [v2]

2022-01-14 Thread Alexander Zvegintsev 
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo  wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, 
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant 
>> formatting artefact and thus can be removed.
>> - `` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Additional typos

Client changes looks good to me.

-

Marked as reviewed by azvegint (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7063

Re: [jdk18] RFR: 8279081: ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 2 platforms

2021-12-21 Thread Alexander Zvegintsev 
On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty  
wrote:

> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on 
> 2 platforms

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk18/pull/61

Re: RFR: 8272805: Avoid looking up standard charsets [v2]

2021-08-24 Thread Alexander Zvegintsev 
On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov  wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of 
>> java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw 
>> UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by 
>> tracing the calls to the Charset.forName() by executing tier1,2,3 and 
>> desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), 
>> J2DBench(should be compatible to 1.4), some code in the network(the change 
>> there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains 14 additional 
> commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: 
> https://git.openjdk.java.net/jdk/compare/8c6e27c3...e7127644

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5210

Re: Integrated: 8268644: ProblemList serviceability/sa/ClhsdbJstackXcompStress.java in -Xcomp mode

2021-06-12 Thread Alexander Zvegintsev 
On Sat, 12 Jun 2021 13:45:49 GMT, Daniel D. Daugherty  
wrote:

> A trivial fix to ProblemList serviceability/sa/ClhsdbJstackXcompStress.java 
> in -Xcomp mode.

Marked as reviewed by azvegint (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/4478

Re: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1

2015-05-28 Thread Alexander Zvegintsev 

Hello Yasumasa,

I prefer to avoid such pragma usage, as for me code is more readable 
without it.
So we can add array-bounds to DISABLED_WARNINGS_gcc in 
make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and BUILD_LIBMLIB_IMAGE.


We can nullify row_pointers and image_data after setjmp call to remove 
warnings in splashscreen_png.c:
diff -r 729dffc8afa0 
src/java.desktop/share/native/libsplashscreen/splashscreen_png.c

--- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
+++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
@@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
 #else
 if (setjmp(png_jmpbuf(png_ptr))) {
 #endif
+row_pointers = NULL;
+image_data = NULL;
 goto done;
 }
(or declare them as volatile, but I prefer the first option).
BTW, there is another issue about this splashscreen_png.c gcc build 
failure [1].


[1] https://bugs.openjdk.java.net/browse/JDK-8080695

Thanks,

Alexander.

On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:

I've uploaded webrev:
   http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/

Please review.


Thanks,

Yasumasa


On 2015/05/28 12:19, Yasumasa Suenaga wrote:

Hi all,

I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, however, it was failed.
I found several problems:


   System:
Fedora release 22 (Twenty Two) x86_64
 - gcc-5.1.1-1.fc22.x86_64


   Problems:
 1. Array bounds check in GCC
   - jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
   - jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
   - jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
   - jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c

   It seems to be bug of GCC:
 Bug 59124: [4.8/4.9/5/6 Regression] Wrong warnings array subscript is 
above array bounds
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

   I think implementations of these files have no problem.
   So I propose to ignore warning(s) of compiler through pragma option as
   workaround when we use GCC [1].


 2. Local variables might be clobbered
   - jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c

   SplashDecodePng() calls setjmp(3).
   Some local variables initialize before setjmp() call, and use after it.
   Their initial values are only used at cleanup code (*done* label) and
   actual values are stored only after setjmp() call.
   So I think we can ignore this error through pragma option [1].


 3. Incorrect condition
   - jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c

   searchAllSourceNames() returns int value. However, branch condition in
   eventFilterRestricted_passesFilter() treats it as boolean value.


I received a comment from Erik to use --disable-warnings-as-errors,
however I could not avoid error in 3.


Thanks,

Yasumasa


[1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

Re: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1

2015-05-28 Thread Alexander Zvegintsev 

I think that you can just exclude libsplashscreen part from your fix,
since it is covered by JDK-8080695.

Thanks,

Alexander.

On 05/28/2015 02:52 PM, Yasumasa Suenaga wrote:


Hi Alexander,

Thank you for your comment.

I agree to use DISABLED_WARNINGS_gcc.

Should I make a patch afterJDK-8080695 
https://bugs.openjdk.java.net/browse/JDK-8080695 committed?


Thanks,

Yasumasa

2015/05/28 18:19 Alexander Zvegintsev 
alexander.zvegint...@oracle.com 
mailto:alexander.zvegint...@oracle.com:


Hello Yasumasa,

I prefer to avoid such pragma usage, as for me code is more
readable without it.
So we can add array-bounds to DISABLED_WARNINGS_gcc in
make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and
BUILD_LIBMLIB_IMAGE.

We can nullify row_pointers and image_data after setjmp call to
remove warnings in splashscreen_png.c:
diff -r 729dffc8afa0
src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
--- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
+++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
@@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
 #else
 if (setjmp(png_jmpbuf(png_ptr))) {
 #endif
+row_pointers = NULL;
+image_data = NULL;
 goto done;
 }
(or declare them as volatile, but I prefer the first option).
BTW, there is another issue about this splashscreen_png.c gcc
build failure [1].

[1] https://bugs.openjdk.java.net/browse/JDK-8080695

Thanks,

Alexander.


On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:

I've uploaded webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/
http://cr.openjdk.java.net/%7Eysuenaga/JDK-8081295/webrev.01/

Please review.


Thanks,

Yasumasa


On 2015/05/28 12:19, Yasumasa Suenaga wrote:

Hi all,

I tried to build jdk9/dev on Fedora22 with GCC 5.1.1,
however, it was failed.
I found several problems:


   System:
Fedora release 22 (Twenty Two) x86_64
 - gcc-5.1.1-1.fc22.x86_64


   Problems:
 1. Array bounds check in GCC
   -
jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
   -
jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
   -

jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
   -

jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c

   It seems to be bug of GCC:
 Bug 59124: [4.8/4.9/5/6 Regression] Wrong
warnings array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

   I think implementations of these files have no problem.
   So I propose to ignore warning(s) of compiler
through pragma option as
   workaround when we use GCC [1].


 2. Local variables might be clobbered
   -
jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c

   SplashDecodePng() calls setjmp(3).
   Some local variables initialize before setjmp()
call, and use after it.
   Their initial values are only used at cleanup code
(*done* label) and
   actual values are stored only after setjmp() call.
   So I think we can ignore this error through pragma
option [1].


 3. Incorrect condition
   -
jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c

   searchAllSourceNames() returns int value. However,
branch condition in
   eventFilterRestricted_passesFilter() treats it as
boolean value.


I received a comment from Erik to use
--disable-warnings-as-errors,
however I could not avoid error in 3.


Thanks,

Yasumasa


[1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

Re: [OpenJDK 2D-Dev] JDK-8081295: Build failed with GCC 5.1.1

2015-05-28 Thread Alexander Zvegintsev 

Hi Yasumasa,

the fix looks good to me.

Thanks,

Alexander.

On 05/28/2015 05:41 PM, Yasumasa Suenaga wrote:

Hi Alexander,

I've uploaded new webrev:
  http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.02/

This patch excludes libsplashscreen, and fix Awt2dLibraries.gmk .
Could you review it?


Thanks,

Yasumasa



On 2015/05/28 22:00, Alexander Zvegintsev wrote:

I think that you can just exclude libsplashscreen part from your fix,
since it is covered by JDK-8080695.

Thanks,

Alexander.

On 05/28/2015 02:52 PM, Yasumasa Suenaga wrote:


Hi Alexander,

Thank you for your comment.

I agree to use DISABLED_WARNINGS_gcc.

Should I make a patch afterJDK-8080695 
https://bugs.openjdk.java.net/browse/JDK-8080695 committed?


Thanks,

Yasumasa

2015/05/28 18:19 Alexander Zvegintsev 
alexander.zvegint...@oracle.com 
mailto:alexander.zvegint...@oracle.com:


Hello Yasumasa,

I prefer to avoid such pragma usage, as for me code is more 
readable without it.
So we can add array-bounds to DISABLED_WARNINGS_gcc in 
make/lib/Awt2dLibraries.gmk for BUILD_LIBJAVAJPEG and 
BUILD_LIBMLIB_IMAGE.


We can nullify row_pointers and image_data after setjmp call to 
remove warnings in splashscreen_png.c:
diff -r 729dffc8afa0 
src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
--- 
a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c
+++ 
b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c

@@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_
 #else
 if (setjmp(png_jmpbuf(png_ptr))) {
 #endif
+row_pointers = NULL;
+image_data = NULL;
 goto done;
 }
(or declare them as volatile, but I prefer the first option).
BTW, there is another issue about this splashscreen_png.c gcc 
build failure [1].


[1] https://bugs.openjdk.java.net/browse/JDK-8080695

Thanks,

Alexander.


On 05/28/2015 06:27 AM, Yasumasa Suenaga wrote:

I've uploaded webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8081295/webrev.01/ 
http://cr.openjdk.java.net/%7Eysuenaga/JDK-8081295/webrev.01/


Please review.


Thanks,

Yasumasa


On 2015/05/28 12:19, Yasumasa Suenaga wrote:

Hi all,

I tried to build jdk9/dev on Fedora22 with GCC 5.1.1, 
however, it was failed.

I found several problems:


   System:
Fedora release 22 (Twenty Two) x86_64
 - gcc-5.1.1-1.fc22.x86_64


   Problems:
 1. Array bounds check in GCC
   - 
jdk/src/java.desktop/share/native/libjavajpeg/jcmaster.c
   - 
jdk/src/java.desktop/share/native/libjavajpeg/jquant1.c
   - 
jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_64.c
   - 
jdk/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp_f.c


   It seems to be bug of GCC:
 Bug 59124: [4.8/4.9/5/6 Regression] Wrong 
warnings array subscript is above array bounds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

   I think implementations of these files have no 
problem.
   So I propose to ignore warning(s) of compiler 
through pragma option as

   workaround when we use GCC [1].


 2. Local variables might be clobbered
   - 
jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c


   SplashDecodePng() calls setjmp(3).
   Some local variables initialize before setjmp() 
call, and use after it.
   Their initial values are only used at cleanup 
code (*done* label) and

   actual values are stored only after setjmp() call.
   So I think we can ignore this error through 
pragma option [1].



 3. Incorrect condition
   - 
jdk/src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c


   searchAllSourceNames() returns int value. 
However, branch condition in
   eventFilterRestricted_passesFilter() treats it as 
boolean value.



I received a comment from Erik to use 
--disable-warnings-as-errors,

however I could not avoid error in 3.


Thanks,

Yasumasa


[1] 
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html