Re: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on Windows

[Igor Ignatyev]

Hi Brian,

thanks for your review. I've decided to push into jdk/jdk instead of jdk15. 
please let me know if you think this patch needs to be in jdk15, and I'll 
backport it there.

Cheers,
-- Igor

> On Jul 30, 2020, at 2:39 PM, Brian Burkhalter  
> wrote:
> 
> Hi Igor,
> 
> This test looks all right to me.
> 
> Sorry for the late review.
> 
> Thanks,
> 
> Brian
> 
>> On Jul 20, 2020, at 11:28 AM, Igor Ignatyev > > wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00 
>> 
>>> 98 lines changed: 18 ins; 31 del; 49 mod;
>> 
>> Hi all,
>> 
>> could you please review this small fix to make java/io/File/GetXSpace.java 
>> work again on windows?
>> 
>> the test has been updated to work under cygwin, which includes the following 
>> changes:
>> - GetXSpace.sh accepts CYGWIN_* as known OS and sets windows path to TMP var
>> - uses the same regexp to parse df on windows as on other platforms
>> - but uses 'FileSystem' field as Space's name, as opposed to 'MountedOn' on 
>> *nix, as on cygwin, MountedOn is cygwin path, while FileSystem is 
>> corresponding windows path, and the test expect Space's name to be 
>> appropriate path
> 

[PING?] RFR(S): 8248910: NPE when freeing the memory for a slice from a buffer

[Yangfei (Felix)]

Ping...  Any suggestions?

Thanks,
Felix


> -Original Message-
> From: Yangfei (Felix)
> Sent: Wednesday, July 8, 2020 11:35 AM
> To: core-libs-dev@openjdk.java.net
> Subject: RFR(S): 8248910: NPE when freeing the memory for a slice from a
> buffer
> 
> Hi,
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248910
> Webrev: http://cr.openjdk.java.net/~fyang/8248910/webrev.00/
> 
> The overall procedure is described by the newly add test.
> For a slice from a ByteBuffer, it does not have a cleaner, which leads to 
> the
> NPE.
> Here, I thinks we should not try to free the memory of a slice.
> Proposed fix adds a null check for cleaner in Util.free before invoking 
> its
> clean() method.
> Another possible way would be catching slice in Util.
> releaseTemporaryDirectBuffer and exclude it.
> 
> Tier1-3 tested on x86_64-linux-gnu.  Newly add test fail without the fix 
> and
> pass otherwise.
> Comments?
> 
> Thanks,
> Felix

Re: RFR 8233048: WeekFields.ISO is not a singleton

[Roger Riggs]

Looks good Naoto.

Thanks, Roger

On 7/30/20 5:53 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8233048

The proposed chageset is located at:

https://cr.openjdk.java.net/~naoto/8233048/webrev.00/

java.time.temporal.WeekFields.ISO is instantiated using the 
constructor, which is a different object returned from 
WeekFields.of(MONDAY, 4). Even though this itself does not cause any 
issues, since objects are "equal", but the fix will provide the 
identity, as WeekFields objects are supposed to be singletons.


Naoto

RFR: 8250646: hdiutil detach fix JDK-8245311 still fails sometimes

[alexander . matveev]

Please review the jpackage fix for bug [1] at [2].

- DMG image can get detach even if "hdiutil detach" return resource busy 
error. Fixed by stopping trying detach if DMG already got detach.


[1] https://bugs.openjdk.java.net/browse/JDK-8250646
[2] http://cr.openjdk.java.net/~almatvee/8250646/webrev.00/

Thanks,
Alexander

Re: RFR 8233048: WeekFields.ISO is not a singleton

[Joe Wang]

+1

-Joe

On 7/30/20 2:53 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8233048

The proposed chageset is located at:

https://cr.openjdk.java.net/~naoto/8233048/webrev.00/

java.time.temporal.WeekFields.ISO is instantiated using the 
constructor, which is a different object returned from 
WeekFields.of(MONDAY, 4). Even though this itself does not cause any 
issues, since objects are "equal", but the fix will provide the 
identity, as WeekFields objects are supposed to be singletons.


Naoto

Re: RFR 8233048: WeekFields.ISO is not a singleton

[Stephen Colebourne]

 +1
Stephen

On Thu, 30 Jul 2020 at 22:54,  wrote:
>
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8233048
>
> The proposed chageset is located at:
>
> https://cr.openjdk.java.net/~naoto/8233048/webrev.00/
>
> java.time.temporal.WeekFields.ISO is instantiated using the constructor,
> which is a different object returned from WeekFields.of(MONDAY, 4). Even
> though this itself does not cause any issues, since objects are "equal",
> but the fix will provide the identity, as WeekFields objects are
> supposed to be singletons.
>
> Naoto
>

