Re: RFR(S): JDK-8054194 jstack crash: assert(handle != NULL) failed: JNI handle should not be null

2014-08-25 Thread Staffan Larsen 
Dmitry,

Your changes look good (except missing spaces after commas). But what I do not 
understand is how this relates to the bug. The code in setImageAndSymbolPath() 
is not looking at the remote process, it’s just setting up data in the jstack 
process. How does killing the remote process affect this code? What am I 
missing?

/Staffan

On 21 aug 2014, at 14:56, Dmitry Samersoff dmitry.samers...@oracle.com wrote:

 Hi Everyone,
 
 Please review small agent changes:
 
 http://cr.openjdk.java.net/~dsamersoff/JDK-8054194/webrev.01/
 
 Under windows, If jstack attempts to attach to java process that is
 being killed by someone else, GetStaticObjectField might return NULL.
 
 -Dmitry
 
 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.

Re: RFR(S): JDK-8029172: warnings from b117 for hotspot.agent.src.os.linux: JNI exception pending

2014-08-25 Thread Staffan Larsen 
Looks good!

Thanks,
/Staffan

On 10 aug 2014, at 11:32, Dmitry Samersoff dmitry.samers...@oracle.com wrote:

 Please review:
 
 http://cr.openjdk.java.net/~dsamersoff/JDK-8029172/webrev.01/
 
 Added more exception checks to agent/src/os/linux/LinuxDebuggerLocal.c
 
 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.

Re: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again

2014-08-25 Thread Staffan Larsen 
Dmitry,

One problem with this fix is that debugInit_exit() is used from many places in 
the JDWP code. For some of these I think it still does make sense to receive a 
core dump for analysis. I agree that when parsing options, we do not need a 
core dump.

/Staffan


On 20 aug 2014, at 17:55, Dmitry Samersoff dmitry.samers...@oracle.com wrote:

 Serguei,
 
 After some additional testing I changed the fix a bit. Please take a
 look at new version.
 
 http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/
 
 New version reports JVMTI error to stderr.
 
 Also jniFatalError is not referenced any more so I remove it.
 
 -Dmitry
 
 
 
 On 2014-08-20 12:08, serguei.spit...@oracle.com wrote:
 Ok.
 
 Thank you for the explanation!
 Serguei
 
 On 8/20/14 1:01 AM, Dmitry Samersoff wrote:
 Serguei,
 
 1. Historically JDI test-suite had no tests for failed transport
 initialization behavior and invalid parameters handling.
 
 2. As a part of JDWP hardening work I added couple of such tests to
 OptionTest.java - these tests pass invalid parameters to dt_socket
 transport to make sure that transport doesn't crash (one such crash was
 discovered and fixed) but just return non-zero exit code to upper level.
 
 3. After fix for JDK-6694099 any non-zero exit code from transport cause
 VM to coredump. Dumping multiple cores on busy machine takes a time so
 harness kills the test by timeout.
 
 We can just increase timeout for this test but I don't think it's a good
 idea to dump core when invalid parameters passed to transport.
 
 So there is the fix.
 
 4. After the fix tests for negative parameters will return non-zero exit
 code as expected but will not dump the core.
 
 -Dmitry
 
 On 2014-08-20 00:54, serguei.spit...@oracle.com wrote:
 Hi Dmitry,
 
 The fix seems to be Ok.
 Just want to make it clear...
 This fix just changes the bug pattern.
 It a case of incorrect transport parameters the test is still going to
 fail but without crash, right?
 
 Thanks,
 Serguei
 
 On 8/19/14 12:09 PM, Dmitry Samersoff wrote:
 Hi Everybody,
 
 Please review the fix:
 
 http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/
 
 JDWP call jniFatalError if transport can't be initialized (e.g. wrong
 parameters) and jniFatalError call os::abort().  Therefor all transport
 initialization errors cause vm to coredump.
 
 I see no reason for debugInit_exit to call jniFatalError so remove this
 code.
 
 -Dmitry
 
 
 
 
 
 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.

Re: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again

2014-08-25 Thread serguei.spit...@oracle.com 

