Re: Review request for JDK-8252124: Restore Dynalink tests

[sundararajan . athijegannathan]

Looks good.

Minor comment: not sure if you need to update copyright year on tests - 
especially because there have been changes like package removal (flat).


-Sundar

On 21/08/20 1:50 am, Attila Szegedi wrote:

Hi folks,

long time since I actively popped up here. I’m taking some time to maintain 
Dynalink, eyeing Java 16 for the changes. Since the nashorn-dev list is 
(presumably? I haven’t bother checking) defunct, I asked around and Sundar 
suggested core-libs-dev is the right list to post review requests, so here I am.

I plan to do the maintenance in three small stages, and this is the first one. 
The stages are:
- restore some Dynalink tests (they were thrown out with Nashorn)
- modernize/lint the Dynalink codebase (it was written for Java 7 originally 
for… reasons, and by now it could have diamonds, lambdas and so on)
- add support for records (the real end goal here.)

As stage 1, please review JDK-8252124 "Restore Dynalink tests" at 
 for 
.

It restores those Dynalink tests that are not dependent on Nashorn, so I again 
have a bit of a coverage as I work on it. They were taken from  
jdk14/test/nashorn/src/jdk/dynalink and moved into jdk/test/jdk/jdk/dynalink as 
proper jtreg-run tests. I flattened the package hierarchy into just the unnamed 
package (which seems to be the usual way of writing tests in the neighboring 
directories.) I added the total of 8 test classes to the “jdk_other” test 
group, it seemed the appropriate group.

Thanks,
   Attila.

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

[Yumin Qi]

Hi, Mandy


On 8/20/20 5:10 PM, Mandy Chung wrote:



On 8/19/20 10:14 PM, Yumin Qi wrote:


HI, Mandy

  Thanks for the review, I took one day off yesterday so just got a detail look 
of your reply.

On 8/19/20 1:30 PM, Mandy Chung wrote:

On 8/17/20 12:37 PM, Yumin Qi wrote:

Hi, Ioi

  Thanks for review/suggestion. I have updated the webrev at the following link:

http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/



This patch leverages the TRACE_RESOLVE output and passes the trace output to 
VM.  VM then calls GenerateJLIClassesHelper::generateMHHolderClasses to do the 
parsing and generate Holder class per the resolved LFs.   I think there are 
other cleaner alternatives implementing this.   jlink --generate-jli-classes 
plugin depends the trace output whereas -Xshare:dump does not.   It's cleaner 
to skip generating the trace output and parsing for dumping shared archive 
purpose.  In addition, the implementation needs some cleanup (I can send you 
feedback on the next revision)


Current patch did not change the existing code for JLinkPlugin part. I just 
moved the parsing code from GenerateJLIClassesPlugin.java to 
GenerateJLIClassesHelper.java since the former is an internal class to which we 
shouldn't call to generate holder classes.

Instead of relying on a system property 
"java.lang.invoke.MethodHandle.CDS_TRACE_RESOLVE", it's better to use 
jdk.internal.vm.isCDSDumpingEnabled() to detect if this is CDS dump time.


I remember we have such API to query if flag -Xshare:dump or -Xshare:on used. 
Do you mean if DumpLoadedClassList flag set? This flag is the one used to log 
class name to list file. In GenerateLinkOptData.gmk:

$(CLASSLIST_FILE): $(INTERIM_IMAGE_DIR)/bin/java$(EXE_SUFFIX) $(CLASSLIST_JAR)
    $(call MakeDir, $(LINK_OPT_DIR))
    $(call LogInfo, Generating $(patsubst $(OUTPUTDIR)/%, %, $@))
    $(call LogInfo, Generating $(patsubst $(OUTPUTDIR)/%, %, 
$(JLI_TRACE_FILE)))
    $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -XX:DumpLoadedClassList=$@.raw 
\
    -Duser.language=en -Duser.country=US \
    -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \
    build.tools.classlist.HelloClasslist $(LOG_DEBUG)
    $(GREP) -v HelloClasslist $@.raw > $@.interim
    $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -Xshare:dump \
    -XX:SharedClassListFile=$@.interim -XX:SharedArchiveFile=$@.jsa \
    -Xmx128M -Xms128M $(LOG_INFO)
    $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java 
-XX:DumpLoadedClassList=$@.raw.2 \
    -XX:SharedClassListFile=$@.interim -XX:SharedArchiveFile=$@.jsa \
    -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true \
    -Duser.language=en -Duser.country=US \
    --module-path $(SUPPORT_OUTPUTDIR)/classlist.jar \
    -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \
    build.tools.classlist.HelloClasslist \
    2> $(LINK_OPT_DIR)/stderr > $(JLI_TRACE_FILE) \
    || ( \
    exitcode=$$? ; \
    $(ECHO) "ERROR: Failed to generate link optimization data." \
    "This is likely a problem with the newly built JVM/JDK." ; \
    $(CAT) $(LINK_OPT_DIR)/stderr $(JLI_TRACE_FILE) ; \
    exit $$exitcode \
    )
    $(GREP) -v HelloClasslist $@.raw.2 > $@

The $(JLI_TRACE_FILE) is generated with both -XX:DumpLoadedClassList and 
-Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true, in current implementation, 
DumpLoadedClassList will turn on property 
java.lang.invoke.MethodHandle.CDS_TRACE_RESOLVE=true. So the same output sent 
to stdout and log file DumpLoadedClassList specified.



These entries are duplicated in two different files: one for jlink 
--generate-jli-classes plugin and another for CDS use.  CDS -Xshare:dump 
attempts to do what jlink plugin does but writes those generated classes in to 
shared archive.

Like the above make logic to build JDK image, the same entries are written in 
both default-jli-trace.txt via System.out and to classlist via JNI call to the 
VM.  I guess VM also implements the logic to do some kind of diffing and write 
to CDS archive.