RFR 8233048: WeekFields.ISO is not a singleton

[naoto . sato]

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8233048

The proposed chageset is located at:

https://cr.openjdk.java.net/~naoto/8233048/webrev.00/

java.time.temporal.WeekFields.ISO is instantiated using the constructor, 
which is a different object returned from WeekFields.of(MONDAY, 4). Even 
though this itself does not cause any issues, since objects are "equal", 
but the fix will provide the identity, as WeekFields objects are 
supposed to be singletons.


Naoto

Re: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on Windows

[Brian Burkhalter]

Hi Igor,

This test looks all right to me.

Sorry for the late review.

Thanks,

Brian

> On Jul 20, 2020, at 11:28 AM, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00 
> 
>> 98 lines changed: 18 ins; 31 del; 49 mod;
> 
> Hi all,
> 
> could you please review this small fix to make java/io/File/GetXSpace.java 
> work again on windows?
> 
> the test has been updated to work under cygwin, which includes the following 
> changes:
> - GetXSpace.sh accepts CYGWIN_* as known OS and sets windows path to TMP var
> - uses the same regexp to parse df on windows as on other platforms
> - but uses 'FileSystem' field as Space's name, as opposed to 'MountedOn' on 
> *nix, as on cygwin, MountedOn is cygwin path, while FileSystem is 
> corresponding windows path, and the test expect Space's name to be 
> appropriate path

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Ningsheng Jian]

On 7/29/20 7:44 PM, Andrew Haley wrote:

On 20/07/2020 04:51, Ningsheng Jian wrote:

Since we are getting ready to propose Vector API target to JDK 16 [1]. I
have regenerated webrev of aarch64 backend parts from panama repo, which
has been rebased to jdk/jdk very recently, by:

$ hg update vector-unstable && hg diff -r default > all.patch
$ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk
'{print $4}' > aarch64_list
$ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list

The new webrev:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/

Could you please help to take a look?


OK, thanks. It all looks fine. Sorry for the delay.


Thank you Andrew!

Regards,
Ningsheng

Re: RFR [16/java.xml] 8250638: Address reliance on default constructors in java.xml

[Lance Andersen]

+1