This is a valid concern.
Sorry, I did not catch it.

Thanks,
Serguei

On 8/25/14 4:26 AM, Staffan Larsen wrote:

Dmitry,

One problem with this fix is that debugInit_exit() is used from many places in 
the JDWP code. For some of these I think it still does make sense to receive a 
core dump for analysis. I agree that when parsing options, we do not need a 
core dump.

/Staffan


On 20 aug 2014, at 17:55, Dmitry Samersoff dmitry.samers...@oracle.com wrote:


Serguei,

After some additional testing I changed the fix a bit. Please take a
look at new version.

http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/

New version reports JVMTI error to stderr.

Also jniFatalError is not referenced any more so I remove it.

-Dmitry



On 2014-08-20 12:08, serguei.spit...@oracle.com wrote:

Ok.

Thank you for the explanation!
Serguei

On 8/20/14 1:01 AM, Dmitry Samersoff wrote:

Serguei,

1. Historically JDI test-suite had no tests for failed transport
initialization behavior and invalid parameters handling.

2. As a part of JDWP hardening work I added couple of such tests to
OptionTest.java - these tests pass invalid parameters to dt_socket
transport to make sure that transport doesn't crash (one such crash was
discovered and fixed) but just return non-zero exit code to upper level.

3. After fix for JDK-6694099 any non-zero exit code from transport cause
VM to coredump. Dumping multiple cores on busy machine takes a time so
harness kills the test by timeout.

We can just increase timeout for this test but I don't think it's a good
idea to dump core when invalid parameters passed to transport.

So there is the fix.

4. After the fix tests for negative parameters will return non-zero exit
code as expected but will not dump the core.

-Dmitry

On 2014-08-20 00:54, serguei.spit...@oracle.com wrote:

Hi Dmitry,

The fix seems to be Ok.
Just want to make it clear...
This fix just changes the bug pattern.
It a case of incorrect transport parameters the test is still going to
fail but without crash, right?

Thanks,
Serguei

On 8/19/14 12:09 PM, Dmitry Samersoff wrote:

Hi Everybody,

Please review the fix:

http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/

JDWP call jniFatalError if transport can't be initialized (e.g. wrong
parameters) and jniFatalError call os::abort().  Therefor all transport
initialization errors cause vm to coredump.

I see no reason for debugInit_exit to call jniFatalError so remove this
code.

-Dmitry



--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

Re: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again

2014-08-25 Thread Staffan Larsen 

On 25 aug 2014, at 13:33, Dmitry Samersoff dmitry.samers...@oracle.com wrote:

 Staffan,
 
 On 2014-08-25 15:26, Staffan Larsen wrote:
 Dmitry,
 
 One problem with this fix is that debugInit_exit() is used from many
 places in the JDWP code. For some of these I think it still does make
 sense to receive a core dump for analysis. I agree that when parsing
 options, we do not need a core dump.
 
 jdwp has explicit option to request a coredump at debugInit_exit().
 
 Is it enough or I should create a more sophisticated fix ?

I don’t think that is enough. Often a problem will happen and will not be 
reproducible. 

Maybe this code:

if ((arg.error != JDWP_ERROR(NONE)) 
(arg.startCount == 0) 
initOnStartup) {
EXIT_ERROR(map2jvmtiError(arg.error), No transports initialized);
}

can use some variant of EXIT_ERROR that does not call fatalError() ?