In current implementation, vm side only records the line as from TRACE_RESOLVE 
at pre-run with -XX:DumpLoadedClassList, and at dump time, call back to java 
for parsing those recordings and generating the holder classes, this uses the 
existing JLI code.


Now instead of this property, using a vm interface API to query if this flag is 
set, I think it is better choice. But here I am NOT sure I understand your 
suggestion, I think there are two choices:

1) Using DumpLoadedClassList to collect TRACE_RESOLVE but not via 
CDS_TRACE_RESOLVE, using new API to query if DumpLoadedClassList is set

2) Do not use DumpLoadedClassList, when -Xshare:dump collecting those name, 
type and holder name to regenerate holder classes?



I misunderstood that this CDS_TRACE_RESOLVE flag is set during -Xshare:dump 
time.

Ioi has clarified to me offline 

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

[Mandy Chung]

On 8/19/20 10:14 PM, Yumin Qi wrote:


HI, Mandy

  Thanks for the review, I took one day off yesterday so just got a 
detail look of your reply.


On 8/19/20 1:30 PM, Mandy Chung wrote:

On 8/17/20 12:37 PM, Yumin Qi wrote:

Hi, Ioi

  Thanks for review/suggestion. I have updated the webrev at the 
following link:


http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/



This patch leverages the TRACE_RESOLVE output and passes the trace 
output to VM.  VM then calls 
GenerateJLIClassesHelper::generateMHHolderClasses to do the parsing 
and generate Holder class per the resolved LFs.   I think there are 
other cleaner alternatives implementing this. jlink 
--generate-jli-classes plugin depends the trace output whereas 
-Xshare:dump does not.   It's cleaner to skip generating the trace 
output and parsing for dumping shared archive purpose.  In addition, 
the implementation needs some cleanup (I can send you feedback on the 
next revision)


Current patch did not change the existing code for JLinkPlugin part. I 
just moved the parsing code from GenerateJLIClassesPlugin.java to 
GenerateJLIClassesHelper.java since the former is an internal class to 
which we shouldn't call to generate holder classes.
Instead of relying on a system property 
"java.lang.invoke.MethodHandle.CDS_TRACE_RESOLVE", it's better to use 
jdk.internal.vm.isCDSDumpingEnabled() to detect if this is CDS dump time.


I remember we have such API to query if flag -Xshare:dump or 
-Xshare:on used. Do you mean if DumpLoadedClassList flag set? This 
flag is the one used to log class name to list file. In 
GenerateLinkOptData.gmk:


$(CLASSLIST_FILE): $(INTERIM_IMAGE_DIR)/bin/java$(EXE_SUFFIX) 
$(CLASSLIST_JAR)

    $(call MakeDir, $(LINK_OPT_DIR))
    $(call LogInfo, Generating $(patsubst $(OUTPUTDIR)/%, %, $@))
    $(call LogInfo, Generating $(patsubst $(OUTPUTDIR)/%, %, 
$(JLI_TRACE_FILE)))
    $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java 
-XX:DumpLoadedClassList=$@.raw \

    -Duser.language=en -Duser.country=US \
    -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \
    build.tools.classlist.HelloClasslist $(LOG_DEBUG)
    $(GREP) -v HelloClasslist $@.raw > $@.interim
    $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java -Xshare:dump \
    -XX:SharedClassListFile=$@.interim 
-XX:SharedArchiveFile=$@.jsa \

    -Xmx128M -Xms128M $(LOG_INFO)
    $(FIXPATH) $(INTERIM_IMAGE_DIR)/bin/java 
-XX:DumpLoadedClassList=$@.raw.2 \
    -XX:SharedClassListFile=$@.interim 
-XX:SharedArchiveFile=$@.jsa \

    -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true \
    -Duser.language=en -Duser.country=US \
    --module-path $(SUPPORT_OUTPUTDIR)/classlist.jar \
    -cp $(SUPPORT_OUTPUTDIR)/classlist.jar \
    build.tools.classlist.HelloClasslist \
    2> $(LINK_OPT_DIR)/stderr > $(JLI_TRACE_FILE) \
    || ( \
    exitcode=$$? ; \
    $(ECHO) "ERROR: Failed to generate link optimization 
data." \
    "This is likely a problem with the newly built 
JVM/JDK." ; \

    $(CAT) $(LINK_OPT_DIR)/stderr $(JLI_TRACE_FILE) ; \
    exit $$exitcode \
    )
    $(GREP) -v HelloClasslist $@.raw.2 > $@

The $(JLI_TRACE_FILE) is generated with both -XX:DumpLoadedClassList 
and -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true, in current 
implementation, DumpLoadedClassList will turn on property 
java.lang.invoke.MethodHandle.CDS_TRACE_RESOLVE=true. So the same 
output sent to stdout and log file DumpLoadedClassList specified.




These entries are duplicated in two different files: one for jlink 
--generate-jli-classes plugin and another for CDS use.  CDS -Xshare:dump 
attempts to do what jlink plugin does but writes those generated classes 
in to shared archive.


Like the above make logic to build JDK image, the same entries are 
written in both default-jli-trace.txt via System.out and to classlist 
via JNI call to the VM.  I guess VM also implements the logic to do some 
kind of diffing and write to CDS archive.


Now instead of this property, using a vm interface API to query if 
this flag is set, I think it is better choice. But here I am NOT sure 
I understand your suggestion, I think there are two choices:


1) Using DumpLoadedClassList to collect TRACE_RESOLVE but not via 
CDS_TRACE_RESOLVE, using new API to query if DumpLoadedClassList is set


2) Do not use DumpLoadedClassList, when -Xshare:dump collecting those 
name, type and holder name to regenerate holder classes?




I misunderstood that this CDS_TRACE_RESOLVE flag is set during 
-Xshare:dump time.


