Re: RFR: 8217633: Configurable extensions with system properties [v3]

[Xue-Lei Andrew Fan]

> The TLS protocols are designed to tolerant unknown TLS extensions. However, 
> although it is not common, there are a few TLS implementations that cannot 
> handle unknown extensions properly. As results in unexpected interoperability 
> issue when new extensions are introduced in JDK. The interoperability impact 
> could be mitigated If applications can customize the extensions if needed.
> 
> With this update, two system properties are added to configure the default 
> extensions in either client or server side of TLS connections.  Please note 
> that the impact of blocking TLS extensions is complicated.  For example, a 
> TLS connection may not be able to established if a mandatory extension is 
> blocked.  Please don't use this feature unless you clearly understand the 
> impact.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993

Xue-Lei Andrew Fan has updated the pull request incrementally with one 
additional commit since the last revision:

  rename the system property names

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1752/files
  - new: https://git.openjdk.java.net/jdk/pull/1752/files/5bd6e865..88beb8ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=01-02

  Stats: 158 lines in 3 files changed: 75 ins; 75 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752

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

RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program

[Rajan Halade]

Following two roots are added to cacerts store -

CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic 
and Research Institutions Cert. Authority, L=Athens, C=GR

CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic 
Academic and Research Institutions Cert. Authority, L=Athens, C=GR

-

Commit messages:
 - 8256421: Add 2 HARICA roots to Oracle Root CA Program

Changes: https://git.openjdk.java.net/jdk/pull/2272/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2272&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256421
  Stats: 393 lines in 4 files changed: 390 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2272/head:pull/2272

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

Re: RFR: 8217633: Configurable extensions with system properties [v4]

[Xue-Lei Andrew Fan]

> The TLS protocols are designed to tolerant unknown TLS extensions. However, 
> although it is not common, there are a few TLS implementations that cannot 
> handle unknown extensions properly. As results in unexpected interoperability 
> issue when new extensions are introduced in JDK. The interoperability impact 
> could be mitigated If applications can customize the extensions if needed.
> 
> With this update, two system properties are added to configure the default 
> extensions in either client or server side of TLS connections.  Please note 
> that the impact of blocking TLS extensions is complicated.  For example, a 
> TLS connection may not be able to established if a mandatory extension is 
> blocked.  Please don't use this feature unless you clearly understand the 
> impact.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993

Xue-Lei Andrew Fan 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 six additional 
commits since the last revision:

 - Merge
 - rename the system property names
 - Update copyright years to 2021
 - Remove swp file
 - Add regression test
 - 8217633: Configurable extensions with system properties

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1752/files
  - new: https://git.openjdk.java.net/jdk/pull/1752/files/88beb8ae..ed9409c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1752&range=02-03

  Stats: 121138 lines in 3068 files changed: 60397 ins; 38820 del; 21921 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752

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

Re: 8259886 : Improve SSL session cache performance and scalability

[Daniel Jeliński]

Hi Xuelei,
Thank you, that would be great.
Yes, I created a microbenchmark and got some numbers. The benchmark just
calls MemoryCache.put() in a loop; baseline results for different size &
timeout values:

Benchmark   (size)  (timeout)  Mode  Cnt ScoreError  Units
CacheBench.put   20480  86400  avgt   2583.653 ?  6.269  us/op
CacheBench.put   20480  0  avgt   25 0.107 ?  0.001  us/op
CacheBench.put  204800  86400  avgt   25  2057.781 ? 35.942  us/op
CacheBench.put  204800  0  avgt   25 0.108 ?  0.001  us/op

And after applying my proposed changes:

Benchmark   (size)  (timeout)  Mode  Cnt  Score   Error  Units
CacheBench.put   20480  86400  avgt   25  0.146 ? 0.002  us/op
CacheBench.put   20480  0  avgt   25  0.108 ? 0.002  us/op
CacheBench.put  204800  86400  avgt   25  0.150 ? 0.001  us/op
CacheBench.put  204800  0  avgt   25  0.106 ? 0.001  us/op

Given that the server-side handshake takes about 2 milliseconds (same
machine, TLS 1.2/ECDHE/ECDSA/secp256r1), I don't expect 0.1 microsecond
cache access to be a point of contention, but I haven't field-tested it yet.

I posted my code and benchmark results here:
https://github.com/openjdk/jdk/pull/2255. I'm still struggling with the
company's OCA (signed a few years and a few corporate changes ago, and not
used in a long time), I hope to get this sorted soon. I went with minimal
changes to the existing implementation, hoping that smaller changes will be
more likely to be approved for backporting than complete rewrites.

