Re: RFR(S): 8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option

[serguei.spit...@oracle.com]

Hi Chris,

It looks good to me.

Thanks,
Serguei


On 2/13/19 18:43, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218941/webrev
https://bugs.openjdk.java.net/browse/JDK-8218941

Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[Chris Plummer]

Hi David,

I can update the man page. Can you point me to where it is in the 
source? I haven't been able to find it. It seems to be out of date in 
other ways also. This is what the output looks like (with my fix).


main[1] threads
Group system:
  (java.lang.ref.Reference$ReferenceHandler)908 Reference Handler running
  (java.lang.ref.Finalizer$FinalizerThread)909  Finalizer cond. waiting
  (java.lang.Thread)910 Signal Dispatcher running
Group main:
  (java.lang.Thread)1   main running (at 
breakpoint)

Group InnocuousThreadGroup:
  (jdk.internal.misc.InnocuousThread)911    Common-Cleaner cond. 
waiting


Note there is no index printed as the docs suggest. Also, the docs don't 
even mention having the threadID printed.


I found this change very useful while using jdb to debug the JDWP debug 
agent. If I don't push it, it will likely just stay as an uncommitted 
change in my local repo indefinitely since I continue to find use for it.


As for the status of jdb, it is supported and we do actively fix it. 
It's greatest use is probably in testing JDI, since a large number of 
JDI tests do so using jdb. Also, I've been using it a lot lately to test 
loom debugging support I've been adding to the JDWP debug agent.


I don't know about needing a CSR request. The rules for needing one 
elude me. I consider you the expert in that area. :)


thanks,

Chris

On 2/13/19 8:53 PM, David Holmes wrote:



pps. You'll also need to update the man page as it has an example 
showing the hex:


 threads
  List the threads that are currently running. For each 
thread, its name and current status are printed and
  an index that can be used in other commands. In this 
example, the thread index is 4, the thread is an
  instance of java.lang.Thread, the thread name is main, 
and it is currently running.


  4. (java.lang.Thread)0x1 main  running

Is this change really worth bothering with? What's the status of jdb 
(I was surprised to seem this is all an example!) ? Does this need a 
CSR request?


Cheers,
David
On 14/02/2019 2:36 pm, David Holmes wrote:

PS.

  return MessageOutput.format("object description and hex id",

Need to change the message too!

David

On 14/02/2019 2:32 pm, David Holmes wrote:

Hi Chris,

On 14/02/2019 1:37 pm, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947


Are there times you may want to correlate those thread ids with ones 
in other logs/tools that are in hex?


That aside:

java.lang.Long.toString

you don't need the java.lang part (it's always implicitly imported).

Thanks,
David
-


Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[Chris Plummer]

Ok. I'll fix.

thanks,

Chris

On 2/13/19 8:36 PM, David Holmes wrote:

PS.

 return MessageOutput.format("object description and hex id",

Need to change the message too!

David

On 14/02/2019 2:32 pm, David Holmes wrote:

Hi Chris,

On 14/02/2019 1:37 pm, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947


Are there times you may want to correlate those thread ids with ones 
in other logs/tools that are in hex?


That aside:

java.lang.Long.toString

you don't need the java.lang part (it's always implicitly imported).

Thanks,
David
-


Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[Chris Plummer]

On 2/13/19 8:32 PM, David Holmes wrote:

Hi Chris,

On 14/02/2019 1:37 pm, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947


Are there times you may want to correlate those thread ids with ones 
in other logs/tools that are in hex?

Not that I know of. It hasn't turned up in tests.


That aside:

java.lang.Long.toString

you don't need the java.lang part (it's always implicitly imported).


Ok. I'll change that.

thanks,

Chris


Thanks,
David
-


Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(S): 8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option

[serguei.spit...@oracle.com]

Hi Chris,

It looks good to me.

Thanks,
Serguei


On 2/13/19 18:43, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218941/webrev
https://bugs.openjdk.java.net/browse/JDK-8218941

Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[David Holmes]

On 14/02/2019 2:53 pm, David Holmes wrote:




oops! Okay on-list then. No big deal :)

David

pps. You'll also need to update the man page as it has an example 
showing the hex:


  threads
   List the threads that are currently running. For each 
thread, its name and current status are printed and
   an index that can be used in other commands. In this 
example, the thread index is 4, the thread is an
   instance of java.lang.Thread, the thread name is main, 
and it is currently running.


   4. (java.lang.Thread)0x1 main  running