Ioi has clarified to me offline that this step is actually part of 
-XX:DumpLoadedClassList and includes these TRACE_RESOLVE logs to the 
given class list file, i.e. you repurpose the class list file to include 
the log output that was initially designed for jlink plugin.


To me, I'd prefer to see this support depending 

Re: RFR: JDK-8251988: jpackage --runtime-image fails on mac when using JDK11 based runtime.

[Alexey Semenyuk]

Andy,

I'd replace 'File.separator' with '/' to make value of 
'jpackage.app-path' property platform independent.
It would be also good to have a unit test verifying values of the new 
properties.


- Alexey

On 8/20/2020 5:44 PM, Andy Herrick wrote:

Please review the jpackage fix at [1] to issue [2].

This fixes the problem loading libjli.dylib as well as  providing some 
useful generic system properties.


/Andy


[1] - http://cr.openjdk.java.net/~herrick/8251988/webrev.02/ 



[2] - https://bugs.openjdk.java.net/browse/JDK-8251988

RFR: JDK-8251988: jpackage --runtime-image fails on mac when using JDK11 based runtime.

[Andy Herrick]

Please review the jpackage fix at [1] to issue [2].

This fixes the problem loading libjli.dylib as well as  providing some 
useful generic system properties.


/Andy


[1] - http://cr.openjdk.java.net/~herrick/8251988/webrev.02/ 



[2] - https://bugs.openjdk.java.net/browse/JDK-8251988

Re: Review request for JDK-8251538: Modernize and lint Dynalink code

[Remi Forax]

- Mail original -
> De: "Attila Szegedi" 
> À: "core-libs-dev" 
> Envoyé: Jeudi 20 Août 2020 22:40:53
> Objet: Review request for JDK-8251538: Modernize and lint Dynalink code

> Following up on the previous e-mail, here’s the modernization and linting work
> on the existing Dynalink codebase:
> 
> Please review JDK-8251538 "Modernize and lint Dynalink code" at
>  for
> 
> 
> The Jira issue has a full enumeration of kinds of changes I did here; they’re
> mostly all source text removals :-)
> 
> Oh, BTW, I really got an inspiration for adding “public static ClassValue
> computingValue(Function, T> f)” method to ClassValue class, similar 
> to
> Comparator.comparing. It’d allow lambdifying class values. (If you’re
> listening, John :-) I suspect it being in java.lang would be a JCP-level 
> change
> so I kind-of don’t want to take it upon myself…)

this is also very similar to 
https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/ThreadLocal.html#withInitial(java.util.function.Supplier)

and the proposed signature doesn't have the right wildcards, it should be
  public static ClassValue computingValue(Function, ? 
extends T> f)
  

> 
> Thanks,
>   Attila.

regards,
Rémi

Re: RFR 8252128: Remove javax.transaction Exception references

[Roger Riggs]

Hi Lance,

Looks fine.

Thanks, Roger


On 8/20/20 4:58 PM, Lance Andersen wrote:

Hi all,

The following patch removes some extraneous references to javax.transaction 
exceptions and removes a couple of unused fields that represented serialized 
versions of the exceptions.  This was missed in the removal of the CORBA and 
Java EE modules.

The webrev can be found at:  
http://cr.openjdk.java.net/~lancea/8252128/webrev.00/

Mach5 jdk-tier1, jdk-tier2, jdk-tier3 are clean (as expected)

Best
Lance
--




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR 8251989: Hex encoder and decoder utility

[Roger Riggs]

Hi Mark,

On 8/20/20 3:10 PM, mark.reinh...@oracle.com wrote:

2020/8/19 14:14:56 -0700, roger.ri...@oracle.com:

Please review a java.util.Hex API to encode and decode hexadecimal
strings to and from byte arrays.

JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html

This mostly looks good -- it’ll be nice to have a standard utility for
this sort of thing.

A few comments:

   - Why do the short-form `encoder` factory methods return encoders that
 produce upper-case hex strings?  `Integer::toHexString` and other
 existing `toHex` methods return lower-case hex strings.  That’s also
 what you get from common Unix CLI tools (e.g., `od -tx1`).

 Please consider changing these methods to return lower-case encoders.


It's (almost) a toss up and easy to change; many of the existing uses 
produce uppercase.


Perhaps the short form no-arg should be replaced with a short form 
constructor that
takes true/false, so it is explicit at the use site or put the case in 
the name.

encodeToUpper(), encodeToLower().
(A boolean parameter is not very informative, a enum would be better but 
perhaps a bit heavyweight).


   - Is it worth having static `Hex.encode(byte[])` and
 `Hex.decode(CharSequence)` convenience methods for the simplest
 cases?
There was some discussion of that but it idea was to minimize the 
surface area.


   - [Warning: Bikeshed] The verbs “encode” and “decode” seem unfortunate.

 Over in `java.nio.charsets` we have encoders that transform
 characters to bytes, and decoders that transform bytes to characters.
 The coded thing is the bytes; the uncoded thing is the characters.

 In `java.util` we already have the `Base64` class, which provides
 encoders that transform bytes to characters, and decoders that
 transform characters to bytes.  The coded thing is the characters;
 the uncoded thing is the bytes.

 The use of “encode” and “decode” in `Base64` was likely inspired by
 the fact that the format has been known as “base 64 encoding” for
 decades, having originated as a hack for transporting non-ASCII data
 via SMTP.  Developers looking to do base-64 operations will, thus,
 expect this terminology.

The bias of encoding vs decoding terminology is subtle, based the 'native'
form of the data. For the Charset classes, the native form of the data 
is characters,
and the encoded form is bytes.  For Base64, the native form of the data 
is bytes,