/Staffan

 
 Actually, I don't think that coredump on every call to jni_FatalError()
 (see jni.cpp:726) is necessary but this hotspot code is here for 6 years
 and changing it probably out of scope of this fix.
 
 -Dmitry
 
 
 
 /Staffan
 
 
 On 20 aug 2014, at 17:55, Dmitry Samersoff
 dmitry.samers...@oracle.com wrote:
 
 Serguei,
 
 After some additional testing I changed the fix a bit. Please take
 a look at new version.
 
 http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/
 
 New version reports JVMTI error to stderr.
 
 Also jniFatalError is not referenced any more so I remove it.
 
 -Dmitry
 
 
 
 On 2014-08-20 12:08, serguei.spit...@oracle.com wrote:
 Ok.
 
 Thank you for the explanation! Serguei
 
 On 8/20/14 1:01 AM, Dmitry Samersoff wrote:
 Serguei,
 
 1. Historically JDI test-suite had no tests for failed
 transport initialization behavior and invalid parameters
 handling.
 
 2. As a part of JDWP hardening work I added couple of such
 tests to OptionTest.java - these tests pass invalid parameters
 to dt_socket transport to make sure that transport doesn't
 crash (one such crash was discovered and fixed) but just return
 non-zero exit code to upper level.
 
 3. After fix for JDK-6694099 any non-zero exit code from
 transport cause VM to coredump. Dumping multiple cores on busy
 machine takes a time so harness kills the test by timeout.
 
 We can just increase timeout for this test but I don't think
 it's a good idea to dump core when invalid parameters passed to
 transport.
 
 So there is the fix.
 
 4. After the fix tests for negative parameters will return
 non-zero exit code as expected but will not dump the core.
 
 -Dmitry
 
 On 2014-08-20 00:54, serguei.spit...@oracle.com wrote:
 Hi Dmitry,
 
 The fix seems to be Ok. Just want to make it clear... This
 fix just changes the bug pattern. It a case of incorrect
 transport parameters the test is still going to fail but
 without crash, right?
 
 Thanks, Serguei
 
 On 8/19/14 12:09 PM, Dmitry Samersoff wrote:
 Hi Everybody,
 
 Please review the fix:
 
 http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/
 
 
 
 JDWP call jniFatalError if transport can't be initialized (e.g. wrong
 parameters) and jniFatalError call os::abort().  Therefor
 all transport initialization errors cause vm to coredump.
 
 I see no reason for debugInit_exit to call jniFatalError so
 remove this code.
 
 -Dmitry
 
 
 
 
 
 -- Dmitry Samersoff Oracle Java development team, Saint Petersburg,
 Russia * I would love to change the world, but they won't give me
 the sources.
 
 
 
 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.

Re: RFR(S): URG! JDK-8049226 com/sun/jdi/OptionTest.java test times out again

2014-08-25 Thread Dmitry Samersoff 
Staffan,

OK. Will create better fix.

-Dmitry