I had a quick look at your SessionCache. It looks like your put() operation
is constant-time already, so not much else for me to improve. However,
please correct me if I'm wrong, but I think SoftCacheEntry.unlink() should
be called with a lock held at all times, shouldn't it? SessionCache.get()
may call remove() without lock. Also there's no protection against calling
unlink() twice on the same entry (for example from concurrent get() calls),
which could wreck the linked list; setting prev=next=null would have
avoided this.

Thanks,
Daniel



śr., 27 sty 2021 o 20:36 Xue-Lei Fan  napisał(a):

> Hi Daniel,
>
> I would like to help you out.  Did you have some numbers about the
> performance improvement of your evaluation?  I had a draft re-write cache
> 
>  by
> using ConcurrentHashMap, if you have a chance, would you like to evaluate
> if it could be improved further with your ideas?
>
> Thanks,
> Xuelei
>
> On Jan 27, 2021, at 1:28 AM, Daniel Jeliński  wrote:
>
> Hi all,
> I'd like to modify the MemoryCache class that is used for caching SSL
> sessions in Java 11; when the cache is overloaded (full cache with no
> expired entries), the computational complexity of put operation is linear
> in the cache size.
>
> I am aware that the current Java versions are using stateless resumption;
> my company's policy is to use Java LTS, so stateless is not an option to us
> at the moment.
>
> The change I propose would alter the behavior of MemoryCache; currently
> the cache guarantees that expired entries are removed before live entries
> when the cache capacity is reached. I'd like to remove that guarantee, and
> instead always remove the least recently used cache entry. Additionally, to
> keep the memory use in check, I'd like to check the least recently used
> entries for expiration, and remove them as needed. This operation would be
> run on every put().
>
> Evaluated alternatives:
> - keep MemoryCache as is, increase cache size to avoid overloading. This
> would reduce the frequency of check for expired entries, but if the larger
> cache eventually gets overloaded, the put() operation would take even
> longer to complete.
> - keep MemoryCache behavior as is, but improve performance of removing
> expired entries. This would require a new data structure - we would need to
> have cache entries sorted both by access time and creation time.
> - always remove entries in insertion order, regardless if they are used or
> not.
> - always remove the least recently used entries, even if they are still
> valid and there are recently used expired entries somewhere in the cache.
> This is my preferred option.
>
> Additionally, we can choose how to remove stale entries:
> - all reachable stale entries on every put (that is, iterate over the
> internal data structure removing stale entries until a non-stale one is
> found); keeps memory use low, but can occasionally scan the entire cache
> (computational complexity: linear worst case, amortized constant);
> - fixed number of reachable stale entries on every put (same as above, but
> stop iterating after a fixed number of removed entries even if more are
> available); execution time is bounded by a constant, but some entries may
> stay in cache a bit longer than they need to.
> - all stale entries on put that would othe

Re: 8259886 : Improve SSL session cache performance and scalability

[Xue-Lei Fan]

Hi Daniel,

I would like to help you out.  Did you have some numbers about the performance 
improvement of your evaluation?  I had a draft re-write 
cache
 by using ConcurrentHashMap, if you have a chance, would you like to evaluate 
if it could be improved further with your ideas?

Thanks,
Xuelei

On Jan 27, 2021, at 1:28 AM, Daniel Jeliński 
mailto:djelins...@gmail.com>> wrote:

Hi all,
I'd like to modify the MemoryCache class that is used for caching SSL sessions 
in Java 11; when the cache is overloaded (full cache with no expired entries), 
the computational complexity of put operation is linear in the cache size.

I am aware that the current Java versions are using stateless resumption; my 
company's policy is to use Java LTS, so stateless is not an option to us at the 
moment.

The change I propose would alter the behavior of MemoryCache; currently the 
cache guarantees that expired entries are removed before live entries when the 
cache capacity is reached. I'd like to remove that guarantee, and instead 
always remove the least recently used cache entry. Additionally, to keep the 
memory use in check, I'd like to check the least recently used entries for 
expiration, and remove them as needed. This operation would be run on every 
put().

Evaluated alternatives:
- keep MemoryCache as is, increase cache size to avoid overloading. This would 
reduce the frequency of check for expired entries, but if the larger cache 
eventually gets overloaded, the put() operation would take even longer to 
complete.
- keep MemoryCache behavior as is, but improve performance of removing expired 
entries. This would require a new data structure - we would need to have cache 
entries sorted both by access time and creation time.
- always remove entries in insertion order, regardless if they are used or not.
- always remove the least recently used entries, even if they are still valid 
and there are recently used expired entries somewhere in the cache. This is my 
preferred option.