and the encoded form is Base64 lines.



 Here you’re proposing that the `Hex` class follow the `Base64` class.
 Consistency with existing nearby APIs is a worthy goal.  If I were
 just looking to convert a byte array into a readable hex string,
 however, I’d probably want to “format” it rather than “encode” it,
 something like `String.format("%x")` on steroids.  Likewise, if I
 were looking to convert a hex string into bytes then I’d want to
 “parse” it rather than “decode” it, i.e., `Integer::parseInt` on
 steroids.

 If you were to rename the nested classes to `Hex.Formatter` and
 `Hex.Parser`, and rename all methods accordingly, then this API would
 be inconsistent with the nearby `Base64` but likely more consistent
 with developer expectations.

 (`Hex` is already inconsistent with `Base64` in that it doesn’t
  prefix the names of its factory methods with `get`, which is a good
  thing.)

The question is at what level of control does "encoding" become formatting.
There are very few formatting features in the API, no control of leading 
zeros, no control
over indicental whitespace, and no control over width.  Similarly with 
parsing,
what flexibility does parsing imply that decoding does not, is 
whitespace ignored, line endings/joins, etc.


Thanks, Roger



- Mark

RFR 8252128: Remove javax.transaction Exception references

[Lance Andersen]

HI all,

The following patch removes some extraneous references to javax.transaction 
exceptions and removes a couple of unused fields that represented serialized 
versions of the exceptions.  This was missed in the removal of the CORBA and 
Java EE modules.

The webrev can be found at:  
http://cr.openjdk.java.net/~lancea/8252128/webrev.00/

Mach5 jdk-tier1, jdk-tier2, jdk-tier3 are clean (as expected)

Best
Lance
--




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR 8251989: Hex encoder and decoder utility

[Roger Riggs]

Hi Max,

The idea was to keep all the Hex functions together.

Its a bit of a mismatch with StringBuilder; StringBuilder doesn't deal 
with arrays and is pretty bulky as it is.
And StringBuilder doesn't have a corresponding parse companion; the 
string to byte[] array functions are needed to.


True, the prefix and suffix are conveniences and could be removed. By 
knowing it them as part of the encode operation it is possible to 
allocate the buffer exactly.


Thanks, Roger


On 8/20/20 3:02 PM, Weijun Wang wrote:

How about StringBuilder::appendHex instead of Encoder::encode(SB, byte[])? Then 
we don’t need to break the chain when appending many different things to a 
StringBuilder.

Also, are prefix and suffix really useful? One can easily add them.

Thanks,
Max


On Aug 19, 2020, at 5:14 PM, Roger Riggs  wrote:

Please review a java.util.Hex API to encode and decode hexadecimal strings to 
and from byte arrays.

Within the JDK and JDK tests there are multiple implementations to encode and 
decode
hexadecimal strings to byte arrays. Hex encoders and decoders support
upper or lower case hexadecimal characters, delimiters, prefix, and suffix.
The API is modeled after the java.util.Base64 API providing static factories,
immutable threadsafe instances with methods to encode to and decode from
string and StringBuilder.

JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html

Webrev for Hex encoder and decoder:
http://cr.openjdk.java.net/~rriggs/webrev-hex-encoder-8251989

Webrev for applying to java.security:
http://cr.openjdk.java.net/~rriggs/webrev-hex-security-8252055

CSR:
https://bugs.openjdk.java.net/browse/JDK-8251991

Issue for API and a few uses:
https://bugs.openjdk.java.net/browse/JDK-8251989

Issue for Use in java.security and tests:
https://bugs.openjdk.java.net/browse/JDK-8252055

Review request for JDK-8251538: Modernize and lint Dynalink code

[Attila Szegedi]

Following up on the previous e-mail, here’s the modernization and linting work 
on the existing Dynalink codebase:

Please review JDK-8251538 "Modernize and lint Dynalink code" at 
 for 


The Jira issue has a full enumeration of kinds of changes I did here; they’re 
mostly all source text removals :-)

Oh, BTW, I really got an inspiration for adding “public static ClassValue 
computingValue(Function, T> f)” method to ClassValue class, similar to 
Comparator.comparing. It’d allow lambdifying class values. (If you’re 
listening, John :-) I suspect it being in java.lang would be a JCP-level change 
so I kind-of don’t want to take it upon myself…)

Thanks,
  Attila.

Review request for JDK-8252124: Restore Dynalink tests

[Attila Szegedi]

Hi folks,

long time since I actively popped up here. I’m taking some time to maintain 
Dynalink, eyeing Java 16 for the changes. Since the nashorn-dev list is 
(presumably? I haven’t bother checking) defunct, I asked around and Sundar 
suggested core-libs-dev is the right list to post review requests, so here I am.

I plan to do the maintenance in three small stages, and this is the first one. 
The stages are:
- restore some Dynalink tests (they were thrown out with Nashorn)
- modernize/lint the Dynalink codebase (it was written for Java 7 originally 
for… reasons, and by now it could have diamonds, lambdas and so on)
- add support for records (the real end goal here.)

As stage 1, please review JDK-8252124 "Restore Dynalink tests" at 
 for 
. 

It restores those Dynalink tests that are not dependent on Nashorn, so I again 
have a bit of a coverage as I work on it. They were taken from  
jdk14/test/nashorn/src/jdk/dynalink and moved into jdk/test/jdk/jdk/dynalink as 
proper jtreg-run tests. I flattened the package hierarchy into just the unnamed 
package (which seems to be the usual way of writing tests in the neighboring 
directories.) I added the total of 8 test classes to the “jdk_other” test 
group, it seemed the appropriate group.

Thanks,
  Attila.

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

[Roger Riggs]

Hi Christoph,

Looks good.

Note that Claes added the cases for Object.class and int.class
to maximize the performance of those common cases.

I'll sponsor the change.

Thanks, Roger


On 8/20/20 2:01 PM, Christoph Dreis wrote:

Hi Roger,

thanks for taking a look!