Is this change really worth bothering with? What's the status of jdb (I 
was surprised to seem this is all an example!) ? Does this need a CSR 
request?


Cheers,
David
On 14/02/2019 2:36 pm, David Holmes wrote:

PS.

  return MessageOutput.format("object description and hex id",

Need to change the message too!

David

On 14/02/2019 2:32 pm, David Holmes wrote:

Hi Chris,

On 14/02/2019 1:37 pm, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947


Are there times you may want to correlate those thread ids with ones 
in other logs/tools that are in hex?


That aside:

java.lang.Long.toString

you don't need the java.lang part (it's always implicitly imported).

Thanks,
David
-


Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[David Holmes]

pps. You'll also need to update the man page as it has an example 
showing the hex:


 threads
  List the threads that are currently running. For each 
thread, its name and current status are printed and
  an index that can be used in other commands. In this 
example, the thread index is 4, the thread is an
  instance of java.lang.Thread, the thread name is main, 
and it is currently running.


  4. (java.lang.Thread)0x1 main  running

Is this change really worth bothering with? What's the status of jdb (I 
was surprised to seem this is all an example!) ? Does this need a CSR 
request?


Cheers,
David
On 14/02/2019 2:36 pm, David Holmes wrote:

PS.

  return MessageOutput.format("object description and hex id",

Need to change the message too!

David

On 14/02/2019 2:32 pm, David Holmes wrote:

Hi Chris,

On 14/02/2019 1:37 pm, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947


Are there times you may want to correlate those thread ids with ones 
in other logs/tools that are in hex?


That aside:

java.lang.Long.toString

you don't need the java.lang part (it's always implicitly imported).

Thanks,
David
-


Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[David Holmes]

PS.

 return MessageOutput.format("object description and hex id",

Need to change the message too!

David

On 14/02/2019 2:32 pm, David Holmes wrote:

Hi Chris,

On 14/02/2019 1:37 pm, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947


Are there times you may want to correlate those thread ids with ones in 
other logs/tools that are in hex?


That aside:

java.lang.Long.toString

you don't need the java.lang part (it's always implicitly imported).

Thanks,
David
-


Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[David Holmes]

Hi Chris,

On 14/02/2019 1:37 pm, Chris Plummer wrote:

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947


Are there times you may want to correlate those thread ids with ones in 
other logs/tools that are in hex?


That aside:

java.lang.Long.toString

you don't need the java.lang part (it's always implicitly imported).

Thanks,
David
-


Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex

[Chris Plummer]

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947

Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

RFR(S): 8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option

[Chris Plummer]

Hi,

Please review the following:

http://cr.openjdk.java.net/~cjplummer/8218941/webrev
https://bugs.openjdk.java.net/browse/JDK-8218941

Tested by running the following on all supported platforms:

open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi

thanks,

Chris

Re: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command

[Nick Gasson (Arm Technology China)]

On 12/02/2019 23:32, Andrew Haley wrote:
> What's the status of this? Are you still looking at it?
> 

Apologies, I was on holiday until today so haven't done anything on it. 
I'll send an updated patch shortly...

Nick

Re: RFR(T) : 8209455 : [error-prone] JdkObsolete in jdk.management.agent

[Jean Christophe Beyler]

Hi Igor,

Looks good to me :)
Jc

On Wed, Feb 13, 2019 at 11:24 AM Igor Ignatyev 
wrote:

> Hi Alan,
>
> actually, String::join is enough in this case, uploaded webrev.01 --
> http://cr.openjdk.java.net/~iignatyev//8209455/webrev.01
>
> Thanks,
> -- Igor
>
> On Feb 12, 2019, at 11:04 PM, Alan Bateman 
> wrote:
>
> On 13/02/2019 00:01, Igor Ignatyev wrote:
>
> http://cr.openjdk.java.net/~iignatyev//8209455/webrev.00
>
> 2 lines changed: 0 ins; 0 del; 2 mod;
>
>
> Hi all,
>
> could you please review this trivial cleanup which replaces StringBuffer
> by StringBuilder in jdk.management.agent module?
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8209455/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209455
>
> Looks okay but StringJoiner might be better here.
>
> -Alan
>
>
>

-- 

Thanks,
Jc

Re: RFR: JDK-8066993: nsk.jdi.EventRequest.setEnabled.setenabled003 fails: event IS NOT a breakpoint

[gary.ad...@oracle.com]

Right now I'm proposing we use the bug number that matches the entry in 
the ProblemList to