Additionally, we can choose how to remove stale entries:
- all reachable stale entries on every put (that is, iterate over the internal 
data structure removing stale entries until a non-stale one is found); keeps 
memory use low, but can occasionally scan the entire cache (computational 
complexity: linear worst case, amortized constant);
- fixed number of reachable stale entries on every put (same as above, but stop 
iterating after a fixed number of removed entries even if more are available); 
execution time is bounded by a constant, but some entries may stay in cache a 
bit longer than they need to.
- all stale entries on put that would otherwise exceed cache capacity (current 
implementation)
- never; once cache reaches full capacity, it stays full until the application 
is restarted. Fastest implementation, but at a cost of increased memory use.

My preference would be to remove either all or a fixed number of reachable 
stale entries.

I'm willing to prepare a patch for 17 and 11u, if I can find a sponsor.
Thanks,
Daniel

Re: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6]

[Clive Verghese]

On Wed, 27 Jan 2021 17:46:03 GMT, Xue-Lei Andrew Fan  wrote:

>> Changes requested by rhalade (Reviewer).
>
> For the CSR request, I updated the component to security-libs/javax.net.ssl, 
> add 17 as one of the fix versions, and added myself as reviewer.

Thank you. I will change the status of the CSR to proposed.

-

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

Re: RFR: 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl [v6]

[Xue-Lei Andrew Fan]

On Wed, 13 Jan 2021 18:46:10 GMT, Rajan Halade  wrote:

>> Clive Verghese has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains four commits:
>> 
>>  - Update copyright year
>>  - Add error handling guidelines
>>  - Fix bugids and use server port passed as a parameter
>>  - 8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl
>
> Changes requested by rhalade (Reviewer).

For the CSR request, I updated the component to security-libs/javax.net.ssl, 
add 17 as one of the fix versions, and added myself as reviewer.

-

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

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]

[Vladimir Kempik]

On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie  wrote:

> Build changes per se now looks okay. However, I agree with Erik that unless 
> this PR can wait for the JNF removal, at the very least the build docs needs 
> to be updated to explain how to successfully build for this platform. (I can 
> live with the configure command line hack, since it's temporary -- otherwise 
> I'd have requested a new configure argument.) This can be done in this PR or 
> a follow-up PR.

I believe it's better be done under separate PR/bugfix, so it can be completely 
reverted once JNF removed.

-

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

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v7]

[Anton Kozlov]

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
> windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
> JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary 
> adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
> required on macOS/AArch64 platform. It's implemented with 
> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
> thread, so W^X mode change relates to the java thread state change (for java 
> threads). In most cases, JVM executes in write-only mode, except when calling 
> a generated stub like SafeFetch, which requires a temporary switch to 
> execute-only mode. The same execute-only mode is enabled when a java thread 
> executes in java or native states. This approach of managing W^X mode turned 
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with two additional 
commits since the last revision:

 - Update copyright year for BsdAARCH64ThreadContext.java
 - Fix inclusing of StubRoutines header

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/f1ef6240..9d8b07c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05-06

  Stats: 5 lines in 4 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

[Andrew Haley]

On 1/26/21 6:42 PM, erik.joels...@oracle.com wrote:
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve this issue [1].
>
> In the meantime, I don't think we should rely on finding JNF in
> unsupported locations inside Xcode. Could we wait with integrating this
> port until it can be built without such hacks?

That sounds right to me.

In the meantime, there is some cleanup work to be done in mainline
on slow_signature_handler, which will potentially make the AArch64
back end merge much simpler.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

8259886 : Improve SSL session cache performance and scalability

[Daniel Jeliński]

Hi all,
I'd like to modify the MemoryCache class that is used for caching SSL
sessions in Java 11; when the cache is overloaded (full cache with no
expired entries), the computational complexity of put operation is linear
in the cache size.

I am aware that the current Java versions are using stateless resumption;
my company's policy is to use Java LTS, so stateless is not an option to us
at the moment.

The change I propose would alter the behavior of MemoryCache; currently the
cache guarantees that expired entries are removed before live entries when
the cache capacity is reached. I'd like to remove that guarantee, and
instead always remove the least recently used cache entry. Additionally, to
keep the memory use in check, I'd like to check the least recently used
entries for expiration, and remove them as needed. This operation would be
run on every put().