Though I wonder if performs differently than just calling  t.descriptorString()?

Seems pretty much to be the same.
The difference of 1 ns for the primitive case is a bit weird, but I guess at 
this levels it's also possible to have fluctuations here and there.

Long.class
Benchmark  Mode  Cnt Score 
Error   Units
MyBenchmark.unparseChristoph   avgt   1036,995 ±   
0,748   ns/op
MyBenchmark.unparseChristoph:·gc.alloc.rate.norm   avgt   10   168,009 ±   
0,001B/op
MyBenchmark.unparseRoger   avgt   1036,857 ±   
1,472   ns/op
MyBenchmark.unparseRoger:·gc.alloc.rate.norm   avgt   10   168,009 ±   
0,001B/op
MyBenchmark.unparseOld avgt   1053,926 ±   
1,991   ns/op
MyBenchmark.unparseOld:·gc.alloc.rate.norm avgt   10   256,014 ±   
0,001B/op
  
long.class

Benchmark  Mode  Cnt Score 
Error   Units
MyBenchmark.unparseChristoph   avgt   10 5,184 ±   
0,168   ns/op
MyBenchmark.unparseChristoph:·gc.alloc.rate.norm   avgt   10≈ 10⁻⁶  
B/op
MyBenchmark.unparseRoger   avgt   10 6,149 ±   
0,238   ns/op
MyBenchmark.unparseRoger:·gc.alloc.rate.norm   avgt   10≈ 10⁻⁶  
B/op
MyBenchmark.unparseOld avgt   1011,236 ±   
0,464   ns/op
MyBenchmark.unparseOld:·gc.alloc.rate.norm avgt   1080,003 ±   
0,001B/op


It should be equivalent, without extra checks.

It seems to be indeed equivalent, so I would change my proposal to the 
following.
I would keep the check for Object.class and int.class above as they seem to be 
the most common.
At least Object.class is good to have to avoid unnecessary String allocations 
in from descriptorString() imho.

=== PATCH ===
--- a/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 13 09:33:28 2020 -0700
+++ b/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 20 19:44:57 2020 +0200
@@ -110,9 +110,7 @@
  } else if (type == int.class) {
  return "I";
  }
-StringBuilder sb = new StringBuilder();
-unparseSig(type, sb);
-return sb.toString();
+return type.descriptorString();
  }

What do you think?

Cheers,
Christoph

On 8/13/20 1:31 PM, Christoph Dreis wrote:

Hi,

I just stumbled upon sun.invoke.util.BytecodeDescriptor.unparse that seems to 
unnecessarily create a StringBuilder and checks for the given type to be of 
Object.class twice in certain scenarios.

When I apply the attached patch below with the following isolated benchmark:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
public class MyBenchmark {

@State(Scope.Thread)
public static class BenchmarkState {
private Class test = String.class; // long.class;
}

@Benchmark
public String unparseNew(BenchmarkState state) {
return BytecodeDescriptor.unparseNew(state.test);
}

@Benchmark
public String unparseOld(BenchmarkState state) {
return BytecodeDescriptor.unparseOld(state.test);
}
}

I get the following results:
String.class
Benchmark   Mode  Cnt Score Error   
Units
MyBenchmark.unparseNew  avgt   1047,207 ±   1,918   
ns/op
MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10   232,011 ±   0,002
B/op
MyBenchmark.unparseOld  avgt   1087,197 ±  22,843   
ns/op
MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   10   384,020 ±   0,001
B/op

long.class

Benchmark   Mode  Cnt Score Error   
Units
MyBenchmark.unparseNew  avgt   10 4,996 ±0,022   
ns/op
MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10≈ 10⁻⁶   
B/op
MyBenchmark.unparseOld  avgt   1013,303 ±6,305   
ns/op
MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   1080,003 ±0,001
B/op

As you can see the new way makes things allocation free for primitives and also 
improves normal classes.

It seems like a relatively trivial improvement. In case you think this is 
worthwhile, I would appreciate it if someone could sponsor the change.

Cheers,
Christoph

=== PATCH ===
--- 

Re: RFR 8251989: Hex encoder and decoder utility

[mark . reinhold]

2020/8/19 14:14:56 -0700, roger.ri...@oracle.com:
> Please review a java.util.Hex API to encode and decode hexadecimal 
> strings to and from byte arrays.
> 
> JavaDoc:
> http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html

This mostly looks good -- it’ll be nice to have a standard utility for
this sort of thing.

A few comments:

  - Why do the short-form `encoder` factory methods return encoders that
produce upper-case hex strings?  `Integer::toHexString` and other
existing `toHex` methods return lower-case hex strings.  That’s also
what you get from common Unix CLI tools (e.g., `od -tx1`).

Please consider changing these methods to return lower-case encoders.

  - Is it worth having static `Hex.encode(byte[])` and
`Hex.decode(CharSequence)` convenience methods for the simplest
cases?

  - [Warning: Bikeshed] The verbs “encode” and “decode” seem unfortunate.

Over in `java.nio.charsets` we have encoders that transform
characters to bytes, and decoders that transform bytes to characters.
The coded thing is the bytes; the uncoded thing is the characters.

In `java.util` we already have the `Base64` class, which provides
encoders that transform bytes to characters, and decoders that
transform characters to bytes.  The coded thing is the characters;
the uncoded thing is the bytes.

The use of “encode” and “decode” in `Base64` was likely inspired by
the fact that the format has been known as “base 64 encoding” for
decades, having originated as a hack for transporting non-ASCII data
via SMTP.  Developers looking to do base-64 operations will, thus,
expect this terminology.

Here you’re proposing that the `Hex` class follow the `Base64` class.
Consistency with existing nearby APIs is a worthy goal.  If I were
just looking to convert a byte array into a readable hex string,
however, I’d probably want to “format” it rather than “encode” it,
something like `String.format("%x")` on steroids.  Likewise, if I
were looking to convert a hex string into bytes then I’d want to
“parse” it rather than “decode” it, i.e., `Integer::parseInt` on
steroids.