remove the test from the ProblemList.

The other matching rules that were added for connection closed and the
other bugs with connection closed had no valid reason for attaching
to a bug with a specific error in a specific test. Since the other tests
were never added to the ProblemList, they obviously have not failed
in a long time. If those errors show up, new bugs should be filed.

This changeset would end up in jdk13. Since this change is specific
to the ProblemList, backports to the older releases would have to be
retested in those builds, if neeeded.

Presumably some other fix has made it so this test no longer is failing.

On 2/13/19 2:37 PM, Chris Plummer wrote:

Hi Gary,

Looks good. What are your plans for bug management? I think the CR 
should actually be closed as CNR and removal from the problemlist be 
done as a subtask.


Also, there are a lot of other failures reported with other tests 
under this bug. Kind of became a dumping ground, but none of them 
resulted in tests being quarantined. All of the reported failures seem 
to be with 8u60, and they probably still happen there. I'm not sure of 
the right procedure for closing out the bug in that case since no fix 
is being provided, so no backport can be done. Also, the affects 
versions includes 9 and 10. I think at some point Jerry reproduced 
something on 10, but didn't give any details. I'm not sure how to 
address that either.


Chris

On 2/13/19 8:53 AM, Gary Adams wrote:

The setenabled003 test has been on the ProblemList since it was first
moved to the open repos. After 1000 test runs on {solaris, macosx, 
windows, linux}
for the test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled 
tests,

the problem does not currently reproduce.

My recommendation is that we remove it from the ProblemList at this 
time.



diff --git a/test/hotspot/jtreg/ProblemList.txt 
b/test/hotspot/jtreg/ProblemList.txt

--- a/test/hotspot/jtreg/ProblemList.txt
+++ b/test/hotspot/jtreg/ProblemList.txt
@@ -161,10 +161,8 @@
 vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java 
8072701 generic-all
 vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java 
7034630 generic-all
 vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java 
8013728 generic-all
-vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 
8066993 generic-all
 vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 
8065773 generic-all
 vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
8065773 generic-all

Re: RFR: JDK-8066993: nsk.jdi.EventRequest.setEnabled.setenabled003 fails: event IS NOT a breakpoint

[Chris Plummer]

Hi Gary,

Looks good. What are your plans for bug management? I think the CR 
should actually be closed as CNR and removal from the problemlist be 
done as a subtask.


Also, there are a lot of other failures reported with other tests under 
this bug. Kind of became a dumping ground, but none of them resulted in 
tests being quarantined. All of the reported failures seem to be with 
8u60, and they probably still happen there. I'm not sure of the right 
procedure for closing out the bug in that case since no fix is being 
provided, so no backport can be done. Also, the affects versions 
includes 9 and 10. I think at some point Jerry reproduced something on 
10, but didn't give any details. I'm not sure how to address that either.


Chris

On 2/13/19 8:53 AM, Gary Adams wrote:

The setenabled003 test has been on the ProblemList since it was first
moved to the open repos. After 1000 test runs on {solaris, macosx, 
windows, linux}
for the test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled 
tests,

the problem does not currently reproduce.

My recommendation is that we remove it from the ProblemList at this time.


diff --git a/test/hotspot/jtreg/ProblemList.txt 
b/test/hotspot/jtreg/ProblemList.txt

--- a/test/hotspot/jtreg/ProblemList.txt
+++ b/test/hotspot/jtreg/ProblemList.txt
@@ -161,10 +161,8 @@
 vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java 
8072701 generic-all
 vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java 
7034630 generic-all
 vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java 
8013728 generic-all
-vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 
8066993 generic-all
 vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 
8065773 generic-all
 vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
8065773 generic-all

Re: RFR(T) : 8209455 : [error-prone] JdkObsolete in jdk.management.agent

[Igor Ignatyev]

Hi Alan,

actually, String::join is enough in this case, uploaded webrev.01 -- 
http://cr.openjdk.java.net/~iignatyev//8209455/webrev.01 
 

Thanks,
-- Igor

> On Feb 12, 2019, at 11:04 PM, Alan Bateman  wrote:
> 
> On 13/02/2019 00:01, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8209455/webrev.00
>>> 2 lines changed: 0 ins; 0 del; 2 mod;
>> 
>> Hi all,
>> 
>> could you please review this trivial cleanup which replaces StringBuffer by 
>> StringBuilder in jdk.management.agent module?
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev/8209455/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209455
>> 
> Looks okay but StringJoiner might be better here.
> 
> -Alan