Evaluated alternatives:
- keep MemoryCache as is, increase cache size to avoid overloading. This
would reduce the frequency of check for expired entries, but if the larger
cache eventually gets overloaded, the put() operation would take even
longer to complete.
- keep MemoryCache behavior as is, but improve performance of removing
expired entries. This would require a new data structure - we would need to
have cache entries sorted both by access time and creation time.
- always remove entries in insertion order, regardless if they are used or
not.
- always remove the least recently used entries, even if they are still
valid and there are recently used expired entries somewhere in the cache.
This is my preferred option.

Additionally, we can choose how to remove stale entries:
- all reachable stale entries on every put (that is, iterate over the
internal data structure removing stale entries until a non-stale one is
found); keeps memory use low, but can occasionally scan the entire cache
(computational complexity: linear worst case, amortized constant);
- fixed number of reachable stale entries on every put (same as above, but
stop iterating after a fixed number of removed entries even if more are
available); execution time is bounded by a constant, but some entries may
stay in cache a bit longer than they need to.
- all stale entries on put that would otherwise exceed cache capacity
(current implementation)
- never; once cache reaches full capacity, it stays full until the
application is restarted. Fastest implementation, but at a cost of
increased memory use.

My preference would be to remove either all or a fixed number of reachable
stale entries.

I'm willing to prepare a patch for 17 and 11u, if I can find a sponsor.
Thanks,
Daniel

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

[David Holmes]

I don't know why the Skara tools decided to associate my comment with 
Alan Hayward's comment as they are not at all related. :(


David

On 27/01/2021 4:50 pm, David Holmes wrote:

On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward 
 wrote:


AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
ie:
`--with-extra-ldflags='-F 
/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`

Otherwise there will be missing _JNFNative* functions.

Is this the long term plan? Or will eventually the required code be moved into 
JDK and/or the xcode one automatically get picked up by the configure scripts?


There is ongoing work by P. Race to eliminate dependence on JNF at all



AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
ie:
`--with-extra-ldflags='-F 
/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
Otherwise there will be missing _JNFNative* functions.
Is this the long term plan? Or will eventually the required code be moved into 
JDK and/or the xcode one automatically get picked up by the configure scripts?


There is ongoing work by P. Race to eliminate dependence on JNF at all


Ok, that's great.
In the meantime is it worth adding something to the MacOS section of 
doc/building.* ?
(I pieced together the required line from multiple posts in a mailing list)


Hi Anton,

Just to add weight to comments already made by @coleenp and @stefank , I also 
find the W^X coding support to be too intrusive and polluting of the shared 
code. I would much rather see this support pushed down as far as possible, to 
minimise the impact and to use ifdef'd code for macos/Aarch64 (via 
MACOS_AARCH64_ONLY macro) rather than providing empty methods.

Thanks,
David

-

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

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]

[Magnus Ihse Bursie]

On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Redo buildsys fix

Build changes per se now looks okay. However, I agree with Erik that unless 
this PR can wait for the JNF removal, at the very least the build docs needs to 
be updated to explain how to successfully build for this platform. (I can live 
with the configure command line hack, since it's temporary -- otherwise I'd 
have requested a new configure argument.) This can be done in this PR or a 
follow-up PR.

-

Marked as reviewed by ihse (Reviewer).

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

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]

[Magnus Ihse Bursie]

On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster  
wrote:

>> @luhenry , could you please check this comment, I think SA-agent was MS's 
>> job here.
>
> The target is identified by the header file now:
> https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41
> 
> Do you think there is any problem with this approach?

@lewurm No, that's okay. I just wanted to know that this had not been lost.

-

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

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

[Magnus Ihse Bursie]

On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik  wrote:

>> make/autoconf/build-aux/autoconf-config.guess line 1275:
>> 
>>> 1273: UNAME_PROCESSOR="aarch64"
>>> 1274: fi
>>> 1275:   fi ;;
>> 
>> Almost, but not quite, correct. We cannot change the autoconf-config.guess 
>> file due to license restrictions (the license allows redistribution, not 
>> modifications). Instead we have the config.guess file which "wraps" 
>> autoconf-config.guess and makes pre-/post-call modifications to work around 
>> limitations in the autoconf original file. So you need to check there if you 
>> are getting incorrect results back and adjust it in that case. See the 
>> already existing clauses in that file.
>
> Hello
> I have updated PR and moved this logic to make/autoconf/build-aux/config.guess
> It's pretty similar to i386 -> x86_64 fix-up on macos_intel

Thanks. That looks better.

-

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