Hi,
On Thu, Jul 23, 2020 at 6:01 AM Roger Riggs wrote:
> Hi David,
>
> Yep, that's the focal point.
> Its both debug and -Xcomp.
> There must be something that changes the timing or the synchronization
> or the sizes; but that's more than I know about how the VM works.
>
Just a really wild
Thanks Mandy!
David
On 23/07/2020 2:22 pm, Mandy Chung wrote:
Hi David,
Looks good.
Mandy
On 7/22/20 4:00 PM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
A number of native tests in hotspot and jdk
Hi Aleksei,
Looks good. I can sponsor this.
Mandy
On 7/22/20 1:32 AM, Aleksei Voitylov wrote:
Hi Mandy,
here is the webrev which addresses your comments:
http://cr.openjdk.java.net/~avoitylov/webrev.8247592.02/
Thanks,
-Aleksei
On 22/07/2020 02:26, Mandy Chung wrote:
Hi Aleksei,
Hi David,
Looks good.
Mandy
On 7/22/20 4:00 PM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
A number of native tests in hotspot and jdk include the jni_util.h
header file which is part of the sources
Hi David,
Yep, that's the focal point.
Its both debug and -Xcomp.
There must be something that changes the timing or the synchronization
or the sizes; but that's more than I know about how the VM works.
Running the TestHumongousNonArrayAllocation test repeatedly does show
the problem
On 23/07/2020 11:27 am, Roger Riggs wrote:
Hi David,
It took some digging in the hs_err files and looking at a core dump to
determine what class was being initialized.
Doh! I knew that [1]:
"So what are we trying to initialize? Unfortunately that's not
discernible from the hs_err file, but
Hi David,
It took some digging in the hs_err files and looking at a core dump to
determine what class
was being initialized.
I attached one to the current bug, there are others on the previous bug.
The "call_class_initializer" is the hook.
Roger
Stack:
Hi Roger,
On 23/07/2020 12:51 am, Roger Riggs wrote:
Please review a change to the Process reaper thread initialization to
preemptively
make sure classes ThreadLocalRandom and ConcurrentHashMap are initialized.
I don't see ThreadLocalRandom appearing in any of the stack traces. ??
David
Roger: You're absolutely right! I should have looked.
On Wed, Jul 22, 2020 at 5:25 PM Roger Riggs wrote:
>
> Hi Martin,
>
> That's a good idea, but unless I miss your point, there is no Reaper class,
> only a lambda that is used as to create the Executor for the reaper
> thread pool.
>
> Do you
Hi Martin,
That's a good idea, but unless I miss your point, there is no Reaper class,
only a lambda that is used as to create the Executor for the reaper
thread pool.
Do you mean to put it before or after lines 91-93? [1]
Thanks, Roger
[1]
Looks good.
I might move the static class preloading into a static method of the
reaper thread class, to make it clearly the responsibility of the
reaper thread class to enumerate and pre-load its dependencies.
On Wed, Jul 22, 2020 at 7:59 AM Peter Levart wrote:
>
> Hi Roger,
>
>
> I don't
Hi Mandy,
Looks good.
On 7/22/20 6:40 PM, Mandy Chung wrote:
Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8249939
Thanks
Mandy
On 7/22/20 1:55 PM, Joe Darcy wrote:
Hi Mandy,
The behavior change looks okay; please file a CSR for this too.
Thanks,
-Joe
On 7/22/2020
Thanks Igor!
David
On 23/07/2020 9:09 am, Igor Ignatyev wrote:
Hi David,
looks good to me.
-- Igor
On Jul 22, 2020, at 4:00 PM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
A number of native tests
Hi David,
looks good to me.
-- Igor
> On Jul 22, 2020, at 4:00 PM, David Holmes wrote:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
> webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
>
> A number of native tests in hotspot and jdk include the jni_util.h header
> file
Bug: https://bugs.openjdk.java.net/browse/JDK-8249940
webrev: http://cr.openjdk.java.net/~dholmes/8249940/webrev/
A number of native tests in hotspot and jdk include the jni_util.h
header file which is part of the sources for libjava and not part of the
testing framework, nor an exported
Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8249939
Thanks
Mandy
On 7/22/20 1:55 PM, Joe Darcy wrote:
Hi Mandy,
The behavior change looks okay; please file a CSR for this too.
Thanks,
-Joe
On 7/22/2020 12:04 PM, Mandy Chung wrote:
Webrev:
Hi, Naoto
The latest changes look good to me.
-Brent
On 7/22/20 10:23 AM, naoto.s...@oracle.com wrote:
Hi,
I revised the fix again, based on further suggestions:
https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
Changes from v.04 are (all in StringUTF16.java):
- The short cut
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/
FTR there's one more aarch64-specific change in shared code to enable
aarch64_neon.ad processing:
diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk
b/make/hotspot/gensrc/GensrcAdlc.gmk
---
On 7/22/20 1:43 PM, naoto.s...@oracle.com wrote:
Thanks Roger,
Ah, I just saw your email just after I sent mine!
They probably saw each other crossing and said hi on the way to inboxes ;-)
On 7/22/20 1:38 PM, Roger Riggs wrote:
Hi Naoto,
Looks fine. (with Joe's suggestion)
On 7/22/20
Hi Mandy,
The behavior change looks okay; please file a CSR for this too.
Thanks,
-Joe
On 7/22/2020 12:04 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
A small improvement to the dynamic proxy generated method to have
ACC_VARARGS matching
Thanks Roger,
Ah, I just saw your email just after I sent mine!
On 7/22/20 1:38 PM, Roger Riggs wrote:
Hi Naoto,
Looks fine. (with Joe's suggestion)
On 7/22/20 4:20 PM, Joe Wang wrote:
Hi Naoto,
The change looks good to me. "supLower" is indeed super slow :-)
The only minor comment I have
Hi Naoto,
Looks fine. (with Joe's suggestion)
On 7/22/20 4:20 PM, Joe Wang wrote:
Hi Naoto,
The change looks good to me. "supLower" is indeed super slow :-)
The only minor comment I have is that the compareCodePointCI method
performs toUpperCase unconditionally. That's not a problem for the
Hi Joe,
Thank you for the consecutive reviews!
On 7/22/20 1:20 PM, Joe Wang wrote:
Hi Naoto,
The change looks good to me. "supLower" is indeed super slow :-)
The only minor comment I have is that the compareCodePointCI method
performs toUpperCase unconditionally. That's not a problem for
Hi Naoto,
The change looks good to me. "supLower" is indeed super slow :-)
The only minor comment I have is that the compareCodePointCI method
performs toUpperCase unconditionally. That's not a problem for the
regular case, where a check on cp1 == cp2 (line 337) is done prior to
the method
looks good.
/Andy
On 7/17/2020 10:35 PM, alexander.matv...@oracle.com wrote:
Hi Alexey,
Fixed as per your suggestion:
http://cr.openjdk.java.net/~almatvee/8245311/webrev.01/
Thanks,
Alexander
On 7/17/20 4:26 PM, Alexey Semenyuk wrote:
Alexander,
The change in RetryExecutor.java results in
Looks good!
- Alexey
On 7/17/2020 10:35 PM, alexander.matv...@oracle.com wrote:
Hi Alexey,
Fixed as per your suggestion:
http://cr.openjdk.java.net/~almatvee/8245311/webrev.01/
Thanks,
Alexander
On 7/17/20 4:26 PM, Alexey Semenyuk wrote:
Alexander,
The change in RetryExecutor.java results
Hi Mandy,
Looks fine.
Roger
On 7/22/20 3:04 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
A small improvement to the dynamic proxy generated method to have
ACC_VARARGS matching the method declared in a proxy interface if set.
If there are
https://bugs.openjdk.java.net/browse/JDK-8244778
http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v01/
Please review this patch that stores the full module graph in the CDS
archive heap. This reduces the initialization time of the basic JVM by
about 22%:
$ perf stat -r
Hi Peter,
yes, the reference to ConcurrentHashMap seems ineffective and unnecessary.
Updated Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-1/
Thanks, Roger
On 7/22/20 10:58 AM, Peter Levart wrote:
Hi Roger,
I don't think resolving the ConcurrentHashMap.class
Webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
A small improvement to the dynamic proxy generated method to have
ACC_VARARGS matching the method declared in a proxy interface if set.
If there are two or more proxy interfaces declaring such a method,
it matches the
Hello,
> On Jul 22, 2020, at 4:52 AM, Raffaello Giulietti
> wrote:
>
> the CSR for read(char[],int,int) does not explicitly specify that "line
> terminators are compressed into single newline ('\n') characters", as the
> no-arg read() spec does.
>
> Thus, it's not entirely clear what
Hi,
I revised the fix again, based on further suggestions:
https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
Changes from v.04 are (all in StringUTF16.java):
- The short cut now does case insensitive comparison that makes the fix
closer to the previous implementation (for BMP
Hi Roger,
I don't think resolving the ConcurrentHashMap.class ensures
initialization of the class. Just loading. But I think CHM is already
initialized at that time as it is used in ClassLoader to maintain class
loading locks (per class name).
Regards, Peter
On 7/22/20 4:51 PM, Roger
Hi Andrew,
Thank you for teaching me.
I made the patch that returns NaN. Could you please sponsor it?
In this case I think it is better to fix k_standard.c itself rather than
ignoring the warning. However, I was able to learn there are some good
ways to suppress warnings. So I'd like to thank
Please review a change to the Process reaper thread initialization to
preemptively
make sure classes ThreadLocalRandom and ConcurrentHashMap are initialized.
From the stack overflow failures, it seems that the classes have not
been initialized
before they are used during processing the
Hello,
the CSR for read(char[],int,int) does not explicitly specify that "line
terminators are compressed into single newline ('\n') characters", as
the no-arg read() spec does.
Thus, it's not entirely clear what happens when the buffer is just large
enough to accept the \r in a \r\n
On 17/07/2020 12:26, Koichi Sakata wrote:
>
> > You'll need to find a reviewer that understands what that
> > method is supposed to do in that case, that's not me ;-)
>
> I understand. This ML is suitable for finding a reviewer, isn't it?
> Or, there is another way. We can avoid the error by
Hi Mandy,
here is the webrev which addresses your comments:
http://cr.openjdk.java.net/~avoitylov/webrev.8247592.02/
Thanks,
-Aleksei
On 22/07/2020 02:26, Mandy Chung wrote:
> Hi Aleksei,
>
>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
>
> This refactoring seems okay. I
> On Apr 8, 2020, at 5:27 AM, David Holmes wrote:
>
> Hi Kim,
Apparently I lost track of these comments and forgot to respond.
I still won't be sending out a new webrev until some of the other
discussion gets settled. There's been some internal discussion, but
I'm currently waiting on some
39 matches
Mail list logo