On 2014-08-25 15:53, Staffan Larsen wrote:
 
 On 25 aug 2014, at 13:33, Dmitry Samersoff dmitry.samers...@oracle.com
 mailto:dmitry.samers...@oracle.com wrote:
 
 Staffan,

 On 2014-08-25 15:26, Staffan Larsen wrote:
 Dmitry,

 One problem with this fix is that debugInit_exit() is used from many
 places in the JDWP code. For some of these I think it still does make
 sense to receive a core dump for analysis. I agree that when parsing
 options, we do not need a core dump.

 jdwp has explicit option to request a coredump at debugInit_exit().

 Is it enough or I should create a more sophisticated fix ?
 
 I don’t think that is enough. Often a problem will happen and will not
 be reproducible. 
 
 Maybe this code:
 
 if ((arg.error != JDWP_ERROR(NONE)) 
 (arg.startCount == 0) 
 initOnStartup) {
 EXIT_ERROR(map2jvmtiError(arg.error), No transports initialized);
 }
 
 can use some variant of EXIT_ERROR that does not call fatalError() ?
 
 /Staffan
 

 Actually, I don't think that coredump on every call to jni_FatalError()
 (see jni.cpp:726) is necessary but this hotspot code is here for 6 years
 and changing it probably out of scope of this fix.

 -Dmitry



 /Staffan


 On 20 aug 2014, at 17:55, Dmitry Samersoff
 dmitry.samers...@oracle.com mailto:dmitry.samers...@oracle.com wrote:

 Serguei,

 After some additional testing I changed the fix a bit. Please take
 a look at new version.

 http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/

 New version reports JVMTI error to stderr.

 Also jniFatalError is not referenced any more so I remove it.

 -Dmitry



 On 2014-08-20 12:08, serguei.spit...@oracle.com wrote:
 Ok.

 Thank you for the explanation! Serguei

 On 8/20/14 1:01 AM, Dmitry Samersoff wrote:
 Serguei,

 1. Historically JDI test-suite had no tests for failed
 transport initialization behavior and invalid parameters
 handling.

 2. As a part of JDWP hardening work I added couple of such
 tests to OptionTest.java - these tests pass invalid parameters
 to dt_socket transport to make sure that transport doesn't
 crash (one such crash was discovered and fixed) but just return
 non-zero exit code to upper level.

 3. After fix for JDK-6694099 any non-zero exit code from
 transport cause VM to coredump. Dumping multiple cores on busy
 machine takes a time so harness kills the test by timeout.

 We can just increase timeout for this test but I don't think
 it's a good idea to dump core when invalid parameters passed to
 transport.

 So there is the fix.

 4. After the fix tests for negative parameters will return
 non-zero exit code as expected but will not dump the core.

 -Dmitry

 On 2014-08-20 00:54, serguei.spit...@oracle.com wrote:
 Hi Dmitry,

 The fix seems to be Ok. Just want to make it clear... This
 fix just changes the bug pattern. It a case of incorrect
 transport parameters the test is still going to fail but
 without crash, right?

 Thanks, Serguei

 On 8/19/14 12:09 PM, Dmitry Samersoff wrote:
 Hi Everybody,

 Please review the fix:

 http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/



 JDWP call jniFatalError if transport can't be initialized (e.g. wrong
 parameters) and jniFatalError call os::abort().  Therefor
 all transport initialization errors cause vm to coredump.

 I see no reason for debugInit_exit to call jniFatalError so
 remove this code.

 -Dmitry





 -- Dmitry Samersoff Oracle Java development team, Saint Petersburg,
 Russia * I would love to change the world, but they won't give me
 the sources.



 -- 
 Dmitry Samersoff
 Oracle Java development team, Saint Petersburg, Russia
 * I would love to change the world, but they won't give me the sources.
 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK

2014-08-25 Thread Staffan Larsen 
Please review the following change to remove hprof as part of the demo package. 
Instead, the source code has been moved to the jdk.hprof.agent module.

bug: https://bugs.openjdk.java.net/browse/JDK-8043936
webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/

Thanks,
/Staffan

RFR: JDK-8043981 Remove the JPDA demo

2014-08-25 Thread Staffan Larsen 
Please review this change to remove the legacy JPDA demos. These demos are 
quite dated at this point and the included instructions are incomplete. In 
addition the example/demo JPDA code does not fit well into the new modular 
structure because the source code is used for both jdb and for the demo.

bug: https://bugs.openjdk.java.net/browse/JDK-8043981
webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/

Thanks,
/Staffan

Re: RFR: JDK-8043981 Remove the JPDA demo

2014-08-25 Thread Alan Bateman 

On 25/08/2014 14:48, Staffan Larsen wrote:

Please review this change to remove the legacy JPDA demos. These demos are 
quite dated at this point and the included instructions are incomplete. In 
addition the example/demo JPDA code does not fit well into the new modular 
structure because the source code is used for both jdb and for the demo.

bug: https://bugs.openjdk.java.net/browse/JDK-8043981
webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/

Good to see this going away, it also addresses one of Magnus' recent 
comments here about jpda/src.zip being built from sources in two 
locations (a consequence of the code being used for two things).


The changes looks okay to me. A passing comment is that the move of 
Expr.jj is a reminder that we have generated code checked-in but that 
has been the case for a long time.


-Alan.

Re: RFR: JDK-8043981 Remove the JPDA demo

2014-08-25 Thread Staffan Larsen 

On 25 aug 2014, at 15:59, Alan Bateman alan.bate...@oracle.com wrote:

 On 25/08/2014 14:48, Staffan Larsen wrote:
 Please review this change to remove the legacy JPDA demos. These demos are 
 quite dated at this point and the included instructions are incomplete. In 
 addition the example/demo JPDA code does not fit well into the new modular 
 structure because the source code is used for both jdb and for the demo.
 
 bug: https://bugs.openjdk.java.net/browse/JDK-8043981
 webrev: http://cr.openjdk.java.net/~sla/8043981/webrev.00/
 
 Good to see this going away, it also addresses one of Magnus' recent comments 
 here about jpda/src.zip being built from sources in two locations (a 
 consequence of the code being used for two things).
 
 The changes looks okay to me. A passing comment is that the move of Expr.jj 
 is a reminder that we have generated code checked-in but that has been the 
 case for a long time.