> On Jul 30, 2020, at 12:20 PM, Joe Wang  wrote:
> 
> Hello,
> 
> Please review a change to remove reliance of default constructors in java.xml.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8250638
> CSR: https://bugs.openjdk.java.net/browse/JDK-8250800
> 
> Patch:
> 
> diff --git a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java 
> b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> --- a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> +++ b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -58,7 +58,10 @@
>  public class HandlerBase
>  implements EntityResolver, DTDHandler, DocumentHandler, ErrorHandler
>  {
> -
> +/**
> + * Constructs a {@code HandlerBase}.
> + */
> +public HandlerBase() {}
> 
> 
>  // Default implementation of the EntityResolver interface.
> diff --git 
> a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java 
> b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> --- a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> +++ b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -70,7 +70,10 @@
>  public class DefaultHandler
>  implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler
>  {
> -
> +/**
> + * Constructs a {@code DefaultHandler}.
> + */
> +public DefaultHandler() {}
> 
> 
>  // Default implementation of the EntityResolver interface.
> 
> Thanks,
> Joe
> 


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(s): Support graceful application termination on Windows shutdown/logoff

[Nikola Grcevski]

Hi core-libs-dev,

I've been searching extensively the mailing list archives and JBS, but I cannot
find any more information on this topic, apart from the two linked bug reports 
[1] and [2].

I apologize for my newbie  search skills, can someone please help review the 
email
I sent to hotspot-runtime-dev below. 

Essentially, no shutdown code runs on normal Windows logoff/shutdown since 
Windows 7, 
which I believe was reported as change in behaviour under [1].

I want to point out that the issue has nothing to do with Virtual Machines, the 
JVM
simply doesn't receive the correct events, unless there's an AWT window open.
The implementation for WM_ENDSESSION in AWT seems to have a small issue that
the java process will terminate regardless of the user changing their mind 
about shutting down.

Thanks,
Nikola

[1] https://bugs.openjdk.java.net/browse/JDK-8079631
[2] https://bugs.openjdk.java.net/browse/JDK-7068835

-Original Message-
From: David Holmes  
Sent: July 23, 2020 11:02 PM
To: Nikola Grcevski ; core-libs-dev Libs 

Cc: hotspot-runtime-...@openjdk.java.net
Subject: Re: RFR(s): Support graceful application termination on Windows 
shutdown/logoff

Hi Nikola,

I'm redirecting this to the core-libs team initially because this is an issue 
that has been raised and discussed considerably in the past (possibly with some 
misunderstanding relating to the WM_ENDSESSION event). The core-libs team need 
to confirm the intended semantics here and we (runtime) can then implement 
whatever is determined to be needed. 
Interaction with the client team for AWT interoperability may also be needed.

Thanks,
David

On 24/07/2020 11:47 am, Nikola Grcevski wrote:
> Hello hotspot-runtime-dev,
> 
> After some recent investigation into stale files remaining after Java 
> process terminates on Windows shutdown, we noticed that there's 
> missing support for detecting Windows shutdown/logoff events for 
> interactive Java applications. Given that Java loads both GDI32.dll 
> and USER32.dll, even for console applications, this means that almost 
> all Java processes launched on Windows don't run any shutdown hooks at the 
> moment on user logoff or system shutdown/restart.
> 
> Since Windows 7, all Windows applications that load (or transitively 
> call) GDI32.dll or USER32.dll will not receive the CTRL_LOGOFF_EVENT 
> and CTRL_SHUTDOWN_EVENT events, but instead they will be sent WM_ENDSESSION.
> 
> This is documented in MSDN under the following article:
> 
> https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler
> 
> It appears that this issue was logged in JSB at some point, but it was 
> made duplicate of another issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8079631
> 
> The behaviour changed going from Windows Vista to Windows 7.
> 
> I've made a proposal patch to address this issue under the following webrev:
> 
> http://cr.openjdk.java.net/~adityam/nikola/wm_endsession_handling/
> 
> At the moment only AWT applications would terminate gracefully on 
> shutdown/logoff, because they have support for listening on WM_ENDSESSION.
> There's a bug in the AWT code, it doesn't check for wparam upon 
> receiving the event, but it will work in most cases. If this patch is 
> accepted I can submit a follow-up patch for AWT to resolve the possible 
> issues.
> 
> Finally, there are third set of events for service processes, for 
> example java applications which are started with a Windows Service 
> wrappers. These services work with SERVICE_ACCEPT_SHUTDOWN and 
> SERVICE_CONTROL_SHUTDOWN.
> Once the most common case is resolved, I'd like to submit perhaps a 
> follow-up patch to support graceful termination of Java as Windows service 
> programs.
> 
> We are working to amend the MSDN documentation for 
> SetConsoleCtrlHandler to specify that this behaviour change is also 
> present on server OSs. The documentation only mentions the workstation OS 
> flavours at the moment.
> 
> Thanks in advance for reviewing this.
> 
> Nikola Grcevski
> Microsoft
> 

Re: RFR [16/java.xml] 8250638: Address reliance on default constructors in java.xml

[Joe Darcy]

Look fine Joe; thanks,

-Joe

On 7/30/2020 9:20 AM, Joe Wang wrote:

Hello,

Please review a change to remove reliance of default constructors in 
java.xml.


JBS: https://bugs.openjdk.java.net/browse/JDK-8250638
CSR: https://bugs.openjdk.java.net/browse/JDK-8250800

Patch:

diff --git a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java 
b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java

--- a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
+++ b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -58,7 +58,10 @@
 public class HandlerBase
 implements EntityResolver, DTDHandler, DocumentHandler, ErrorHandler
 {
-
+    /**
+ * Constructs a {@code HandlerBase}.
+ */
+    public HandlerBase() {}


 // Default implementation of the EntityResolver interface.
diff --git 
a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java 
b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java

--- a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
+++ b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -70,7 +70,10 @@
 public class DefaultHandler
 implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler
 {
-
+    /**
+ * Constructs a {@code DefaultHandler}.
+ */
+    public DefaultHandler() {}


 // Default implementation of the EntityResolver interface.

Thanks,
Joe

RFR [16/java.xml] 8250638: Address reliance on default constructors in java.xml

[Joe Wang]

Hello,

Please review a change to remove reliance of default constructors in 
java.xml.


JBS: https://bugs.openjdk.java.net/browse/JDK-8250638
CSR: https://bugs.openjdk.java.net/browse/JDK-8250800

Patch:

diff --git a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java 
b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java

--- a/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
+++ b/src/java.xml/share/classes/org/xml/sax/HandlerBase.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -58,7 +58,10 @@
 public class HandlerBase
 implements EntityResolver, DTDHandler, DocumentHandler, ErrorHandler
 {
-
+    /**
+ * Constructs a {@code HandlerBase}.
+ */
+    public HandlerBase() {}


 // Default implementation of the EntityResolver interface.
diff --git 
a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java 
b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java

--- a/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
+++ b/src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -70,7 +70,10 @@
 public class DefaultHandler
 implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler
 {
-
+    /**
+ * Constructs a {@code DefaultHandler}.
+ */
+    public DefaultHandler() {}


 // Default implementation of the EntityResolver interface.

Thanks,
Joe

Re: RFR: JDK-8244288 Specialized implementations for putIfAbsent, merge, compute* methods in TreeMap derived maps

[Paul Sandoz]

Hi Tagir,

Thanks for your measured patience. I will take a look.

Paul.

> On Jul 26, 2020, at 9:04 AM, Tagir Valeev  wrote:
> 
> Hello!
> 
> A gentle ping: please review
> https://bugs.openjdk.java.net/browse/JDK-8244288
> http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
> The details are listed below.
> 
> With best regards,
> Tagir Valeev.
> 
> On Sun, May 3, 2020 at 4:36 PM Tagir Valeev  wrote:
>> 
>> Hello!
>> 
>> Please review the following change:
>> https://bugs.openjdk.java.net/browse/JDK-8244288
>> http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/
>> 
>> We already implemented putIfAbsent, merge, computeIfAbsent,
>> computeIfPresent, and compute for TreeMap class (see JDK-8176894).
>> However, default implementations of these methods are still used for
>> TreeMap derived maps, such as descendingMap(), tailMap(), headMap()
>> and subMap(). The implementation is pretty straightforward, just a
>> range-check+delegation for each of these methods inside the
>> TreeMap.NavigableSubMap (+32 lines in TreeMap.java). Care should be
>> taken to avoid throwing IAE from compute* methods if the key is
>> outside of the range but we don't actually add the entry. This mimics
>> the previous behavior and also consistent with other modification
>> methods like Map.remove (we don't throw from remove if the key is out
>> of range, simply do nothing).
>> 
>> To cover these changes with tests, I added new
>> TreeMap().descendingMap() to
>> InPlaceOpsCollisions.nullValueFriendlyMaps and
>> MapWithCollisionsProviders.makeMapsMoreTypes. This map should behave
>> like a normal Map modulo iteration order but implementation goes
>> through NavigableSubMap. Also, I added more adders to
>> LockStep::randomAdder (lines 572+) to cover new methods, as well as
>> some more throws IAE asserts around line 806. At the same time, I took
>> the liberty to modernize this test:
>> - Convert all the raw-types to properly parameterized (using 'var' for
>> local vars where resulting type is long)
>> - Convert MapFrobber and SetFrobber to interfaces, and convert all the
>> implementations to lambdas (automatic conversion via IntelliJ IDEA +
>> rename of conflicting parameter names)
>> - Use for-each loop instead of indexed for loop where possible
>> - 'elts' array was created in two places but unused afterward. I added
>> size assert to these arrays to use it at least somehow (though
>> probably content should be checked as well).
>> - Use Comparator.naturalOrder() instead of manually written one in
>> comparator() methods (should not affect the testing in any way as it's
>> only used directly, not passed e.g. to TreeMap constructor).
>> - Use Objects.equals inside LockStep#equal
>> - Inverted 'if' at line 299 to avoid empty block.
>> If the cleanup really complicates the review I can post the cleanup as
>> a separate changeset. Though it should not be very problematic as the
>> actual changes are quite compact (as said above, near lines 572 and
>> 806)
>> 
>> I also improved the previously added benchmark TreeMapUpdate to check
>> descendingMap and tailMap cases to confirm the hypothesis that the
>> change improves the performance of derived maps. This is indeed the
>> case. E.g. merge test yields (comparator = false, size = 1000) for
>> unpatched JDK:
>> 
>> (benchmark) (mode) (prefill)Score  Error  Units
>> TreeMapUpdate.mergeTreeMap   true   63589,075 ± 1028,065  ns/op
>> TreeMapUpdate.mergeTreeMap  false   65414,367 ± 1011,442  ns/op
>> TreeMapUpdate.merge  descendingMap   true  121501,618 ± 1849,108  ns/op
>> TreeMapUpdate.merge  descendingMap  false   95913,212 ± 2854,063  ns/op
>> TreeMapUpdate.mergetailMap   true  126657,309 ± 4467,733  ns/op
>> TreeMapUpdate.mergetailMap  false   93448,840 ± 1359,392  ns/op
>> 
>> As you can see, the merge on derived maps is significantly slower.
>> After the patch is applied the results are much better:
>> 
>> (benchmark) (mode)  (prefill) Score  Error  Units
>> TreeMapUpdate.mergeTreeMap   true 64059,189 ±  808,230  ns/op
>> TreeMapUpdate.mergeTreeMap  false 65156,912 ± 1229,965  ns/op
>> TreeMapUpdate.merge  descendingMap   true 69938,131 ± 1697,357  ns/op
>> TreeMapUpdate.merge  descendingMap  false 67783,829 ±  263,061  ns/op
>> TreeMapUpdate.mergetailMap   true 71079,529 ±  841,738  ns/op
>> TreeMapUpdate.mergetailMap  false 68577,169 ± 1196,758  ns/op
>> 
>> I don't think this requires a CSR, as the changed class is
>> package-private, so it cannot be extended by clients.
>> 
>> With best regards,
>> Tagir Valeev.

Re: Build error with GCC 10 in NetworkInterface.c and k_standard.c

[Koichi Sakata]

>> We don't need it; this is ancient history. Nonetheless, feel free to
>> be consistent with the old style. I'll approve it.

I understand. Thank you, Andrew!

On 2020/07/30 21:13, Yasumasa Suenaga wrote:

Hi Koichi,

Looks good your change.

BTW have you got a sponsor?
I will sponsor you if you do not have yet.


Thanks,

Yasumasa


I haven't found a sponsor yet. So I would appreciate it if you could 
sponsor this patch.


Thanks,
Koichi





On 2020/07/30 18:45, Andrew Haley wrote:

On 7/30/20 6:58 AM, Koichi Sakata wrote:

I just formatted the patch to be same as the other code.

Moreover, I saw the following code in k_standard.c.

if (_LIB_VERSION == _SVID_)
    exc.retval = zero;
else
    exc.retval = zero/zero;

Do we need to do like that in this patch? It seems to be related to the
old matherr(), but I'm not sure about that.


We don't need it; this is ancient history. Nonetheless, feel free to
be consistent with the old style. I'll approve it.

Re: Build error with GCC 10 in NetworkInterface.c and k_standard.c

[Yasumasa Suenaga]

Hi Koichi,

Looks good your change.

BTW have you got a sponsor?
I will sponsor you if you do not have yet.


Thanks,

Yasumasa


On 2020/07/30 18:45, Andrew Haley wrote:

On 7/30/20 6:58 AM, Koichi Sakata wrote:

I just formatted the patch to be same as the other code.

Moreover, I saw the following code in k_standard.c.

if (_LIB_VERSION == _SVID_)
exc.retval = zero;
else
exc.retval = zero/zero;

Do we need to do like that in this patch? It seems to be related to the
old matherr(), but I'm not sure about that.


We don't need it; this is ancient history. Nonetheless, feel free to
be consistent with the old style. I'll approve it.

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

[Daniel Fuchs]

Hi Alexey,

I have added myself as a reviewer to the CSR [1].
It would be good to get someone from security-dev to do the
same, and then move the CSR state to "Proposed".

best regards,

-- daniel

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

On 30/07/2020 10:17, Alexey Bakhtin wrote:

Gentle ping

Regards
Alexey

Re: Build error with GCC 10 in NetworkInterface.c and k_standard.c

[Andrew Haley]

On 7/30/20 6:58 AM, Koichi Sakata wrote:
> I just formatted the patch to be same as the other code.
> 
> Moreover, I saw the following code in k_standard.c.
> 
> if (_LIB_VERSION == _SVID_)
>exc.retval = zero;
> else
>exc.retval = zero/zero;
> 
> Do we need to do like that in this patch? It seems to be related to the 
> old matherr(), but I'm not sure about that.

We don't need it; this is ancient history. Nonetheless, feel free to
be consistent with the old style. I'll approve it.

-- 
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

Re: [PING?] RFR(s): 8247863: Unreachable code in OperatingSystemImpl.getTotalSwapSpaceSize()

[Severin Gehwolf]

On Thu, 2020-07-30 at 05:28 +, Baesken, Matthias wrote:
> > The only reason why a 0 was observed, was because the cgroup interface
> > files were missing and the old code mapped that to a 0. That's no
> > longer the case and, thus, it seems it would make the code clearer if
> > it wouldn't be there any more.
> > 
> > I don't feel strongly about this, though, and can just drop this patch.
> 
> Hi Severin, thanks for clarification, I'm fine with the patch !

Thanks for the review, Matthias.

Cheers,
Severin

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

[Alexey Bakhtin]

Gentle ping

Regards
Alexey

> On 15 Jul 2020, at 14:18, Alexey Bakhtin  wrote:
> 
> Hello Daniel,
> 
> I’ve updated CSR as you suggested and added kerberos ldap setup commands for 
> the client host in the JDK-8245527
> 
> Regards
> Alexey