If you were to rename the nested classes to `Hex.Formatter` and
`Hex.Parser`, and rename all methods accordingly, then this API would
be inconsistent with the nearby `Base64` but likely more consistent
with developer expectations.

(`Hex` is already inconsistent with `Base64` in that it doesn’t
 prefix the names of its factory methods with `get`, which is a good
 thing.)

- Mark

Re: RFR 8251989: Hex encoder and decoder utility

[Weijun Wang]

How about StringBuilder::appendHex instead of Encoder::encode(SB, byte[])? Then 
we don’t need to break the chain when appending many different things to a 
StringBuilder.

Also, are prefix and suffix really useful? One can easily add them.

Thanks,
Max

> On Aug 19, 2020, at 5:14 PM, Roger Riggs  wrote:
> 
> Please review a java.util.Hex API to encode and decode hexadecimal strings to 
> and from byte arrays.
> 
> Within the JDK and JDK tests there are multiple implementations to encode and 
> decode
> hexadecimal strings to byte arrays. Hex encoders and decoders support
> upper or lower case hexadecimal characters, delimiters, prefix, and suffix.
> The API is modeled after the java.util.Base64 API providing static factories,
> immutable threadsafe instances with methods to encode to and decode from
> string and StringBuilder.
> 
> JavaDoc:
> http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html
> 
> Webrev for Hex encoder and decoder:
>http://cr.openjdk.java.net/~rriggs/webrev-hex-encoder-8251989
> 
> Webrev for applying to java.security:
>http://cr.openjdk.java.net/~rriggs/webrev-hex-security-8252055
> 
> CSR:
>https://bugs.openjdk.java.net/browse/JDK-8251991
> 
> Issue for API and a few uses:
>https://bugs.openjdk.java.net/browse/JDK-8251989
> 
> Issue for Use in java.security and tests:
>https://bugs.openjdk.java.net/browse/JDK-8252055
> 

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

[Mandy Chung]

On 8/20/20 11:01 AM, Christoph Dreis wrote:

=== PATCH ===
--- a/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 13 09:33:28 2020 -0700
+++ b/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 20 19:44:57 2020 +0200
@@ -110,9 +110,7 @@
  } else if (type == int.class) {
  return "I";
  }
-StringBuilder sb = new StringBuilder();
-unparseSig(type, sb);
-return sb.toString();
+return type.descriptorString();
  }

What do you think?



This looks fine.   FYI.  unparseSig(Class t, StringBuilder sb) was 
already changed to call `Class::descriptorString` by JDK-8238358.   It's 
redundant for unparse(Class t) to call unparseSig.


Mandy

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

[Christoph Dreis]

Hi Roger,

thanks for taking a look!

> Though I wonder if performs differently than just calling  
> t.descriptorString()?

Seems pretty much to be the same.
The difference of 1 ns for the primitive case is a bit weird, but I guess at 
this levels it's also possible to have fluctuations here and there.

Long.class  
 
Benchmark  Mode  Cnt Score 
Error   Units 
MyBenchmark.unparseChristoph   avgt   1036,995 ±   
0,748   ns/op 
MyBenchmark.unparseChristoph:·gc.alloc.rate.norm   avgt   10   168,009 ±   
0,001B/op 
MyBenchmark.unparseRoger   avgt   1036,857 ±   
1,472   ns/op 
MyBenchmark.unparseRoger:·gc.alloc.rate.norm   avgt   10   168,009 ±   
0,001B/op 
MyBenchmark.unparseOld avgt   1053,926 ±   
1,991   ns/op 
MyBenchmark.unparseOld:·gc.alloc.rate.norm avgt   10   256,014 ±   
0,001B/op 

 
long.class  
 
Benchmark  Mode  Cnt Score 
Error   Units 
MyBenchmark.unparseChristoph   avgt   10 5,184 ±   
0,168   ns/op 
MyBenchmark.unparseChristoph:·gc.alloc.rate.norm   avgt   10≈ 10⁻⁶  
B/op 
MyBenchmark.unparseRoger   avgt   10 6,149 ±   
0,238   ns/op 
MyBenchmark.unparseRoger:·gc.alloc.rate.norm   avgt   10≈ 10⁻⁶  
B/op 
MyBenchmark.unparseOld avgt   1011,236 ±   
0,464   ns/op 
MyBenchmark.unparseOld:·gc.alloc.rate.norm avgt   1080,003 ±   
0,001B/op

> It should be equivalent, without extra checks.

It seems to be indeed equivalent, so I would change my proposal to the 
following.
I would keep the check for Object.class and int.class above as they seem to be 
the most common.
At least Object.class is good to have to avoid unnecessary String allocations 
in from descriptorString() imho.

=== PATCH ===
--- a/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 13 09:33:28 2020 -0700
+++ b/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 20 19:44:57 2020 +0200
@@ -110,9 +110,7 @@
 } else if (type == int.class) {
 return "I";
 }
-StringBuilder sb = new StringBuilder();
-unparseSig(type, sb);
-return sb.toString();
+return type.descriptorString();
 }

What do you think?

Cheers,
Christoph