Thanks Alan.

Yes, Ideally we should run JavaCC during the build on Expr.jj, but that adds a 
dependency and execution time for something that is very rarely changed.

/Staffan

 
 -Alan.

Re: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK

2014-08-25 Thread Erik Joelsson 

Build changes look ok to me.

/Erik

On 2014-08-25 15:35, Staffan Larsen wrote:

Please review the following change to remove hprof as part of the demo package. 
Instead, the source code has been moved to the jdk.hprof.agent module.

bug: https://bugs.openjdk.java.net/browse/JDK-8043936
webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/

Thanks,
/Staffan

Re: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK

2014-08-25 Thread Staffan Larsen 

On 25 aug 2014, at 16:15, Alan Bateman alan.bate...@oracle.com wrote:

 On 25/08/2014 14:35, Staffan Larsen wrote:
 Please review the following change to remove hprof as part of the demo 
 package. Instead, the source code has been moved to the jdk.hprof.agent 
 module.
 
 bug: https://bugs.openjdk.java.net/browse/JDK-8043936
 webrev: http://cr.openjdk.java.net/~sla/8043936/webrev.00/
 
 The move of the source code to native/libhprof looks good.
 
 Having the README and manual in the same directory is probably okay as it has 
 always lived in the same directory as the source code. One thing is check is 
 the contents of manual.html as there is at least one place where it 
 references the directory demo/jvmti/hprof.

Good point. I have removed the section about Source Code in the latest version 
since all OpenJDK source code can be found at the same place:

http://cr.openjdk.java.net/~sla/8043936/webrev.01/

I plan to push this version tomorrow unless someone shouts ;)

Thanks,
/Staffan

 
 I assume Erik or Magnus will check the make changes, I don't see any issues.
 
 -Alan

Re: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK

2014-08-25 Thread Alan Bateman 

On 25/08/2014 15:38, Staffan Larsen wrote:

On 25 aug 2014, at 16:15, Alan Bateman alan.bate...@oracle.com wrote:


:

Having the README and manual in the same directory is probably okay as it has 
always lived in the same directory as the source code. One thing is check is 
the contents of manual.html as there is at least one place where it references 
the directory demo/jvmti/hprof.

Good point. I have removed the section about Source Code in the latest version 
since all OpenJDK source code can be found at the same place:

http://cr.openjdk.java.net/~sla/8043936/webrev.01/



The update to the manual looks good.

-Alan

RFR: JDK-8055845 - Add trace event for promoted objects

2014-08-25 Thread Staffan Friberg 

Hi,

Could I please get reviews for this RFE that adds a trace event for 
aging and promotion for young collections in G1, CMS and Parallel GC.
It works similarly to allocation events, and generates the event on the 
slow path when either a direct copy occurs or a new PLAB is request.


Since I'm adding an event I cc:ed the serviceability list in case anyone 
has any comments on the event and changes to trace.xml.


RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00

Bengt has been kind and agreed to both sponsor and host the the webrev.

Thanks,
Staffan

Re: RFR: JDK-8055845 - Add trace event for promoted objects

2014-08-25 Thread Erik Gahlin 
Did you manage to call the field class? It's a reserved word in C++, 
so we had to use klass in the past


Descriptions with only one sentence shouldn't end with .

How is Object Age measured?

As a user, I would expect the number to be in seconds/minutes/hours, but 
that is not the case. Perhaps an explanation in the description and/or a 
field name that better reflects what we really mean with age.


Otherwise trace.xml looks good!

Erik

Staffan Friberg skrev 25/08/14 18:28:

Hi,

Could I please get reviews for this RFE that adds a trace event for 
aging and promotion for young collections in G1, CMS and Parallel GC.
It works similarly to allocation events, and generates the event on 
the slow path when either a direct copy occurs or a new PLAB is request.


