t;
> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should
> be `NonHeapUsage = CodeCache + Metaspace`.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
update
-
Changes:
- all: https://git.openjdk.ja
t;
> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should
> be `NonHeapUsage = CodeCache + Metaspace`.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
remove compressed class space pool
-
Changes:
- al
On Fri, 27 May 2022 06:22:36 GMT, Ioi Lam wrote:
> I think the right fix is to just convert the MetaspacePool into
> NonClassMetaspacePool and only report the non-class values.
Yes, it's okay for me. But I have another concern.
The compressed class pool is not directly used by other VM compone
On Thu, 26 May 2022 22:17:17 GMT, David Holmes wrote:
>> Beside my general points, I think this patch makes sense. I agree with
>> @kelthuzadx that counting Classspace twice is wrong, whatever the intention
>> of this API originally was.
>
> Yes counting it twice is wrong but this is the wrong
On Thu, 26 May 2022 07:34:59 GMT, David Holmes wrote:
>> This is also acceptable, but if we add more memory pools, we might add more
>> special pools to exclude their space from nonheap. Instead, we can specify
>> exactly which pools we need to accumulate, which is what this change did.
>
> I t
On Thu, 26 May 2022 05:08:13 GMT, Ioi Lam wrote:
>> It seems that calculation of
>> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>>
>> Currently,
>> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>>
>> ==> CodeHeap
On Mon, 23 May 2022 09:58:46 GMT, David Holmes wrote:
> Sorry but I can't agree with this change as presented. By definition the
> total non-heap memory is the sum of all pools which identify as non-heap as
> per the specification:
>
> "The non-heap memory consists of one or more memory pools.
It seems that calculation of
MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
Currently, NonHeapUsage = CodeCache + Metaspace + CompressedClassSpace
==> CodeHeap 'non-nmethods' 1532544 (Used)
==> CodeHeap 'profiled nmethods' 0
==> CodeHeap 'non-profiled nmethods' 13952
==> Metasp
On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote:
>> Found various typos of expected: `exepected`, `exept`, `epectedly`,
>> `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8284853: Fi
On Wed, 16 Mar 2022 02:57:20 GMT, Yi Yang wrote:
>> When we use jcmd Thread.dump/jstack , we could dump all Java
>> thread stack trace, but unfortunately we are not able to print NonJavaThread
>> stack trace such as VMThread/GCWorker, etc. For these threads, we know
>>
futex_wait.constprop.1+0x29
>
> "G1 Conc#12" os_prio=0 cpu=1.17ms elapsed=23.05s tid=0x00007f152c009df0
> nid=116033 runnable
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0
futex_wait.constprop.1+0x29
>
> "G1 Conc#12" os_prio=0 cpu=1.17ms elapsed=23.05s tid=0x00007f152c009df0
> nid=116033 runnable
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0
When we use jcmd Thread.dump/jstack , we could dump all Java thread
stack trace, but unfortunately we are not able to print NonJavaThread stack
trace such as VMThread/GCWorker, etc. For these threads, we know nothing about
what are they doing/are they blocked in pthread condition from jstack ou
On Mon, 17 Jan 2022 09:31:54 GMT, Yi Yang wrote:
> Add VM.classes to print details of all classes, output looks like:
>
> 1. jcmd VM.classes
>
> KlassAddr Size State Flags LoaderName ClassName
> 0x000800c0b400 62 inited W bootstrap
> java.lang.invoke.LambdaForm$
On Fri, 4 Mar 2022 09:05:36 GMT, Yi Yang wrote:
>> Add VM.classes to print details of all classes, output looks like:
>>
>> 1. jcmd VM.classes
>>
>> KlassAddr Size State Flags LoaderName ClassName
>> 0x000800c0b400 62 inited W bootstrap
>> java.la
On Fri, 4 Mar 2022 09:05:36 GMT, Yi Yang wrote:
>> Add VM.classes to print details of all classes, output looks like:
>>
>> 1. jcmd VM.classes
>>
>> KlassAddr Size State Flags LoaderName ClassName
>> 0x000800c0b400 62 inited W bootstrap
>> java.la
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invoke
On Fri, 4 Mar 2022 08:14:39 GMT, Ioi Lam wrote:
> Numbers should be aligned to the right. The following is what I want:
>
> ```
> 62
> 123
> 4567
> ```
Done.
-
PR: https://git.openjdk.java.net/jdk/pull/7105
On Fri, 4 Mar 2022 05:13:58 GMT, Ioi Lam wrote:
> You should change it to `%4d`. Otherwise, when the numbers are changed in the
> future (e.g., to 3 or 4 digits) they will be misaligned:
>
> ```
> KlassAddr Size State FlagsClassName
> 0x000800df8400 62f
On Fri, 4 Mar 2022 07:12:03 GMT, Lin Zang wrote:
> Sorry that I just chime in. It seems this change adds new command options, so
> it seems that `csr` is required?
Hi @linzang, according to [previous
discussion](https://github.com/openjdk/jdk/pull/6075) and [comments in
JBS](https://bugs.open
On Fri, 4 Mar 2022 03:43:59 GMT, David Holmes wrote:
>> I'm not sure what's the meaning of "non-trivial finalize" method, can you
>> elaborate more for it?
>> (P.S. All comments are addressed)
>
> I mean a finalize() method that actually does something. I checked the code
> and you will print F
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invoke/LambdaForm$D
On Wed, 19 Jan 2022 02:50:16 GMT, Chris Plummer wrote:
>>> It seems it would be useful to support the verbose output with just a
>>> single class that is specified, although that would suggest that the dcmd
>>> name should then be something other than `VM.classes`.
>>
>> This is a good idea, b
On Fri, 11 Feb 2022 06:53:23 GMT, David Holmes wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix
>
> src/hotspot/share/services/diagnosticCommand.cpp line 964:
>
>> 962:
On Fri, 4 Mar 2022 03:29:51 GMT, David Holmes wrote:
>> Yi Yang has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'master' into jcmd_classes
>> - typo
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invoke/LambdaForm$DMH+0x000
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invoke/LambdaForm$DMH+0x
On Fri, 11 Feb 2022 06:49:25 GMT, David Holmes wrote:
>> src/hotspot/share/oops/instanceKlass.cpp line 2081:
>>
>>> 2079: _st->print(INTPTR_FORMAT " ", p2i(k));
>>> 2080: // klass size
>>> 2081: _st->print("%-4d ", k->size());
>>
>> Should be `%4d` so that the numbers are aligned correc
On Tue, 18 Jan 2022 02:59:11 GMT, David Holmes wrote:
>> Yi Yang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains
On Mon, 24 Jan 2022 04:12:22 GMT, Ioi Lam wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix test
>
> src/hotspot/share/oops/instanceKlass.cpp line 2106:
>
>> 2104: // clas
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invoke/LambdaForm$DMH+0x00
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invoke/
On Wed, 19 Jan 2022 02:37:10 GMT, Yi Yang wrote:
>> Add VM.classes to print details of all classes, output looks like:
>>
>> 1. jcmd VM.classes
>>
>> KlassAddr Size State Flags LoaderName ClassName
>> 0x000800c0b400 62 inited W bootstra
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invoke/LambdaForm$DMH+
On Tue, 18 Jan 2022 19:43:12 GMT, Chris Plummer wrote:
> It seems it would be useful to support the verbose output with just a single
> class that is specified, although that would suggest that the dcmd name
> should then be something other than `VM.classes`.
This is a good idea, but `jcmd VM.
rray(0x)
> - inner classes: Array(0x0008005af6d8)
> - nest members: Array(0x0008005af6d8)
> - permitted subclasses: Array(0x0008005af6d8)
> - java mirror: a 'java/lang/Class'{0x00011f4b0968} =
> 'java/lang/invok
On Tue, 18 Jan 2022 03:10:11 GMT, David Holmes wrote:
>> Yi Yang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains
On Tue, 18 Jan 2022 03:04:15 GMT, David Holmes wrote:
>> Yi Yang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains
Hi all,
I had an offline discussion about this with Denghui, when I first time hear
this idea, I felt it was useful. It allows users to do some stuff that requires
a lot of effort in a simple way. I'm also tracking discussion on the mailing
list, I've seen many folks come up with very construct
On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich
wrote:
> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be
> qualified.
> Testing:
> - `make test TEST="gtest"`: Passed
> - `make run-test TEST="tier1"`: Passed
> - `make run-test TEST="tier2"`: Passed
> - `make run
That seems an ideal solution. I think there are some potential code
consolidation work further. With this change, some existing C++ JFR Jcmd
structure definitions(and other Jcmd commands) in VM level can also be lifted
to Java level because they simply forward request to Java level by
JavaCalls
On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg
wrote:
> This PR fixes the following spelling errors:
>
> choosen -> chosen
> commad -> command
> hiearchy -> hierarchy
> leagacy -> legacy
> minium -> minimum
> subsytem -> subsystem
> unamed -> unnamed
Hi, I've filed https://bugs
On Wed, 28 Jul 2021 08:24:41 GMT, Jie Fu wrote:
> For hotspot changes, it would be better to have a second review & wait for 24
> hours before integration.
> Thanks.
Well, it seems a trivial change, maybe one review is okay. For non-trivial
changes, we really need more reviews and wait for 24h
On Wed, 28 Jul 2021 07:19:08 GMT, Yi Yang wrote:
> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph
> XML.
Thank you Jie for review!
-
PR: https://git.openjdk.java.net/jdk/pull/4917
On Wed, 28 Jul 2021 07:19:08 GMT, Yi Yang wrote:
> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph
> XML.
This pull request has now been integrated.
Changeset: 072fe486
Author: Yi Yang
URL:
https://git.openjdk.java.net/jdk/
> Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph
> XML.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
update copyright year
-
Changes:
- all: https://git.openjdk.java.net/jdk/pul
Should be PHASE_CCP instead of PHASE_CPP, it also affects dumped ideal graph
XML.
-
Commit messages:
- typo
Changes: https://git.openjdk.java.net/jdk/pull/4917/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4917&range=00
Issue: https://bugs.openjdk.java.net/browse/J
On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has
On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote:
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
This pull request has now been integrat
On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has refreshed the contents of this pull request, and previous commits
have bee
On Wed, 7 Jul 2021 17:08:19 GMT, Mandy Chung wrote:
>>> Does "client changes" means changes involving src/java.desktop and
>>> test/java/awt?
>>
>> src/java.desktop, test/java/awt, and test/javax/imageio
>
>> > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
>> > nee
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with two additional commits
since the
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with four additional commits
since the
On Tue, 6 Jul 2021 19:06:43 GMT, Mandy Chung wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> tests rely on IOOBE exception message
>
> test/jdk/java/lang/StringBuffer/Exc
On Thu, 10 Jun 2021 02:07:36 GMT, Yi Yang wrote:
> From users' perspective, we can find corresponding os thread via top
> directly, otherwise, we must convert hex format based nid to an integer, and
> find that thread via `top -pid `. This slightly facilitates our
> debug
On Tue, 6 Jul 2021 03:08:42 GMT, David Holmes wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use \p{XDigit}
>
> src/hotspot/share/runtime/osThread.cpp line 41:
>
>> 39: //
On Wed, 30 Jun 2021 06:38:30 GMT, Yi Yang wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
&g
On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang wrote:
>> Class loading order is different to class initialization order.
>>
>> There are a lot more tests than just tier1. :) I don't expect many, if any,
>> tests to be looking for a specific IOOBE message, and I can'
On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Class loading order is different to class ini
MEM TIME+ COMMAND
> 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
> 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
> 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 jav
On Wed, 30 Jun 2021 02:43:29 GMT, Yi Yang wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
&g
On Wed, 30 Jun 2021 04:42:19 GMT, Thomas Stuefe wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright
>
> test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.
MEM TIME+ COMMAND
> 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
> 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
> 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 jav
On Tue, 29 Jun 2021 11:54:55 GMT, Kevin Walls wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore cleanup code
>
> src/hotspot/share/runtime/osThread.cpp line 41:
>
>&g
MEM TIME+ COMMAND
> 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
> 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
> 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 jav
On Mon, 28 Jun 2021 13:07:21 GMT, Kevin Walls wrote:
> If so (and if we don't discover more tools that prefer hex for thread IDs!),
> then we want to be consistent, so in addition to the native/built in
> implementation, we should also update:
> src/jdk.hotspot.agent/share/classes/sun/jvm/hots
MEM TIME+ COMMAND
> 49083 tianxia+ 20 0 32.8g 594148 10796 S 103.3 0.1 0:10.05 java
> 71291 qingfen+ 20 0 39.3g 26.7g 18312 S 100.7 5.3 16861:35 jhsdb
> 50407 tianxia+ 20 0 32.5g 32796 9768 S 100.3 0.0 0:05.80 java
> 107429 maolian+ 20 0 11.4g 1.1g 10956 S 100.3 0.2 20173:52 jav
On Mon, 28 Jun 2021 06:16:14 GMT, Thomas Stuefe wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
>> debugging process
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
On Tue, 22 Jun 2021 02:39:01 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Y
On Mon, 21 Jun 2021 20:49:56 GMT, Paul Sandoz wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> more replacement 2
>
> src/java.base/share/classes/jdk/internal/util/Precon
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
On Fri, 18 Jun 2021 18:03:44 GMT, Paul Sandoz wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the last re
On Thu, 17 Jun 2021 15:45:47 GMT, Paul Sandoz wrote:
>> src/java.base/share/classes/java/util/Base64.java line 934:
>>
>>> 932: if (closed)
>>> 933: throw new IOException("Stream is closed");
>>> 934: Preconditions.checkFromIndexSize(len, off, b.length, (x
On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Y
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
On Thu, 17 Jun 2021 10:19:43 GMT, Alan Bateman wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore IndexOfOufBoundsException; split exception line
>
> src/jav
On Thu, 17 Jun 2021 01:51:41 GMT, David Holmes wrote:
> I skimmed through all these and the changes seem fine in principal.
> I have two mild concerns:
>
> 1. How does this change the class initialization order on VM startup?
> 2. Do any tests need adjusting due to potential changes in the exact
After JDK-8265518, it's possible to replace all variants of checkIndex by
Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the
whole JDK codebase.
-
Commit messages:
- use checkIndex globally
Changes: https://git.openjdk.java.net/jdk/pull/4507/files
Webre
On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine
wrote:
> If the /proc/stat mount point is changed in container environment, the while
> loop may lead to 100% cpu usage.
I have encountered a similar problem before, I've filed a new issue
https://bugs.openjdk.java.net/browse/JDK-8268361 for this. Yo
NotANode(node.hpp) and not_a_node(compile.cpp) are completely repeated guys.
-
Commit messages:
- not_a_node
Changes: https://git.openjdk.java.net/jdk/pull/3715/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3715&range=00
Issue: https://bugs.openjdk.java.net/browse/J
86 matches
Mail list logo