On 8/13/20 1:31 PM, Christoph Dreis wrote:
> Hi,
>
> I just stumbled upon sun.invoke.util.BytecodeDescriptor.unparse that seems to 
> unnecessarily create a StringBuilder and checks for the given type to be of 
> Object.class twice in certain scenarios.
>
> When I apply the attached patch below with the following isolated benchmark:
>
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Thread)
> public class MyBenchmark {
>
>   @State(Scope.Thread)
>   public static class BenchmarkState {
>   private Class test = String.class; // long.class;
>   }
>
>   @Benchmark
>   public String unparseNew(BenchmarkState state) {
>   return BytecodeDescriptor.unparseNew(state.test);
>   }
>
>   @Benchmark
>   public String unparseOld(BenchmarkState state) {
>   return BytecodeDescriptor.unparseOld(state.test);
>   }
> }
>
> I get the following results:
> String.class
> Benchmark   Mode  Cnt Score Error   
> Units
> MyBenchmark.unparseNew  avgt   1047,207 ±   1,918   
> ns/op
> MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10   232,011 ±   0,002
> B/op
> MyBenchmark.unparseOld  avgt   1087,197 ±  22,843   
> ns/op
> MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   10   384,020 ±   0,001
> B/op
>   
>  
> long.class
> Benchmark   Mode  Cnt Score Error   
> Units
> MyBenchmark.unparseNew  avgt   10 4,996 ±0,022   
> ns/op
> MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10≈ 10⁻⁶   
> B/op
> MyBenchmark.unparseOld  avgt   1013,303 ±6,305   
> ns/op
> MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   1080,003 ±0,001
> B/op
>
> As you can see the new way makes things allocation free for primitives and 
> also improves normal classes.
>
> It seems like a relatively trivial improvement. In case you think this is 
> worthwhile, I would appreciate it if someone could sponsor the change.
>
> Cheers,
> Christoph
>
> 

RFR: JDK-8252113: Move jfr man page into jfr module

[Adam Farley8]

Hi All,

Should jfr.1 be moved from java.base to the jdk.jfr module source 
directory, as indicated here?

Webrev: http://cr.openjdk.java.net/~afarley/8252113/webrev/

Bug: https://bugs.openjdk.java.net/browse/JDK-8252113

It seems to me that it should, as man pages should be with their code (as 
appears the case in other modules), but perhaps there's something I'm not 
seeing.

Thoughts and reviews welcome.

Best Regards

Adam Farley 
IBM Runtimes

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR 8251989: Hex encoder and decoder utility

[Roger Riggs]

Hi Raffaello,

Will do, an oversight in updating the example.

Thanks, Roger


On 8/20/20 12:46 PM, Raffaello Giulietti wrote:

Hi Roger,

in the examples in the javadoc you might want to correct the first 
argument to Hex.encoder and Hex.decoder to "," to be consistent with 
the narrative.



Greetings
Raffaello




JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html 

RFR 8251989: Hex encoder and decoder utility

[Raffaello Giulietti]

Hi Roger,

in the examples in the javadoc you might want to correct the first 
argument to Hex.encoder and Hex.decoder to "," to be consistent with the 
narrative.



Greetings
Raffaello




JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html

Re: RFR 8251989: Hex encoder and decoder utility

[Roger Riggs]

Hi Chris,

Thanks for the comments, I'll make the updates suggested.

Roger


On 8/20/20 11:33 AM, Chris Hegarty wrote:

On 19 Aug 2020, at 22:14, Roger Riggs  wrote:

..
JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html

I like it Roger, very nice. A few minor comments/quibbles:

Hex:

- "Utilities to encode bytes to hex strings and decode hex strings to bytes.” - This 
class consists solely of “factory methods" for creating encoders and decoders to ..

- In the example, do you want to assert that the byte arrays `bytes` and `dec` 
are equal?

- RFC 4752 or RFC 2752. Which one is it? ;-)

RFC 4752.


Decoder:

- decode​(char[] chars, int index, int length) - " A valid character array 
consists only of the delimiters, prefix, suffix, and an even number of hex digits.” 
- its just the portion of the array that is required to consist of …, right. You 
need to add “range”, or similar.

Please use “ReturnS” consistently ( I see a few Return (no S) ). Actually, 
there are a few others, e.g. “Convert”. Can you take pass over all these, in 
all three classes?

-Chris.

Re: RFR 8251989: Hex encoder and decoder utility

[Chris Hegarty]

> On 19 Aug 2020, at 22:14, Roger Riggs  wrote:
> 
> ..
> JavaDoc:
> http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html

I like it Roger, very nice. A few minor comments/quibbles:

Hex:

- "Utilities to encode bytes to hex strings and decode hex strings to bytes.” - 
This class consists solely of “factory methods" for creating encoders and 
decoders to ..

- In the example, do you want to assert that the byte arrays `bytes` and `dec` 
are equal?

- RFC 4752 or RFC 2752. Which one is it? ;-)

Decoder:

- decode​(char[] chars, int index, int length) - " A valid character array 
consists only of the delimiters, prefix, suffix, and an even number of hex 
digits.” - its just the portion of the array that is required to consist of …, 
right. You need to add “range”, or similar.

Please use “ReturnS” consistently ( I see a few Return (no S) ). Actually, 
there are a few others, e.g. “Convert”. Can you take pass over all these, in 
all three classes? 

-Chris.

Re: Optimize sun.invoke.util.BytecodeDescriptor.unparse

[Roger Riggs]

Hi Chris,

Inlining and simplifying unparseSig(cl, sb) seems straightforward.

Though I wonder if performs differently than just calling 
t.descriptorString()?


The first action of Class.descriptorString is to check for primitives 
and return the basicTypeString

and if not a primitive it calls Class.descriptorString().

It should be equivalent, without extra checks.

Regards, Roger


On 8/13/20 1:31 PM, Christoph Dreis wrote:

Hi,

I just stumbled upon sun.invoke.util.BytecodeDescriptor.unparse that seems to 
unnecessarily create a StringBuilder and checks for the given type to be of 
Object.class twice in certain scenarios.

When I apply the attached patch below with the following isolated benchmark:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
public class MyBenchmark {

@State(Scope.Thread)
public static class BenchmarkState {
private Class test = String.class; // long.class;
}

@Benchmark
public String unparseNew(BenchmarkState state) {
return BytecodeDescriptor.unparseNew(state.test);
}

@Benchmark
public String unparseOld(BenchmarkState state) {
return BytecodeDescriptor.unparseOld(state.test);
}
}