Since I'm adding an event I cc:ed the serviceability list in case 
anyone has any comments on the event and changes to trace.xml.


RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00

Bengt has been kind and agreed to both sponsor and host the the webrev.

Thanks,
Staffan

RFR 8037082: java/lang/instrument/NativeMethodPrefixAgent.java failing

2014-08-25 Thread Jaroslav Bachorik 

Please, review the following test fix.

Issue : https://bugs.openjdk.java.net/browse/JDK-8037082
Webrev: http://cr.openjdk.java.net/~jbachorik/8037082/webrev.00

As Staffan mentions in the issue comments - The two tests 
NativeMethodPrefixAgent and RetransformAgent use their own byte code 
instrumentation library in jdk/test/java/lang/instrument/ilib/. These 
tests need to be rewritten to use ASM instead so that we don't have to 
maintain the ilib library.


This patch is intended to remove the ilib library and replace the 
usages with an ASM5 alternative. Only the currently used features of the 
ilib library are being ported.


Thanks,

-JB-

Re: RFR: JDK-8055845 - Add trace event for promoted objects

2014-08-25 Thread Staffan Friberg 

Hi Erik,

No issue with naming the field class, since the event is similar to the 
Allocation event I used that as a starting point and it also uses class 
as name together with a couple of other events.


Will go through the descriptions and remove periods.

Object age is basically the how many times an object has been kept in 
survivor region, it is incremented each time a YC happens and the object 
is aged.
Will see how I can update the description to make it clearer. Calling 
the field tenuringAge might help?


From the documentation, 
http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html


-XX:MaxTenuringThreshold=/threshold/

Sets the maximum tenuring threshold for use in adaptive GC sizing.
The largest value is 15. The default value is 15 for the parallel
(throughput) collector, and 6 for the CMS collector.

The following example shows how to set the maximum tenuring
threshold to 10:

-XX:MaxTenuringThreshold=10


-XX:+PrintTenuringDistribution

Enables printing of tenuring age information. The following is an
example of the output:

Desired survivor size 48286924 bytes, new threshold 10 (max 10)
- age 1: 28992024 bytes, 28992024 total
- age 2: 1366864 bytes, 3035 total
- age 3: 1425912 bytes, 31784800 total
...

Age 1 objects are the youngest survivors (they were created after
the previous scavenge, survived the latest scavenge, and moved
from eden to survivor space). Age 2 objects have survived two
scavenges (during the second scavenge they were copied from one
survivor space to the next). And so on.

In the preceding example, 28 992 024 bytes survived one scavenge
and were copied from eden to survivor space, 1 366 864 bytes are
occupied by age 2 objects, etc. The third value in each row is the
cumulative size of objects of age n or less.

By default, this option is disabled.



Thanks for the comments,
Staffan

On 08/25/2014 09:55 AM, Erik Gahlin wrote:
Did you manage to call the field class? It's a reserved word in C++, 
so we had to use klass in the past


Descriptions with only one sentence shouldn't end with .

How is Object Age measured?

As a user, I would expect the number to be in seconds/minutes/hours, 
but that is not the case. Perhaps an explanation in the description 
and/or a field name that better reflects what we really mean with age.


Otherwise trace.xml looks good!

Erik

Staffan Friberg skrev 25/08/14 18:28:

Hi,

Could I please get reviews for this RFE that adds a trace event for 
aging and promotion for young collections in G1, CMS and Parallel GC.
It works similarly to allocation events, and generates the event on 
the slow path when either a direct copy occurs or a new PLAB is request.


Since I'm adding an event I cc:ed the serviceability list in case 
anyone has any comments on the event and changes to trace.xml.


RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00

Bengt has been kind and agreed to both sponsor and host the the webrev.

Thanks,
Staffan

Re: RFR 8037082: java/lang/instrument/NativeMethodPrefixAgent.java failing

2014-08-25 Thread Staffan Larsen 
Thanks for taking on this one!

The code looks good. Just two small things below.

Have you tested with -Xverify:all, just to see if there are any byte code 
problems?


