Please review the jpackage fix for bug [1] at [2].
- "hdiutil detach" resource busy error is fixed in same way as
JDK-8242786 by repeating detach several times.
- pkgbuild timeout will be covered with JDK-8249395.
[1] https://bugs.openjdk.java.net/browse/JDK-8245311
[2] http://cr.openjdk.java.
Hi Andy,
Can you double check two other places where File.list() was introduced
with JDK-8223955 for similar issues?
One in MacPkgBundler.java and second in DeployParams.java.
Thanks,
Alexander
On 7/15/20 3:09 PM, Alexey Semenyuk wrote:
Andy,
Stream.close() call is missing on the result of
Andy,
Stream.close() call is missing on the result of Files.list() call.
I'd also replace Files.list(root) with Files.walk(root, 1) call to
eliminate diving in directory tree.
- Alexey
On 7/15/2020 2:37 PM, Andy Herrick wrote:
Please review the jpackage fix for issue [1] at [2].
This fixes
Hi Roger,
On 2020-07-15 22:21, Roger Riggs wrote:
Hi Raffaello,
Base64.java:
2: Please update 2nd copyright year to 2020
I was unsure what to do here, thanks for guidance.
I also removed the seemingly useless import at former L33.
leftovers():
996: "&" the shortcutting && is more typical
Hi Raffaello,
Base64.java:
2: Please update 2nd copyright year to 2020
leftovers():
996: "&" the shortcutting && is more typical in a condition.
997: the -= is buried in an expression and a reader might miss it.
1053: "can be reallocated to other vars": not a useful comment,
reflecting on o
Hi Alan,
> On 15/07/2020 18:20, rken...@redhat.com wrote:
> > DirectBufferAllocTest is unreliable when running with
> > +ExplicitGCInvokesConcurrent, because allocating DBB spreads
> > System.gc() calls all over concurrent GC cycles. It becomes more
> > reliable when running with -ExplicitGCInvoke
👍
📱
> On Jul 15, 2020, at 4:32 PM, Joe Wang wrote:
>
> Jim: I was referring to the rest of the process (the calls to
> toCodePoint/toUpperCase/toLowerCase), not isHighSurrogate itself. But Roger
> has a more comprehensive review on performance, and Naoto is planning on
> preparing a JMH tes
Jim: I was referring to the rest of the process (the calls to
toCodePoint/toUpperCase/toLowerCase), not isHighSurrogate itself. But
Roger has a more comprehensive review on performance, and Naoto is
planning on preparing a JMH test.
-Joe
On 7/15/2020 11:46 AM, Jim Laskey wrote:
Joe: This is
Joe: This is a defensive approach that I believe has minimal cost.
public static boolean isHighSurrogate(char ch) {
// Help VM constant-fold; MAX_HIGH_SURROGATE + 1 == MIN_LOW_SURROGATE
return ch >= MIN_HIGH_SURROGATE && ch < (MAX_HIGH_SURROGATE + 1);
}
> On Jul 15, 2020,
On 15/07/2020 18:20, rken...@redhat.com wrote:
DirectBufferAllocTest is unreliable when running with
+ExplicitGCInvokesConcurrent, because allocating DBB spreads
System.gc() calls all over concurrent GC cycles. It becomes more
reliable when running with -ExplicitGCInvokesConcurrent. (Shenandoah
d
Please review the jpackage fix for issue [1] at [2].
This fixes the regression in JDK16 which caused exception when an empty
directory was used int the --temp jpackage option, and added to the
existing test.
[1] - https://bugs.openjdk.java.net/browse/JDK-8249289
[2[ - http://cr.openjdk.java.
Hi Joe,
Thank you for your review.
On 7/15/20 10:57 AM, Joe Wang wrote:
Hi Naoto,
In StringUTF16.java, if one is isHighSurrogate and the other not, you
may quickly return without going through the rest of the process,
probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal
a
Hi Roger,
Thank you for your review and suggestions.
On 7/15/20 10:56 AM, Roger Riggs wrote:
Hi Naoto,
Given the extra tests in the body of the loop, I think its worth finding
or creating
a JMH test for this and checking the performance.
Good point.
With performance in mind, I would try
Hi Naoto,
In StringUTF16.java, if one is isHighSurrogate and the other not, you
may quickly return without going through the rest of the process,
probably not significant as cp1 and cp2 and/or u1 and u2 won't be equal
anyways. But it could skip a couple of
toCodePoint/toUpperCase/toLowerCase
Hi Naoto,
Given the extra tests in the body of the loop, I think its worth finding
or creating
a JMH test for this and checking the performance.
With performance in mind, I would try to fall back to the UC/LC
conversions only
when the bytes don't match. See java.util.Arrays.mismatch(byte[],
In StringJoiner::toString
final int addLen = prefix.length() + suffix.length();
Looks suspicious. There is no check for overflow here. Looking at the
constructor it should have raised a OOM much earlier. Will investigate and file
a bug.
Thanks.
-- Jim
> On Jul 15, 2020, at 1:21 PM,
DirectBufferAllocTest is unreliable when running with
+ExplicitGCInvokesConcurrent, because allocating DBB spreads
System.gc() calls all over concurrent GC cycles. It becomes more
reliable when running with -ExplicitGCInvokesConcurrent. (Shenandoah
defaults to +ExplicitGCInvokesConcurrent, other GC
Thank you, Jim, for the quick review!
On 7/15/20 9:26 AM, Jim Laskey wrote:
I think I'm good with this. +1
Asides:
325 int cp1 = (int)getChar(value, k1);
326 int cp2 = (int)getChar(other, k2);
I would be tempted to short cut by exiting when not equal, but I think w
I think I'm good with this. +1
Asides:
325 int cp1 = (int)getChar(value, k1);
326 int cp2 = (int)getChar(other, k2);
I would be tempted to short cut by exiting when not equal, but I think we
agreed we need to allow for upper/lowers on different planes.
In the UTF-16
Hi,
I looked a bit at the allocations themselves, but first answering
questions.
On 15.07.20 15:25, David Holmes wrote:
> On 15/07/2020 10:18 pm, Jim Laskey wrote:
>> Thomas explained: That large objects are never moved (outstanding
>> issue) So, it's possible to fragment the -Xmx4g such tha
Hello,
Please review the fix to the following issues:
https://bugs.openjdk.java.net/browse/JDK-8248655
https://bugs.openjdk.java.net/browse/JDK-8248434
The proposed changeset and its CSR are located at:
https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.00/
https://bugs.openjdk.java.net
Hi,
On 15.07.20 15:35, Jim Laskey wrote:
Try this:
- You have a 4G heap.
- You allocate some stuff, say 1 byte.
- You allocate a 2G object - so there is only 2G - 1, left. Not enough space
for another 2G object.
- But you do allocate 1 byte.
- You have 1 byte, 2G and 1 byte.
- You free the ori
Hello Severin ,
> the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return 0
Wouldn’t it be possible that the coding of getMemoryAndSwapLimit returns a
negative value (might not happen on a "healthy" system but you never know) :
jdk/src/j
Try this:
- You have a 4G heap.
- You allocate some stuff, say 1 byte.
- You allocate a 2G object - so there is only 2G - 1, left. Not enough space
for another 2G object.
- But you do allocate 1 byte.
- You have 1 byte, 2G and 1 byte.
- You free the original 2G object.
- But something allocates 1
On 15/07/2020 10:18 pm, Jim Laskey wrote:
Thomas explained: That large objects are never moved (outstanding issue) So,
it's possible to fragment the -Xmx4g such that a 2G object can't be allocated,
Naively one would expect that whatever memory was consumed by
String maxString = "*".repeat(MAX
Thomas explained: That large objects are never moved (outstanding issue) So,
it's possible to fragment the -Xmx4g such that a 2G object can't be allocated,
> On Jul 15, 2020, at 8:55 AM, Jim Laskey wrote:
>
> Since the MAX_STRING is 2Gbytes, I wonder if those strings are allocated on
> the sid
Since the MAX_STRING is 2Gbytes, I wonder if those strings are allocated on the
side per se and are subject to the platforms VM whims.
> On Jul 14, 2020, at 8:36 PM, David Holmes wrote:
>
> On 15/07/2020 5:35 am, Roger Riggs wrote:
>> Looks good.
>> Though it does seem like the VM should have b
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
> On 14 Jul 2020, at 18:28, Daniel Fuchs wrote:
>
> Hi Alexey,
>
> On 10/07/2020 21:37, Alexey Bakhtin wrote:
>> Updated webrev:http://cr.openjdk.java.
Anyone?
On Mon, 2020-06-29 at 17:53 +0200, Severin Gehwolf wrote:
> Hi,
>
> Could I please get a review of this dead-code removal? During review of
> JDK-8244500 it was discovered that with the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return
> 0
Hi Alexey,
Thanks for addressing comments and answering questions. The JNDI changes
in latest webrev looks good to me.
CI is also happy with the latest changes.
Best,
Aleksei
On 10/07/2020 21:37, Alexey Bakhtin wrote:
Hello Aleksei,
Thank you for review.
Please see my comments below.
Updat
30 matches
Mail list logo