Re: RFR JDK-8218702: [TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors

[Chris Plummer]

Ok

On 2/12/19 4:45 PM, Alex Menkov wrote:

Hi Chris,

Most of JDI tests use helper classes (VMConnection or Debuggee) which 
redirect debuggee outputs.
LaunchingConnector is used only by RepStep, SunBootClassPathEmptyTest 
and DebugUsingCustomConnector and only RepStep really performs 
debugging (SingleStepping).


--alex

On 02/11/2019 18:32, Chris Plummer wrote:
How is this test different from other JDI tests in its handling of 
stdout and stderr? Why is it a special case that needs this fix?


Chris

On 2/11/19 3:59 PM, Alex Menkov wrote:

Hi all,

please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8218702
webrev:
http://cr.openjdk.java.net/~amenkov/RepStep_redirect/webrev/

The fix adds events logging and debuggee stdout/stderr redirection 
(the test now logs crash in debuggee as described in JDK-8043571)


--alex

Re: RFR: 8218734: SA: Incorrect and raw loads of OopHandles

[Stefan Karlsson]

On 2019-02-13 17:12, coleen.phillim...@oracle.com wrote:



On 2/13/19 10:40 AM, Stefan Karlsson wrote:

On 2019-02-13 14:40, coleen.phillim...@oracle.com wrote:



On 2/11/19 3:39 AM, Stefan Karlsson wrote:

Hi all,

Please review this patch to fix the resolving of oops inside the 
(VM) OopHandles.


https://cr.openjdk.java.net/~stefank/8218734/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8218734

Before this patch the OopHandle::_obj was assumed to be located at 
offset 0, and the SA resolved OopHandle (Klass::_java_mirror and 
ClassLoaderData::_class_loader) without the required load barrier 
for ZGC. I've added a new class VMOopHandle (The SA already has a 
OopHandle), which handles the resolving (load or load + barrier).


This looks good but unfortunate that the SA has a different 
OopHandle. Maybe it would be more accurate to call it 
AccessOopHandle to imply that it has to use barriers?


Maybe. I'm not sure I like the name AccessOopHandle any better, but 
if you feel strongly about this I'll change it.

I don't feel strongly about it.




The OopHandle type is grouped under the Oops section in 
vmStructs.cpp. It's not an oop, so I added a newline to separate it 
out from the rest. Any suggestion of a better location in that file?




Seems ok to me.  The change looks fine.  Thank you for fixing this.


Thanks for reviewing. I'll change getAddressField to getField as 
suggested by Jini in another thread.




Good, I didn't see any replies and was wondering if it should be sent 
to another mailing list.


I think you dropped serviceability-dev (TO:ed).

StefanK



Coleen


Thanks,
StefanK



Thanks,
Coleen
Tested with the jtreg tests in serviceability/sa + patches to make 
ZGC usable with the SA's hprof dumping.


Thanks,
StefanK

RFR: JDK-8066993: nsk.jdi.EventRequest.setEnabled.setenabled003 fails: event IS NOT a breakpoint

[Gary Adams]

The setenabled003 test has been on the ProblemList since it was first
moved to the open repos. After 1000 test runs on {solaris, macosx, 
windows, linux}

for the test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled tests,
the problem does not currently reproduce.

My recommendation is that we remove it from the ProblemList at this time.


diff --git a/test/hotspot/jtreg/ProblemList.txt 
b/test/hotspot/jtreg/ProblemList.txt

--- a/test/hotspot/jtreg/ProblemList.txt
+++ b/test/hotspot/jtreg/ProblemList.txt
@@ -161,10 +161,8 @@
 vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java 
8072701 generic-all
 vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java 
7034630 generic-all
 vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java 
8013728 generic-all
-vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 
8066993 generic-all

 
vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java
 8065773 generic-all
 
vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java
 8065773 generic-all

RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC

[Stefan Karlsson]

Hi all,

Please review / comment on this patch to enable a best-effort live heap 
region iteration implementation in ZGC.


http://cr.openjdk.java.net/~stefank/8218922/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8218922

The SA has functionally that relies on live heap region information from 
the GCs. This is problematic when dead objects are left in the heap, and 
their classes have been unloaded.


Because of this ZGC has so far not implemented this feature. However, we 
could provide a best-effort implementation that most likely will work if 
classes are not unloaded (or class unloading is turned off), and 
otherwise might fail to fully parse and report all live heap regions.