Could fix the auto-naming of the params in this code?
 131 @Override
 132 public void visit(int i, int i1, String className, String 
string1, String string2, String[] strings) {
 133 this.className = className;
 134 super.visit(i, i1, className, string1, string2, strings);
 135 }

nit: let’s ClassWriter to deal - let ClassWriter deal
163 mv.visitMaxs(1, 1); // dummy call; let's 
ClassWriter to deal with this
 

Thanks,
/Staffan


On 25 aug 2014, at 19:16, Jaroslav Bachorik jaroslav.bacho...@oracle.com 
wrote:

 Please, review the following test fix.
 
 Issue : https://bugs.openjdk.java.net/browse/JDK-8037082
 Webrev: http://cr.openjdk.java.net/~jbachorik/8037082/webrev.00
 
 As Staffan mentions in the issue comments - The two tests 
 NativeMethodPrefixAgent and RetransformAgent use their own byte code 
 instrumentation library in jdk/test/java/lang/instrument/ilib/. These tests 
 need to be rewritten to use ASM instead so that we don't have to maintain the 
 ilib library.
 
 This patch is intended to remove the ilib library and replace the usages 
 with an ASM5 alternative. Only the currently used features of the ilib 
 library are being ported.
 
 Thanks,
 
 -JB-

Re: RFR 8040692: [TESTBUG] sun/management/jmxremote/bootstrap/JvmstatCountersTest.java requires -XX:+UsePerfData option to pass on embedded platforms

2014-08-25 Thread David Holmes 

On 21/08/2014 10:44 PM, Jaroslav Bachorik wrote:

Please, review this simple fix.

Issue : https://bugs.openjdk.java.net/browse/JDK-8040692
Webrev: http://cr.openjdk.java.net/~jbachorik/8040692/webrev.00

On embedded platforms it is necessary to provide -XX:+UsePerfData flag
in order to make the performance counters accessible. This fix does this
for the tests which need to access the performance counters.


Looks fine to me - except for the sources.list file ?? :)

Thanks,
David


Thanks,

-JB-

Review request: 8055230: Rename attach provider implementation class

2014-08-25 Thread Mandy Chung 

Webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/

This patch renames the class name of attach provider implementation class
to be the same for all platforms.  This simplifies the build logic and
removes the need for generating the service config file at build time.

The files renamed are
   unix/classes/sun/tools/attach/${OS}VirtualMachine.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
   unix/classes/sun/tools/attach/${OS}AttachProvider.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java

   ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
   ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java

and also corresponding native files.

Mandy

Re: Review request: 8055230: Rename attach provider implementation class

2014-08-25 Thread David Holmes 

I like this change! :)

Looks good to me.

Thanks Mandy!

David
-

On 26/08/2014 2:29 PM, Mandy Chung wrote:

Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/

This patch renames the class name of attach provider implementation class
to be the same for all platforms.  This simplifies the build logic and
removes the need for generating the service config file at build time.

The files renamed are
unix/classes/sun/tools/attach/${OS}VirtualMachine.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
unix/classes/sun/tools/attach/${OS}AttachProvider.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java

${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
  - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java

and also corresponding native files.

Mandy

Re: Review request: 8055230: Rename attach provider implementation class

2014-08-25 Thread Staffan Larsen 
Ahh. The simplicity!

Looks good!

Thanks,
/Staffan

On 26 aug 2014, at 06:29, Mandy Chung mandy.ch...@oracle.com wrote:

 Webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
 
 This patch renames the class name of attach provider implementation class
 to be the same for all platforms.  This simplifies the build logic and
 removes the need for generating the service config file at build time.
 
 The files renamed are
   unix/classes/sun/tools/attach/${OS}VirtualMachine.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
   unix/classes/sun/tools/attach/${OS}AttachProvider.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
 
   ${OS}/classes/sun/tools/attach/${OS}VirtualMachine.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
   ${OS}/classes/sun/tools/attach/${OS}AttachProvider.java
 - ${OS}/classes/sun/tools/attach/VirtualMachineImpl.java
 
 and also corresponding native files.
 
 Mandy