Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

2018-12-31 Thread Chris Plummer
Ok. Chris On 12/31/18 12:30 PM, gary.ad...@oracle.com wrote: The one test that failed is changed in this webrev. When it failed, it was the check in add_option that does not allow an "empty" option name. On 12/31/18 2:25 PM, Chris Plummer wrote: Looks good. Are empty options strings still

Re: [RFR]8215623: Add incremental dump for jmap histo

2018-12-31 Thread Hohensee, Paul
As for 8215622, update the copyright dates to 2019 please, since this won’t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. “incremental” could become

Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

2018-12-31 Thread gary.ad...@oracle.com
The one test that failed is changed in this webrev. When it failed, it was the check in add_option that does not allow an "empty" option name. On 12/31/18 2:25 PM, Chris Plummer wrote: Looks good. Are empty options strings still allowed after your changes? Chris On 12/31/18 10:06 AM,

Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

2018-12-31 Thread Chris Plummer
Looks good. Are empty options strings still allowed after your changes? Chris On 12/31/18 10:06 AM, gary.ad...@oracle.com wrote: Here's a revised webrev.   Webrev: http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8211343/webrev.01/ Updates in this round of changes :   -

Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

2018-12-31 Thread gary.ad...@oracle.com
Here's a revised webrev.   Webrev: http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8211343/webrev.01/ Updates in this round of changes :   - replaced index() with strchr() to avoid platform dependent issues with strings.h include   - removed NSK_JVMTI_OPTION_VAL_SEP   -

Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

2018-12-31 Thread gary.ad...@oracle.com
Here are few more DYLD_LIBRARY_PATH locations that would be worth checking ./jdk/vm/JniInvocationTest.java:50: env.compute("DYLD_LIBRARY_PATH", (k, v) -> (k == null) ? libdir : v + ":" + libdir); ./jdk/tools/launcher/ExecutionEnvironment.java:66:    ? "DYLD_LIBRARY_PATH"

RE: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

2018-12-31 Thread Lindenmaier, Goetz
Hi Gary, > Would it make sense to add a method to test/lib/jdk/test/lib/Platform.java > similar to sharedLibraryExt() to cover the envName setting? Good point. I'll post a follow up change next year ... and believe me, that's not too far in the future  I'd like to keep this out of this test

Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

2018-12-31 Thread gary.ad...@oracle.com
Would it make sense to add a method to test/lib/jdk/test/lib/Platform.java similar to sharedLibraryExt() to cover the envName setting? Are the other places DYLD_LIBRARY_PATH is set also need to be updated for AIX? On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: Hi, Some of the nsk tests are

RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

2018-12-31 Thread Lindenmaier, Goetz
Hi, Some of the nsk tests are not properly configured for the above platforms: nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.java The tests use the path to native libraries, which is named "LIBPATH" on AIX.