For active, non-relocating pages the patch simply returns [start, top) 
and for pages being actively relocated, it reports regions containing 
the non-forwarded objects, the other objects are either dead or could be 
found in one of the to-regions.


With this patch I'm able to get heap histograms with ZGC.

Maybe this is enough to enable a bit more SA debugging capabilities when 
running with ZGC? What do you think, should we bring in this change?


To be able to implement this more cleanly I've restructured the live 
region collection, and pushed GC specific code into the specific GCs. 
There are some extra usage of generics to make the code a bit easier to 
read and develop.


Thanks,
StefanK

Re: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc.

[zgu]

Thanks, Per.
> > Thanks for cleaning this up. GC changes look good. Just one minor
> > thing, 
> > please align the assignment here:
> > 
> > @@ -147,8 +145,7 @@
> > 
> >   void ThreadLocalAllocBuffer::reset_statistics() {
> > _number_of_refills = 0;
> > -  _fast_refill_waste = 0;
> > -  _slow_refill_waste = 0;
> > +  _refill_waste = 0;
> > _gc_waste  = 0;
> > _slow_allocations  = 0;
> > _allocated_size= 0;
> > 
> > 
> 
> Updated: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.01/
> 
> -Zhengyu
> 
> > 
> > I agree that Serviceability should ack the jstat change.
Ping, anyone from Serviceability!

Thanks,

-Zhengyu


> > 
> > cheers,
> > Per

Re: RFR(S) 8218751 Do not store original classfiles inside the CDS archive

[Ioi Lam]

Hi Calvin

Thanks for the review.

On 2/12/19 11:29 AM, Calvin Cheung wrote:

Hi Ioi,

The following call is probably slower than before because it involves 
reading from a jar file.

cfs = FileMapInfo::open_stream_for_jvmti(ik, CHECK_NULL);
It is probably ok since the above is called under the following 
condition:

if (JvmtiExport::should_post_class_file_load_hook())

I think the slow down is probably going to be OK. If not, some users 
will tell us :-) I remember the old days when CDS will be completely 
disabled when CFLH is used, but no one was complaining at that time.




Minor comments in the following 2 files:

filemap.cpp
1494   assert(path_index >= 0, "should be called for shared built-in 
classes only");


Should the above be also checking (path_index < 
ClassLoaderExt::app_class_paths_start_index())?



I already have this check

  assert(path_index < (int)_shared_path_table_size, "sanity");

It's possible for path_index to be >= 
ClassLoaderExt::app_class_paths_start_index(). For example, if the class 
is being loaded from the app classpath (e.g., hello.jar when loading an 
archived HelloWorld class).




SpaceUtilizationCheck.java
106   throw new RuntimeException("Must have 5 consecutive, 
fully utilized regions");


5 should be 4


Fixed.

Thanks

- Ioi



thanks,
Calvin

On 2/11/19, 9:23 AM, Ioi Lam wrote:
http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/ 


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

For JVMTI ClassFileLoadHook support, the CDS archive currently stores
the original classfile data of all archived classes.

However, this consists of over 30% of the archive size. Because all
original classfile data are already available in other files (such as 
the

JDK lib/modules file, or JAR files in the classpath), we can simply read
from these locations when needed by JVMTI.

For the default CDS archive (included as part of the JDK distribution),
the size is reduced from about 18.5MB to 12.1MB on Linux/x64.

Thanks

- Ioi

Re: RFR: 8218743: SA: Add support for large bitmaps

[Stefan Karlsson]

Hi Jini,

On 2019-02-13 05:53, Jini George wrote:

Hi Stefan,

Looks good to me. Nits: pls do change the copyright year.


Thanks for reviewing. I'll update the copyright years.

Thanks,
StefanK



Thanks,
Jini.

On 2/11/2019 6:06 PM, Stefan Karlsson wrote:

Hi all,

Please review this patch to add support for large bitmaps in the SA.

http://cr.openjdk.java.net/~stefank/8218743/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8218743

I've added a minimal interface (at, atPut, clear) that uses longs 
instead of ints, and changed MarkBits to use this interface.


I've implemented a segmented bitmap that, currently, all GCs use when 
asked for a bitmap in MarkBits. Later ZGC will provide its own 
discontiguous bitmap, implementing the new interface, but that will be 
sent out as a separate RFE.


I've tested this with a temporary patch that lowers the segment size 
and implements a jtreg test:

http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01

I ran through the all the tests in serviceability/sa with both these 
patches.


Thanks,
StefanK