I get the following results:
String.class
Benchmark   Mode  Cnt Score Error   
Units
MyBenchmark.unparseNew  avgt   1047,207 ±   1,918   
ns/op
MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10   232,011 ±   0,002
B/op
MyBenchmark.unparseOld  avgt   1087,197 ±  22,843   
ns/op
MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   10   384,020 ±   0,001
B/op
   
long.class

Benchmark   Mode  Cnt Score Error   
Units
MyBenchmark.unparseNew  avgt   10 4,996 ±0,022   
ns/op
MyBenchmark.unparseNew:·gc.alloc.rate.norm  avgt   10≈ 10⁻⁶   
B/op
MyBenchmark.unparseOld  avgt   1013,303 ±6,305   
ns/op
MyBenchmark.unparseOld:·gc.alloc.rate.norm  avgt   1080,003 ±0,001
B/op

As you can see the new way makes things allocation free for primitives and also 
improves normal classes.

It seems like a relatively trivial improvement. In case you think this is 
worthwhile, I would appreciate it if someone could sponsor the change.

Cheers,
Christoph

=== PATCH ===
--- a/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 13 09:33:28 2020 -0700
+++ b/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java   
Thu Aug 13 19:27:26 2020 +0200
@@ -110,9 +110,13 @@
  } else if (type == int.class) {
  return "I";
  }
-StringBuilder sb = new StringBuilder();
-unparseSig(type, sb);
-return sb.toString();
+Wrapper basicType = Wrapper.forBasicType(type);
+char c = basicType.basicTypeChar();
+if (c != 'L') {
+return basicType.basicTypeString();
+} else {
+return type.descriptorString();
+}
  }

[PATCH] continuation of JDK-6736490

[Сергей Цыпанов]

Hello,

in June I sent a letter regarding clean-ups of unnecessary explicit 
initialization of volatile variables [1].
Original mail caused some discussion regarding whether clean-up is safe as of 
JMM.

It turned out that Aleksey Shipilev tried to find conter-example against 
removal of explicit initialization of volatile variables
in concurrency-interest [2] and didn't find any.

Also Doug Lea mentions in the same discussion [3]

> But your account is a more careful version of reasoning
we've done before to conclude that there is never any reason to explicitly
initialize fields to 0/0.0/false/null.

The original message of mine was then forwarded to security-dev list as 
affected code related to security-libs [4]
and Sean Mullan issued JDK-8251548 as sub-issue of JDK-6736490 which already 
includes similar clean-up done for
java.base.

There is also a plenty of possible volatile clean-ups (I've included them into 
a separate patch here), so I have two questions:

1) Could anyone sponsor the changes related to JDK-8251548 (patch is attached 
to [1])?
2) Should we create one more sub-issue in JDK-6736490 to handle the rest of 
changes (attached to this mail) or handle them
module by module?

Patch is attached, tier1 and tier2 are ok

1. https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067341.html
2. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html
3. http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html
4. https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022289.html

diff --git a/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java b/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java
--- a/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java
+++ b/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java
@@ -53,7 +53,7 @@
 // A set of tag numbers corresponding to tags essential to decoding
 // the image and metadata required to interpret its samples.
 //
-private static volatile Set essentialTags = null;
+private static volatile Set essentialTags;
 
 private static void initializeEssentialTags() {
 Set tags = essentialTags;
diff --git a/src/java.desktop/share/classes/com/sun/media/sound/SoftAudioPusher.java b/src/java.desktop/share/classes/com/sun/media/sound/SoftAudioPusher.java
--- a/src/java.desktop/share/classes/com/sun/media/sound/SoftAudioPusher.java
+++ b/src/java.desktop/share/classes/com/sun/media/sound/SoftAudioPusher.java
@@ -37,7 +37,7 @@
  */
 public final class SoftAudioPusher implements Runnable {
 
-private volatile boolean active = false;
+private volatile boolean active;
 private SourceDataLine sourceDataLine = null;
 private Thread audiothread;
 private final AudioInputStream ais;
diff --git a/src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java b/src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java
--- a/src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java
+++ b/src/java.desktop/share/classes/com/sun/media/sound/SoftSynthesizer.java
@@ -76,7 +76,7 @@
 public SoftAudioPusher pusher = null;
 public AudioInputStream jitter_stream = null;
 public SourceDataLine sourceDataLine = null;
-public volatile long silent_samples = 0;
+public volatile long silent_samples;
 private int framesize = 0;
 private final WeakReference weak_stream_link;
 private final AudioFloatConverter converter;
diff --git a/src/java.desktop/share/classes/java/awt/Component.java b/src/java.desktop/share/classes/java/awt/Component.java
--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -394,7 +394,7 @@
  * @see #validate
  * @see #invalidate
  */
-private volatile boolean valid = false;
+private volatile boolean valid;
 
 /**
  * The {@code DropTarget} associated with this component.
@@ -9317,7 +9317,7 @@
  * to add/remove ComponentListener and FocusListener to track
  * target Component's state.
  */
-private transient volatile int propertyListenersCount = 0;
+private transient volatile int propertyListenersCount;
 
 /**
  * A component listener to track show/hide/resize events
diff --git a/src/java.desktop/share/classes/java/awt/Container.java b/src/java.desktop/share/classes/java/awt/Container.java
--- a/src/java.desktop/share/classes/java/awt/Container.java
+++ b/src/java.desktop/share/classes/java/awt/Container.java
@@ -3845,7 +3845,7 @@
  * Number of PropertyChangeListener objects registered. It's used
  * to add/remove ContainerListener to track target Container's state.
  */
-private transient volatile int propertyListenersCount = 0;
+private transient volatile int propertyListenersCount;