From dmitry.samersoff at oracle.com Sat Nov 1 10:13:44 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 01 Nov 2014 13:13:44 +0300 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5453F9F4.20309@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> Message-ID: <5454B258.1080104@oracle.com> Serguei, Thank you for good finding. This approach looks much better for me. The fix looks good. Is it necessary to release vmDeathLock locks at eventHandler.c:1244 before call EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? -Dmitry On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: > > It is 3-rd round of review for: > https://bugs.openjdk.java.net/browse/JDK-6988950 > > New webrev: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ > > > Summary > > For failing scenario, please, refer to the 1-st round RFR below. > > I've found what is missed in the jdwp agent shutdown and decided to > switch from a workaround to a real fix. > > The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. > The agent debugLoop_run() has a guard against the VM shutdown: > > 165 } else if (gdata->vmDead && > 166 ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { > 167 /* Protect the VM from calls while dead. > 168 * VirtualMachine cmdSet quietly ignores some cmds > 169 * after VM death, so, it sends it's own errors. > 170 */ > 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); > > > However, the guard above does not help much if the VM_DEATH event > happens in the middle of a command execution. > There is a lack of synchronization here. > > The fix introduces new lock (vmDeathLock) which does not allow to > execute the commands > and the VM_DEATH event callback concurrently. > It should work well for any function that is used in implementation of > the JDWP_COMMAND_SET(VirtualMachine) . > > > Testing: > Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests > > > Thanks, > Serguei > > > On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >> >> >> The changes are: >> - added a comment recommended by Staffan >> - removed the ignore_wrong_phase() call from function classSignature() >> >> The classSignature() function is called in 16 places. >> Most of them do not tolerate the NULL in place of returned signature >> and will crash. >> I'm not comfortable to fix all the occurrences now and suggest to >> return to this >> issue after gaining experience with more failure cases that are still >> expected. >> The failure with the classSignature() involved was observed only once >> in the nightly >> and should be extremely rare reproducible. >> I'll file a placeholder bug if necessary. >> >> Thanks, >> Serguei >> >> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>> >>> >>> >>> Summary: >>> >>> The failing scenario: >>> The debugger and the debuggee are well aware a VM shutdown has >>> been started in the target process. >>> The debugger at this point is not expected to send any commands >>> to the JDWP agent. >>> However, the JDI layer (debugger side) and the jdwp agent >>> (debuggee side) >>> are not in sync with the consumer layers. >>> >>> One reason is because the test debugger does not invoke the JDI >>> method VirtualMachine.dispose(). >>> Another reason is that the Debugger and the debuggee processes >>> are uneasy to sync in general. >>> >>> As a result the following steps are possible: >>> - The test debugger sends a 'quit' command to the test debuggee >>> - The debuggee is normally exiting >>> - The jdwp backend reports (over the jdwp protocol) an >>> anonymous class unload event >>> - The JDI InternalEventHandler thread handles the >>> ClassUnloadEvent event >>> - The InternalEventHandler wants to uncache the matching >>> reference type. >>> If there is more than one class with the same host class >>> signature, it can't distinguish them, >>> and so, deletes all references and re-retrieves them again >>> (see tracing below): >>> MY_TRACE: JDI: >>> VirtualMachineImpl.retrieveClassesBySignature: >>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>> - The jdwp backend debugLoop_run() gets the command from JDI >>> and calls the functions >>> classesForSignature() and classStatus() recursively. >>> - The classStatus() makes a call to the JVMTI GetClassStatus() >>> and gets the JVMTI_ERROR_WRONG_PHASE >>> - As a result the jdwp backend reports the JVMTI error to the >>> JDI, and so, the test fails >>> >>> For details, see the analysis in bug report closed as a dup of >>> the bug 6988950: >>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>> >>> Some similar cases can be found in the two bug reports (6988950 >>> and 8024865) describing this issue. >>> >>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>> as it is normal at the VM shutdown. >>> The original jdwp backend implementation had a similar approach >>> for the raw monitor functions. >>> Threy use the ignore_vm_death() to workaround the >>> JVMTI_ERROR_WRONG_PHASE errors. >>> For reference, please, see the file: src/share/back/util.c >>> >>> >>> Testing: >>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Mon Nov 3 02:29:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Nov 2014 12:29:29 +1000 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: <5453AC95.3060904@oracle.com> Message-ID: <5456E889.8080100@oracle.com> Again adding in serviceability. David On 1/11/2014 6:17 AM, Jeremy Manson wrote: > Thanks, Coleen - I saw that you committed it, but the change had a long > contributed-by line, so I wasn't sure whether you were the right person to > reach out to. > > Jeremy > > On Fri, Oct 31, 2014 at 8:36 AM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> Jeremy, >> I will review and sponsor this for you since I wrote the original code. >> Thanks, >> Coleen >> >> >> On 10/30/14, 1:02 PM, Jeremy Manson wrote: >> >>> There's a significant regression in the speed of JVMTI GetClassMethods in >>> JDK8. I've tracked this down to allocation of jmethodids in a tight loop. >>> The issue can be addressed by preallocating enough space for all of the >>> jmethodids when starting the operation and not iterating over all of the >>> existing jmethodids when you allocate a new one. >>> >>> A patch is here: >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >>> >>> A reproducible test case can be found here: >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >>> >>> It's a benchmark, though: I have no idea how to turn it into a test. >>> >>> For whoever reviews it: can you explain to me why it is okay that this >>> code >>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a lot of >>> problems stemming from accidental reuse. >>> >>> Jeremy >>> >> >> From david.holmes at oracle.com Mon Nov 3 02:30:37 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Nov 2014 12:30:37 +1000 Subject: RFR 8062647: Wrong indentation of arguments of annotated methods In-Reply-To: <54539F0F.6030704@oracle.com> References: <54539F0F.6030704@oracle.com> Message-ID: <5456E8CD.1000107@oracle.com> Ivan, javadoc tool changes need to be reviewed by the javadoc folk not serviceability. David On 1/11/2014 12:39 AM, Ivan Gerasimov wrote: > Hello everybody! > > I noticed that the javadoc tool may produce the doc with misaligned > arguments of annotated methods in the 'method details' section. > For example: > http://jre.us.oracle.com/java/re/jdk/9/nightly/latest/docs/api/java/util/EnumSet.html#of-E-E...- > > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8062647 > WEBREV: http://cr.openjdk.java.net/~igerasim/8062647/0/webrev/ > > Sincerely yours, > Ivan From david.holmes at oracle.com Mon Nov 3 04:58:16 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Nov 2014 14:58:16 +1000 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5454B258.1080104@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> Message-ID: <54570B68.3060806@oracle.com> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: > Serguei, > > Thank you for good finding. This approach looks much better for me. > > The fix looks good. > > Is it necessary to release vmDeathLock locks at > eventHandler.c:1244 before call > > EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? I agree this looks necessary, or at least more clean (if things are failing we really don't know what is happening). More generally I'm concerned about whether any of the code paths taken while holding the new lock can result in deadlock - in particular with regard to the resumeLock ? David > -Dmitry > > > > On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >> >> It is 3-rd round of review for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> New webrev: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >> >> >> Summary >> >> For failing scenario, please, refer to the 1-st round RFR below. >> >> I've found what is missed in the jdwp agent shutdown and decided to >> switch from a workaround to a real fix. >> >> The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. >> The agent debugLoop_run() has a guard against the VM shutdown: >> >> 165 } else if (gdata->vmDead && >> 166 ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { >> 167 /* Protect the VM from calls while dead. >> 168 * VirtualMachine cmdSet quietly ignores some cmds >> 169 * after VM death, so, it sends it's own errors. >> 170 */ >> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >> >> >> However, the guard above does not help much if the VM_DEATH event >> happens in the middle of a command execution. >> There is a lack of synchronization here. >> >> The fix introduces new lock (vmDeathLock) which does not allow to >> execute the commands >> and the VM_DEATH event callback concurrently. >> It should work well for any function that is used in implementation of >> the JDWP_COMMAND_SET(VirtualMachine) . >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> >> >> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>> >>> >>> The changes are: >>> - added a comment recommended by Staffan >>> - removed the ignore_wrong_phase() call from function classSignature() >>> >>> The classSignature() function is called in 16 places. >>> Most of them do not tolerate the NULL in place of returned signature >>> and will crash. >>> I'm not comfortable to fix all the occurrences now and suggest to >>> return to this >>> issue after gaining experience with more failure cases that are still >>> expected. >>> The failure with the classSignature() involved was observed only once >>> in the nightly >>> and should be extremely rare reproducible. >>> I'll file a placeholder bug if necessary. >>> >>> Thanks, >>> Serguei >>> >>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> The failing scenario: >>>> The debugger and the debuggee are well aware a VM shutdown has >>>> been started in the target process. >>>> The debugger at this point is not expected to send any commands >>>> to the JDWP agent. >>>> However, the JDI layer (debugger side) and the jdwp agent >>>> (debuggee side) >>>> are not in sync with the consumer layers. >>>> >>>> One reason is because the test debugger does not invoke the JDI >>>> method VirtualMachine.dispose(). >>>> Another reason is that the Debugger and the debuggee processes >>>> are uneasy to sync in general. >>>> >>>> As a result the following steps are possible: >>>> - The test debugger sends a 'quit' command to the test debuggee >>>> - The debuggee is normally exiting >>>> - The jdwp backend reports (over the jdwp protocol) an >>>> anonymous class unload event >>>> - The JDI InternalEventHandler thread handles the >>>> ClassUnloadEvent event >>>> - The InternalEventHandler wants to uncache the matching >>>> reference type. >>>> If there is more than one class with the same host class >>>> signature, it can't distinguish them, >>>> and so, deletes all references and re-retrieves them again >>>> (see tracing below): >>>> MY_TRACE: JDI: >>>> VirtualMachineImpl.retrieveClassesBySignature: >>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>> - The jdwp backend debugLoop_run() gets the command from JDI >>>> and calls the functions >>>> classesForSignature() and classStatus() recursively. >>>> - The classStatus() makes a call to the JVMTI GetClassStatus() >>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>> - As a result the jdwp backend reports the JVMTI error to the >>>> JDI, and so, the test fails >>>> >>>> For details, see the analysis in bug report closed as a dup of >>>> the bug 6988950: >>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>> >>>> Some similar cases can be found in the two bug reports (6988950 >>>> and 8024865) describing this issue. >>>> >>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>>> as it is normal at the VM shutdown. >>>> The original jdwp backend implementation had a similar approach >>>> for the raw monitor functions. >>>> Threy use the ignore_vm_death() to workaround the >>>> JVMTI_ERROR_WRONG_PHASE errors. >>>> For reference, please, see the file: src/share/back/util.c >>>> >>>> >>>> Testing: >>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > > From serguei.spitsyn at oracle.com Mon Nov 3 06:16:03 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 02 Nov 2014 22:16:03 -0800 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5454B258.1080104@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> Message-ID: <54571DA3.9090906@oracle.com> On 11/1/14 3:13 AM, Dmitry Samersoff wrote: > Serguei, > > Thank you for good finding. This approach looks much better for me. > > The fix looks good. > > Is it necessary to release vmDeathLock locks at > eventHandler.c:1244 before call > > EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? Nice catch. Yes, it is better to release the lock in that case. Thanks, Dmitry! Serguei > > -Dmitry > > > > On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >> It is 3-rd round of review for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> New webrev: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >> >> >> Summary >> >> For failing scenario, please, refer to the 1-st round RFR below. >> >> I've found what is missed in the jdwp agent shutdown and decided to >> switch from a workaround to a real fix. >> >> The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. >> The agent debugLoop_run() has a guard against the VM shutdown: >> >> 165 } else if (gdata->vmDead && >> 166 ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { >> 167 /* Protect the VM from calls while dead. >> 168 * VirtualMachine cmdSet quietly ignores some cmds >> 169 * after VM death, so, it sends it's own errors. >> 170 */ >> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >> >> >> However, the guard above does not help much if the VM_DEATH event >> happens in the middle of a command execution. >> There is a lack of synchronization here. >> >> The fix introduces new lock (vmDeathLock) which does not allow to >> execute the commands >> and the VM_DEATH event callback concurrently. >> It should work well for any function that is used in implementation of >> the JDWP_COMMAND_SET(VirtualMachine) . >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> >> >> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>> >>> >>> The changes are: >>> - added a comment recommended by Staffan >>> - removed the ignore_wrong_phase() call from function classSignature() >>> >>> The classSignature() function is called in 16 places. >>> Most of them do not tolerate the NULL in place of returned signature >>> and will crash. >>> I'm not comfortable to fix all the occurrences now and suggest to >>> return to this >>> issue after gaining experience with more failure cases that are still >>> expected. >>> The failure with the classSignature() involved was observed only once >>> in the nightly >>> and should be extremely rare reproducible. >>> I'll file a placeholder bug if necessary. >>> >>> Thanks, >>> Serguei >>> >>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> The failing scenario: >>>> The debugger and the debuggee are well aware a VM shutdown has >>>> been started in the target process. >>>> The debugger at this point is not expected to send any commands >>>> to the JDWP agent. >>>> However, the JDI layer (debugger side) and the jdwp agent >>>> (debuggee side) >>>> are not in sync with the consumer layers. >>>> >>>> One reason is because the test debugger does not invoke the JDI >>>> method VirtualMachine.dispose(). >>>> Another reason is that the Debugger and the debuggee processes >>>> are uneasy to sync in general. >>>> >>>> As a result the following steps are possible: >>>> - The test debugger sends a 'quit' command to the test debuggee >>>> - The debuggee is normally exiting >>>> - The jdwp backend reports (over the jdwp protocol) an >>>> anonymous class unload event >>>> - The JDI InternalEventHandler thread handles the >>>> ClassUnloadEvent event >>>> - The InternalEventHandler wants to uncache the matching >>>> reference type. >>>> If there is more than one class with the same host class >>>> signature, it can't distinguish them, >>>> and so, deletes all references and re-retrieves them again >>>> (see tracing below): >>>> MY_TRACE: JDI: >>>> VirtualMachineImpl.retrieveClassesBySignature: >>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>> - The jdwp backend debugLoop_run() gets the command from JDI >>>> and calls the functions >>>> classesForSignature() and classStatus() recursively. >>>> - The classStatus() makes a call to the JVMTI GetClassStatus() >>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>> - As a result the jdwp backend reports the JVMTI error to the >>>> JDI, and so, the test fails >>>> >>>> For details, see the analysis in bug report closed as a dup of >>>> the bug 6988950: >>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>> >>>> Some similar cases can be found in the two bug reports (6988950 >>>> and 8024865) describing this issue. >>>> >>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>>> as it is normal at the VM shutdown. >>>> The original jdwp backend implementation had a similar approach >>>> for the raw monitor functions. >>>> Threy use the ignore_vm_death() to workaround the >>>> JVMTI_ERROR_WRONG_PHASE errors. >>>> For reference, please, see the file: src/share/back/util.c >>>> >>>> >>>> Testing: >>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> > From serguei.spitsyn at oracle.com Mon Nov 3 07:07:15 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 02 Nov 2014 23:07:15 -0800 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54570B68.3060806@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> Message-ID: <545729A3.7090301@oracle.com> On 11/2/14 8:58 PM, David Holmes wrote: > On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >> Serguei, >> >> Thank you for good finding. This approach looks much better for me. >> >> The fix looks good. >> >> Is it necessary to release vmDeathLock locks at >> eventHandler.c:1244 before call >> >> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? > > I agree this looks necessary, or at least more clean (if things are > failing we really don't know what is happening). Agreed (replied to Dmitry). > > More generally I'm concerned about whether any of the code paths taken > while holding the new lock can result in deadlock - in particular with > regard to the resumeLock ? The cbVMDeath() function never holds both vmDeathLock and resumeLock at the same time, so there is no chance for a deadlock that involves both these locks. Two more locks used in the cbVMDeath() are the callbackBlock and callbackLock. These two locks look completely unrelated to the debugLoop_run(). The debugLoop_run() function also uses the cmdQueueLock. The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at the same time. So that I do not see any potential to introduce new deadlock with the vmDeathLock. However, it is still easy to overlook something here. Please, let me know if you see any danger. Thanks, Serguei > > David > >> -Dmitry >> >> >> >> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>> >>> It is 3-rd round of review for: >>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>> >>> New webrev: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>> >>> >>> >>> Summary >>> >>> For failing scenario, please, refer to the 1-st round RFR below. >>> >>> I've found what is missed in the jdwp agent shutdown and decided to >>> switch from a workaround to a real fix. >>> >>> The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. >>> The agent debugLoop_run() has a guard against the VM shutdown: >>> >>> 165 } else if (gdata->vmDead && >>> 166 ((cmd->cmdSet) != >>> JDWP_COMMAND_SET(VirtualMachine))) { >>> 167 /* Protect the VM from calls while dead. >>> 168 * VirtualMachine cmdSet quietly ignores some >>> cmds >>> 169 * after VM death, so, it sends it's own errors. >>> 170 */ >>> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >>> >>> >>> However, the guard above does not help much if the VM_DEATH event >>> happens in the middle of a command execution. >>> There is a lack of synchronization here. >>> >>> The fix introduces new lock (vmDeathLock) which does not allow to >>> execute the commands >>> and the VM_DEATH event callback concurrently. >>> It should work well for any function that is used in >>> implementation of >>> the JDWP_COMMAND_SET(VirtualMachine) . >>> >>> >>> Testing: >>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>> >>>> >>>> >>>> The changes are: >>>> - added a comment recommended by Staffan >>>> - removed the ignore_wrong_phase() call from function >>>> classSignature() >>>> >>>> The classSignature() function is called in 16 places. >>>> Most of them do not tolerate the NULL in place of returned signature >>>> and will crash. >>>> I'm not comfortable to fix all the occurrences now and suggest to >>>> return to this >>>> issue after gaining experience with more failure cases that are still >>>> expected. >>>> The failure with the classSignature() involved was observed only once >>>> in the nightly >>>> and should be extremely rare reproducible. >>>> I'll file a placeholder bug if necessary. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>> >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The failing scenario: >>>>> The debugger and the debuggee are well aware a VM shutdown has >>>>> been started in the target process. >>>>> The debugger at this point is not expected to send any commands >>>>> to the JDWP agent. >>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>> (debuggee side) >>>>> are not in sync with the consumer layers. >>>>> >>>>> One reason is because the test debugger does not invoke the JDI >>>>> method VirtualMachine.dispose(). >>>>> Another reason is that the Debugger and the debuggee processes >>>>> are uneasy to sync in general. >>>>> >>>>> As a result the following steps are possible: >>>>> - The test debugger sends a 'quit' command to the test >>>>> debuggee >>>>> - The debuggee is normally exiting >>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>> anonymous class unload event >>>>> - The JDI InternalEventHandler thread handles the >>>>> ClassUnloadEvent event >>>>> - The InternalEventHandler wants to uncache the matching >>>>> reference type. >>>>> If there is more than one class with the same host class >>>>> signature, it can't distinguish them, >>>>> and so, deletes all references and re-retrieves them again >>>>> (see tracing below): >>>>> MY_TRACE: JDI: >>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>> - The jdwp backend debugLoop_run() gets the command from JDI >>>>> and calls the functions >>>>> classesForSignature() and classStatus() recursively. >>>>> - The classStatus() makes a call to the JVMTI >>>>> GetClassStatus() >>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>> - As a result the jdwp backend reports the JVMTI error to the >>>>> JDI, and so, the test fails >>>>> >>>>> For details, see the analysis in bug report closed as a dup of >>>>> the bug 6988950: >>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>> >>>>> Some similar cases can be found in the two bug reports (6988950 >>>>> and 8024865) describing this issue. >>>>> >>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>>>> as it is normal at the VM shutdown. >>>>> The original jdwp backend implementation had a similar approach >>>>> for the raw monitor functions. >>>>> Threy use the ignore_vm_death() to workaround the >>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>> For reference, please, see the file: src/share/back/util.c >>>>> >>>>> >>>>> Testing: >>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>> tests >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> >> From serguei.spitsyn at oracle.com Mon Nov 3 07:13:16 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 02 Nov 2014 23:13:16 -0800 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545729A3.7090301@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> Message-ID: <54572B0C.4000100@oracle.com> David, I forgot to thank you for reviewing! Thanks, Serguei On 11/2/14 11:07 PM, serguei.spitsyn at oracle.com wrote: > On 11/2/14 8:58 PM, David Holmes wrote: >> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Thank you for good finding. This approach looks much better for me. >>> >>> The fix looks good. >>> >>> Is it necessary to release vmDeathLock locks at >>> eventHandler.c:1244 before call >>> >>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >> >> I agree this looks necessary, or at least more clean (if things are >> failing we really don't know what is happening). > > Agreed (replied to Dmitry). > >> >> More generally I'm concerned about whether any of the code paths >> taken while holding the new lock can result in deadlock - in >> particular with regard to the resumeLock ? > > The cbVMDeath() function never holds both vmDeathLock and resumeLock > at the same time, > so there is no chance for a deadlock that involves both these locks. > > Two more locks used in the cbVMDeath() are the callbackBlock and > callbackLock. > These two locks look completely unrelated to the debugLoop_run(). > > The debugLoop_run() function also uses the cmdQueueLock. > The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at > the same time. > > So that I do not see any potential to introduce new deadlock with the > vmDeathLock. > > However, it is still easy to overlook something here. > Please, let me know if you see any danger. > > Thanks, > Serguei > >> >> David >> >>> -Dmitry >>> >>> >>> >>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>> >>>> It is 3-rd round of review for: >>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>> >>>> New webrev: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>> >>>> >>>> >>>> Summary >>>> >>>> For failing scenario, please, refer to the 1-st round RFR below. >>>> >>>> I've found what is missed in the jdwp agent shutdown and decided to >>>> switch from a workaround to a real fix. >>>> >>>> The agent VM_DEATH callback sets the gdata field: gdata->vmDead >>>> = 1. >>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>> >>>> 165 } else if (gdata->vmDead && >>>> 166 ((cmd->cmdSet) != >>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>> 167 /* Protect the VM from calls while dead. >>>> 168 * VirtualMachine cmdSet quietly ignores some >>>> cmds >>>> 169 * after VM death, so, it sends it's own errors. >>>> 170 */ >>>> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >>>> >>>> >>>> However, the guard above does not help much if the VM_DEATH event >>>> happens in the middle of a command execution. >>>> There is a lack of synchronization here. >>>> >>>> The fix introduces new lock (vmDeathLock) which does not allow to >>>> execute the commands >>>> and the VM_DEATH event callback concurrently. >>>> It should work well for any function that is used in >>>> implementation of >>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>> >>>> >>>> Testing: >>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>> The updated webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>> >>>>> >>>>> >>>>> The changes are: >>>>> - added a comment recommended by Staffan >>>>> - removed the ignore_wrong_phase() call from function >>>>> classSignature() >>>>> >>>>> The classSignature() function is called in 16 places. >>>>> Most of them do not tolerate the NULL in place of returned signature >>>>> and will crash. >>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>> return to this >>>>> issue after gaining experience with more failure cases that are still >>>>> expected. >>>>> The failure with the classSignature() involved was observed only once >>>>> in the nightly >>>>> and should be extremely rare reproducible. >>>>> I'll file a placeholder bug if necessary. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The failing scenario: >>>>>> The debugger and the debuggee are well aware a VM shutdown has >>>>>> been started in the target process. >>>>>> The debugger at this point is not expected to send any >>>>>> commands >>>>>> to the JDWP agent. >>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>> (debuggee side) >>>>>> are not in sync with the consumer layers. >>>>>> >>>>>> One reason is because the test debugger does not invoke the >>>>>> JDI >>>>>> method VirtualMachine.dispose(). >>>>>> Another reason is that the Debugger and the debuggee processes >>>>>> are uneasy to sync in general. >>>>>> >>>>>> As a result the following steps are possible: >>>>>> - The test debugger sends a 'quit' command to the test >>>>>> debuggee >>>>>> - The debuggee is normally exiting >>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>> anonymous class unload event >>>>>> - The JDI InternalEventHandler thread handles the >>>>>> ClassUnloadEvent event >>>>>> - The InternalEventHandler wants to uncache the matching >>>>>> reference type. >>>>>> If there is more than one class with the same host class >>>>>> signature, it can't distinguish them, >>>>>> and so, deletes all references and re-retrieves them again >>>>>> (see tracing below): >>>>>> MY_TRACE: JDI: >>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>> - The jdwp backend debugLoop_run() gets the command from JDI >>>>>> and calls the functions >>>>>> classesForSignature() and classStatus() recursively. >>>>>> - The classStatus() makes a call to the JVMTI >>>>>> GetClassStatus() >>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>> - As a result the jdwp backend reports the JVMTI error to >>>>>> the >>>>>> JDI, and so, the test fails >>>>>> >>>>>> For details, see the analysis in bug report closed as a dup of >>>>>> the bug 6988950: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>> >>>>>> Some similar cases can be found in the two bug reports >>>>>> (6988950 >>>>>> and 8024865) describing this issue. >>>>>> >>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>>>>> as it is normal at the VM shutdown. >>>>>> The original jdwp backend implementation had a similar >>>>>> approach >>>>>> for the raw monitor functions. >>>>>> Threy use the ignore_vm_death() to workaround the >>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>> For reference, please, see the file: src/share/back/util.c >>>>>> >>>>>> >>>>>> Testing: >>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>> tests >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >>> > From staffan.larsen at oracle.com Mon Nov 3 09:48:38 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 3 Nov 2014 10:48:38 +0100 Subject: RFR 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double In-Reply-To: <5451413B.2080807@oracle.com> References: <5450F08C.5050804@oracle.com> <5451413B.2080807@oracle.com> Message-ID: <1F1664AE-C4F1-4C54-ACCB-A9BFE9AAFDA6@oracle.com> With Mandy?s suggestions this looks good to me too. /Staffan > On 29 okt 2014, at 20:34, Mandy Chung wrote: > > > On 10/29/2014 6:50 AM, Jaroslav Bachorik wrote: >> Please review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8061616 >> Webrev : >> (jdk): http://cr.openjdk.java.net/~jbachorik/8061616/jdk/webrev.00/ >> (hotspot): http://cr.openjdk.java.net/~jbachorik/8061616/hotspot/webrev.00/ >> > > share/classes/sun/management/HotSpotDiagnostic.java > line 105-110, 117-122: you can replace with new IAE(String, Throwable cause) > The original code was written before that IAE constructor was added. > > test/com/sun/management/HotSpotDiagnosticMXBean/GetDoubleVMOption.java > you can take out line 28 > > Looks okay otherwise. > > Mandy From jaroslav.bachorik at oracle.com Mon Nov 3 12:37:01 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 03 Nov 2014 13:37:01 +0100 Subject: [ping] Re: RFR 8058506: ThreadMXBeanStateTest throws exception In-Reply-To: <5449032D.5070208@oracle.com> References: <5444EE20.6090803@oracle.com> <54465F27.3080204@oracle.com> <54469C35.8090005@oracle.com> <5448CE39.704@oracle.com> <5449032D.5070208@oracle.com> Message-ID: <545776ED.2030307@oracle.com> May I have a (R)eviewer to take a look at this, please? http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 -JB- On 10/23/2014 03:31 PM, Erik Gahlin wrote: > Looks good! > > Erik > > Jaroslav Bachorik skrev 2014-10-23 11:45: >> On 10/21/2014 07:47 PM, Jaroslav Bachorik wrote: >>> On 10/21/2014 03:27 PM, Erik Gahlin wrote: >>>> Have you considered creating a LogMessage class that keeps the logCntr >>>> value and the log message, instead of putting the counter into the log >>>> string and parsing it. >>> >>> Yes. And didn't go that way in order to prevent creating a lot of >>> throwaway stringbuilder instances (the Formatter works that way) - but >>> it might (almost certainly) be a premature optimization. I will clean it >>> up and resubmit the request. >> >> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 >> >> I moved the log collection logic to a separate class available in the >> testlib now. The code is much more concise now. >> >> -JB- >> >>> >>> -JB- >>> >>>> >>>> Seems simpler and easier to understand. >>>> >>>> Erik >>>> >>>> Jaroslav Bachorik skrev 2014-10-20 13:12: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8058506 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8058506/webrev.00 >>>>> >>>>> The test fails intermittently due to the log printing blocking the >>>>> test thread from time to time, resulting in incorrect data reported by >>>>> ThreadMXBean. >>>>> >>>>> The solution is to use per-thread non-blocking StringBuilders (wrapped >>>>> in Formatter instances) and aggregate the log output only after the >>>>> test is finished. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From shanliang.jiang at oracle.com Mon Nov 3 13:33:53 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 03 Nov 2014 14:33:53 +0100 Subject: Code review: 8046192 Eliminate SNMP dependencies to the internal APIs from open jdk modules In-Reply-To: <5453BC5C.6000804@oracle.com> References: <5453BC5C.6000804@oracle.com> Message-ID: <54578441.6010304@oracle.com> Hi, Here is version 2: http://cr.openjdk.java.net/~sjiang/JDK-8046192/01/ The modification in ./jdk/src was missed in the first version. The webreviews show only modification in the public part. Thanks, Shanliang shanliang wrote: > Hi, > > The fix is to remove unnecessary exports for jdk.snmp module. > > bug: https://bugs.openjdk.java.net/browse/JDK-8046192 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8046192/00/ > > Thanks, > Shanliang From Alan.Bateman at oracle.com Mon Nov 3 16:20:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Nov 2014 16:20:22 +0000 Subject: Code review: 8046192 Eliminate SNMP dependencies to the internal APIs from open jdk modules In-Reply-To: <54578441.6010304@oracle.com> References: <5453BC5C.6000804@oracle.com> <54578441.6010304@oracle.com> Message-ID: <5457AB46.5040300@oracle.com> On 03/11/2014 13:33, shanliang wrote: > Hi, Here is version 2: > http://cr.openjdk.java.net/~sjiang/JDK-8046192/01/ > > The modification in ./jdk/src was missed in the first version. > This looks okay to me now. -Alan From mandy.chung at oracle.com Mon Nov 3 18:25:30 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 03 Nov 2014 10:25:30 -0800 Subject: Code review: 8046192 Eliminate SNMP dependencies to the internal APIs from open jdk modules In-Reply-To: <54578441.6010304@oracle.com> References: <5453BC5C.6000804@oracle.com> <54578441.6010304@oracle.com> Message-ID: <5457C89A.2080208@oracle.com> On 11/3/14 5:33 AM, shanliang wrote: > Hi, Here is version 2: > http://cr.openjdk.java.net/~sjiang/JDK-8046192/01/ > Looks okay to me. Thanks Mandy From daniel.daugherty at oracle.com Mon Nov 3 18:41:33 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Nov 2014 11:41:33 -0700 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5453F9F4.20309@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> Message-ID: <5457CC5D.3010300@oracle.com> On 10/31/14 3:07 PM, serguei.spitsyn at oracle.com wrote: > > It is 3-rd round of review for: > https://bugs.openjdk.java.net/browse/JDK-6988950 > > New webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ Thumbs up on the code. I have comment suggestions below... src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line 149: debugMonitorEnter(vmDeathLock); Perhaps this comment would help: /* * We grab the vmDeathLock here to prevent the cbVMDeath() * event handler from tearing things down while we're * asynchronously processing a command. */ src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 71: jrawMonitorID vmDeathLock; A nice blurb about the new global lock's protocol would be good here. Something like: /* * Coordinates the cbVMDeath() event handler and the * debugLoop_run() thread. */ line 1236: debugMonitorEnter(vmDeathLock); Perhaps this comment would help: /* * We grab the vmDeathLock here to prevent the debugLoop_run() * thread from asynchronously dispatching another command. */ This block caught my eye: 1295 /* 1296 * The VM will die soon after the completion of this callback - we 1297 * may need to do a final synchronization with the command loop to 1298 * avoid the VM terminating with replying to the final (resume) 1299 * command. 1300 */ 1301 debugLoop_sync(); The above comment implies that debugLoop_sync() does something to coordinate this code (cbVMDeath()) with the debugLoop code, but clearly something is incomplete. It's entirely possible that this debugLoop_sync() is solving a different problem that happens after the debugLoop has left its command processing loop and realizes that the VM is shutting down. Don't know for sure. I haven't been in this code for quite a while... Dan > > > Summary > > For failing scenario, please, refer to the 1-st round RFR below. > > I've found what is missed in the jdwp agent shutdown and decided to > switch from a workaround to a real fix. > > The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. > The agent debugLoop_run() has a guard against the VM shutdown: > 165 } else if (gdata->vmDead && > 166 ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { > 167 /* Protect the VM from calls while dead. > 168 * VirtualMachine cmdSet quietly ignores some cmds > 169 * after VM death, so, it sends it's own errors. > 170 */ > 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); > > However, the guard above does not help much if the VM_DEATH event > happens in the middle of a command execution. > There is a lack of synchronization here. > > The fix introduces new lock (vmDeathLock) which does not allow to > execute the commands > and the VM_DEATH event callback concurrently. > It should work well for any function that is used in implementation > of the JDWP_COMMAND_SET(VirtualMachine) . > > > Testing: > Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests > > > Thanks, > Serguei > > > On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >> >> >> The changes are: >> - added a comment recommended by Staffan >> - removed the ignore_wrong_phase() call from function classSignature() >> >> The classSignature() function is called in 16 places. >> Most of them do not tolerate the NULL in place of returned signature >> and will crash. >> I'm not comfortable to fix all the occurrences now and suggest to >> return to this >> issue after gaining experience with more failure cases that are still >> expected. >> The failure with the classSignature() involved was observed only once >> in the nightly >> and should be extremely rare reproducible. >> I'll file a placeholder bug if necessary. >> >> Thanks, >> Serguei >> >> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>> >>> >>> >>> Summary: >>> >>> The failing scenario: >>> The debugger and the debuggee are well aware a VM shutdown has >>> been started in the target process. >>> The debugger at this point is not expected to send any commands >>> to the JDWP agent. >>> However, the JDI layer (debugger side) and the jdwp agent >>> (debuggee side) >>> are not in sync with the consumer layers. >>> >>> One reason is because the test debugger does not invoke the JDI >>> method VirtualMachine.dispose(). >>> Another reason is that the Debugger and the debuggee processes >>> are uneasy to sync in general. >>> >>> As a result the following steps are possible: >>> - The test debugger sends a 'quit' command to the test debuggee >>> - The debuggee is normally exiting >>> - The jdwp backend reports (over the jdwp protocol) an >>> anonymous class unload event >>> - The JDI InternalEventHandler thread handles the >>> ClassUnloadEvent event >>> - The InternalEventHandler wants to uncache the matching >>> reference type. >>> If there is more than one class with the same host class >>> signature, it can't distinguish them, >>> and so, deletes all references and re-retrieves them again >>> (see tracing below): >>> MY_TRACE: JDI: >>> VirtualMachineImpl.retrieveClassesBySignature: >>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>> - The jdwp backend debugLoop_run() gets the command from JDI >>> and calls the functions >>> classesForSignature() and classStatus() recursively. >>> - The classStatus() makes a call to the JVMTI >>> GetClassStatus() and gets the JVMTI_ERROR_WRONG_PHASE >>> - As a result the jdwp backend reports the JVMTI error to the >>> JDI, and so, the test fails >>> >>> For details, see the analysis in bug report closed as a dup of >>> the bug 6988950: >>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>> >>> Some similar cases can be found in the two bug reports (6988950 >>> and 8024865) describing this issue. >>> >>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>> as it is normal at the VM shutdown. >>> The original jdwp backend implementation had a similar approach >>> for the raw monitor functions. >>> Threy use the ignore_vm_death() to workaround the >>> JVMTI_ERROR_WRONG_PHASE errors. >>> For reference, please, see the file: src/share/back/util.c >>> >>> >>> Testing: >>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Nov 3 19:35:38 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Nov 2014 11:35:38 -0800 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5457CC5D.3010300@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5457CC5D.3010300@oracle.com> Message-ID: <5457D90A.1040608@oracle.com> On 11/3/14 10:41 AM, Daniel D. Daugherty wrote: > On 10/31/14 3:07 PM, serguei.spitsyn at oracle.com wrote: >> >> It is 3-rd round of review for: >> https://bugs.openjdk.java.net/browse/JDK-6988950 >> >> New webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ > > Thumbs up on the code. Thanks, Dan! > I have comment suggestions below... > > src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c > line 149: debugMonitorEnter(vmDeathLock); > Perhaps this comment would help: > /* > * We grab the vmDeathLock here to prevent the cbVMDeath() > * event handler from tearing things down while we're > * asynchronously processing a command. > */ Done > > src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c > line 71: jrawMonitorID vmDeathLock; > A nice blurb about the new global lock's protocol would be > good here. Something like: > > /* > * Coordinates the cbVMDeath() event handler and the > * debugLoop_run() thread. > */ > Done > line 1236: debugMonitorEnter(vmDeathLock); > Perhaps this comment would help: > /* > * We grab the vmDeathLock here to prevent the debugLoop_run() > * thread from asynchronously dispatching another command. > */ > Done I also think, it'd be enough to narrow the scope of synchronization around the event_callback() call: /* * Coordinates the cbVMDeath() event handler and the * debugLoop_run() thread. */ debugMonitorEnter(vmDeathLock); /* Only now should we actually process the VM death event */ (void)memset(&info,0,sizeof(info)); info.ei = EI_VM_DEATH; event_callback(env, &info); debugMonitorExit(vmDeathLock); > This block caught my eye: > > 1295 /* > 1296 * The VM will die soon after the completion of this > callback - we > 1297 * may need to do a final synchronization with the > command loop to > 1298 * avoid the VM terminating with replying to the final > (resume) > 1299 * command. > 1300 */ > 1301 debugLoop_sync(); > > The above comment implies that debugLoop_sync() does something to > coordinate this code (cbVMDeath()) with the debugLoop code, but > clearly something is incomplete. It's entirely possible that this > debugLoop_sync() is solving a different problem that happens after > the debugLoop has left its command processing loop and realizes > that the VM is shutting down. This block caught my eye too. I agree, it looks incomplete. The cbVMDeath() callback waits until a resume command finishes if it has been started. Not sure how useful it is. Thanks! Serguei > > Don't know for sure. I haven't been in this code for quite a while... > > Dan > > >> >> >> Summary >> >> For failing scenario, please, refer to the 1-st round RFR below. >> >> I've found what is missed in the jdwp agent shutdown and decided to >> switch from a workaround to a real fix. >> >> The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. >> The agent debugLoop_run() has a guard against the VM shutdown: >> 165 } else if (gdata->vmDead && >> 166 ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { >> 167 /* Protect the VM from calls while dead. >> 168 * VirtualMachine cmdSet quietly ignores some cmds >> 169 * after VM death, so, it sends it's own errors. >> 170 */ >> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >> >> However, the guard above does not help much if the VM_DEATH event >> happens in the middle of a command execution. >> There is a lack of synchronization here. >> >> The fix introduces new lock (vmDeathLock) which does not allow to >> execute the commands >> and the VM_DEATH event callback concurrently. >> It should work well for any function that is used in implementation >> of the JDWP_COMMAND_SET(VirtualMachine) . >> >> >> Testing: >> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >> >> >> Thanks, >> Serguei >> >> >> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>> >>> >>> The changes are: >>> - added a comment recommended by Staffan >>> - removed the ignore_wrong_phase() call from function >>> classSignature() >>> >>> The classSignature() function is called in 16 places. >>> Most of them do not tolerate the NULL in place of returned signature >>> and will crash. >>> I'm not comfortable to fix all the occurrences now and suggest to >>> return to this >>> issue after gaining experience with more failure cases that are >>> still expected. >>> The failure with the classSignature() involved was observed only >>> once in the nightly >>> and should be extremely rare reproducible. >>> I'll file a placeholder bug if necessary. >>> >>> Thanks, >>> Serguei >>> >>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> The failing scenario: >>>> The debugger and the debuggee are well aware a VM shutdown has >>>> been started in the target process. >>>> The debugger at this point is not expected to send any >>>> commands to the JDWP agent. >>>> However, the JDI layer (debugger side) and the jdwp agent >>>> (debuggee side) >>>> are not in sync with the consumer layers. >>>> >>>> One reason is because the test debugger does not invoke the >>>> JDI method VirtualMachine.dispose(). >>>> Another reason is that the Debugger and the debuggee processes >>>> are uneasy to sync in general. >>>> >>>> As a result the following steps are possible: >>>> - The test debugger sends a 'quit' command to the test debuggee >>>> - The debuggee is normally exiting >>>> - The jdwp backend reports (over the jdwp protocol) an >>>> anonymous class unload event >>>> - The JDI InternalEventHandler thread handles the >>>> ClassUnloadEvent event >>>> - The InternalEventHandler wants to uncache the matching >>>> reference type. >>>> If there is more than one class with the same host class >>>> signature, it can't distinguish them, >>>> and so, deletes all references and re-retrieves them again >>>> (see tracing below): >>>> MY_TRACE: JDI: >>>> VirtualMachineImpl.retrieveClassesBySignature: >>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>> - The jdwp backend debugLoop_run() gets the command from JDI >>>> and calls the functions >>>> classesForSignature() and classStatus() recursively. >>>> - The classStatus() makes a call to the JVMTI >>>> GetClassStatus() and gets the JVMTI_ERROR_WRONG_PHASE >>>> - As a result the jdwp backend reports the JVMTI error to >>>> the JDI, and so, the test fails >>>> >>>> For details, see the analysis in bug report closed as a dup of >>>> the bug 6988950: >>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>> >>>> Some similar cases can be found in the two bug reports >>>> (6988950 and 8024865) describing this issue. >>>> >>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>>> as it is normal at the VM shutdown. >>>> The original jdwp backend implementation had a similar >>>> approach for the raw monitor functions. >>>> Threy use the ignore_vm_death() to workaround the >>>> JVMTI_ERROR_WRONG_PHASE errors. >>>> For reference, please, see the file: src/share/back/util.c >>>> >>>> >>>> Testing: >>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Mon Nov 3 20:19:54 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 03 Nov 2014 15:19:54 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: Message-ID: <5457E36A.3020800@oracle.com> Hi Jeremy, I reviewed your new code and it looks fine. I had one comment in http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html The name "need_to_resolve" doesn't make sense when reading this code. Isn't it more like "need_to_ensure_space" ? I think method resolution with the other name, which it doesn't do. I was trying to find a way to make this new code not appear twice (maybe with a local jvmtiEnv function get_jmethodID(m) - instanceK_h is m->method_holder()). Also, I was trying to figure out if the new class in utilities called chunkedList.hpp could be used to store jmethodIDs, since the data structures are similar. There is still more things in JNIMethodBlock has to do so I think a specialized structure is still needed (which is why I originally wrote it to be very simple). I'm not sure if the comment above it still applies. Maybe only the first and third sentences. Can you rewrite the comment slightly? Your other comments in the changes are good. I can't completely answer your question about reusing free_methods - but if a jmethodID is created provisionally in InstanceKlass::get_jmethod_id and not needed because it loses the race in the method id cache, it's never handed back to native code, so it's safe to reuse. This is different than jmethodIDs for methods that are unloaded. They are cleared and never reused. At least that's my reading of this caching code but it's pretty complicated stuff. I've also run our nsk and jck vm/jvmti on this change and they all passed. I'd be happy to sponsor it with these suggested changes and it needs another reviewer. Thanks for diagnosing and fixing this problem! Coleen On 10/30/2014 01:02 PM, Jeremy Manson wrote: > There's a significant regression in the speed of JVMTI GetClassMethods in > JDK8. I've tracked this down to allocation of jmethodids in a tight loop. > The issue can be addressed by preallocating enough space for all of the > jmethodids when starting the operation and not iterating over all of the > existing jmethodids when you allocate a new one. > > A patch is here: > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ > > A reproducible test case can be found here: > > http://cr.openjdk.java.net/~jmanson/8062116/repro/ > > It's a benchmark, though: I have no idea how to turn it into a test. > > For whoever reviews it: can you explain to me why it is okay that this code > reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a lot of > problems stemming from accidental reuse. > > Jeremy From david.holmes at oracle.com Tue Nov 4 06:50:45 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Nov 2014 16:50:45 +1000 Subject: [ping] Re: RFR 8058506: ThreadMXBeanStateTest throws exception In-Reply-To: <545776ED.2030307@oracle.com> References: <5444EE20.6090803@oracle.com> <54465F27.3080204@oracle.com> <54469C35.8090005@oracle.com> <5448CE39.704@oracle.com> <5449032D.5070208@oracle.com> <545776ED.2030307@oracle.com> Message-ID: <54587745.8060502@oracle.com> On 3/11/2014 10:37 PM, Jaroslav Bachorik wrote: > May I have a (R)eviewer to take a look at this, please? > > http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 I don't understand the need for the semaphore given you do: 116 thread.join(); 117 System.out.println(thread.getLog()); If join() returns normally, such that you call getLog() then run() must have completed and the semaphore has to be signalled. So the semaphore is serving no purpose here that I can see. If you want to ensure getLog() blocks until the thread has terminated then it could internally do a join(). David ----- David > -JB- > > On 10/23/2014 03:31 PM, Erik Gahlin wrote: >> Looks good! >> >> Erik >> >> Jaroslav Bachorik skrev 2014-10-23 11:45: >>> On 10/21/2014 07:47 PM, Jaroslav Bachorik wrote: >>>> On 10/21/2014 03:27 PM, Erik Gahlin wrote: >>>>> Have you considered creating a LogMessage class that keeps the logCntr >>>>> value and the log message, instead of putting the counter into the log >>>>> string and parsing it. >>>> >>>> Yes. And didn't go that way in order to prevent creating a lot of >>>> throwaway stringbuilder instances (the Formatter works that way) - but >>>> it might (almost certainly) be a premature optimization. I will >>>> clean it >>>> up and resubmit the request. >>> >>> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 >>> >>> I moved the log collection logic to a separate class available in the >>> testlib now. The code is much more concise now. >>> >>> -JB- >>> >>>> >>>> -JB- >>>> >>>>> >>>>> Seems simpler and easier to understand. >>>>> >>>>> Erik >>>>> >>>>> Jaroslav Bachorik skrev 2014-10-20 13:12: >>>>>> Please, review the following test change >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8058506 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8058506/webrev.00 >>>>>> >>>>>> The test fails intermittently due to the log printing blocking the >>>>>> test thread from time to time, resulting in incorrect data >>>>>> reported by >>>>>> ThreadMXBean. >>>>>> >>>>>> The solution is to use per-thread non-blocking StringBuilders >>>>>> (wrapped >>>>>> in Formatter instances) and aggregate the log output only after the >>>>>> test is finished. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Tue Nov 4 09:49:31 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 04 Nov 2014 10:49:31 +0100 Subject: [ping] Re: RFR 8058506: ThreadMXBeanStateTest throws exception In-Reply-To: <54587745.8060502@oracle.com> References: <5444EE20.6090803@oracle.com> <54465F27.3080204@oracle.com> <54469C35.8090005@oracle.com> <5448CE39.704@oracle.com> <5449032D.5070208@oracle.com> <545776ED.2030307@oracle.com> <54587745.8060502@oracle.com> Message-ID: <5458A12B.2020205@oracle.com> On 11/04/2014 07:50 AM, David Holmes wrote: > On 3/11/2014 10:37 PM, Jaroslav Bachorik wrote: >> May I have a (R)eviewer to take a look at this, please? >> >> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 > > I don't understand the need for the semaphore given you do: > > 116 thread.join(); > 117 System.out.println(thread.getLog()); > > If join() returns normally, such that you call getLog() then run() must > have completed and the semaphore has to be signalled. So the semaphore > is serving no purpose here that I can see. If you want to ensure > getLog() blocks until the thread has terminated then it could internally > do a join(). I prefer having the precondition of "getLog()" method enforced inside the ThreadStateController class and not to rely on the caller to do the right thing. I've replaced the semaphore with the plain thrd.join() call as suggested. http://cr.openjdk.java.net/~jbachorik/8058506/webrev.02 -JB- > > David > ----- > > David > >> -JB- >> >> On 10/23/2014 03:31 PM, Erik Gahlin wrote: >>> Looks good! >>> >>> Erik >>> >>> Jaroslav Bachorik skrev 2014-10-23 11:45: >>>> On 10/21/2014 07:47 PM, Jaroslav Bachorik wrote: >>>>> On 10/21/2014 03:27 PM, Erik Gahlin wrote: >>>>>> Have you considered creating a LogMessage class that keeps the >>>>>> logCntr >>>>>> value and the log message, instead of putting the counter into the >>>>>> log >>>>>> string and parsing it. >>>>> >>>>> Yes. And didn't go that way in order to prevent creating a lot of >>>>> throwaway stringbuilder instances (the Formatter works that way) - but >>>>> it might (almost certainly) be a premature optimization. I will >>>>> clean it >>>>> up and resubmit the request. >>>> >>>> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 >>>> >>>> I moved the log collection logic to a separate class available in the >>>> testlib now. The code is much more concise now. >>>> >>>> -JB- >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> Seems simpler and easier to understand. >>>>>> >>>>>> Erik >>>>>> >>>>>> Jaroslav Bachorik skrev 2014-10-20 13:12: >>>>>>> Please, review the following test change >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8058506 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8058506/webrev.00 >>>>>>> >>>>>>> The test fails intermittently due to the log printing blocking the >>>>>>> test thread from time to time, resulting in incorrect data >>>>>>> reported by >>>>>>> ThreadMXBean. >>>>>>> >>>>>>> The solution is to use per-thread non-blocking StringBuilders >>>>>>> (wrapped >>>>>>> in Formatter instances) and aggregate the log output only after the >>>>>>> test is finished. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Tue Nov 4 10:48:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Nov 2014 20:48:51 +1000 Subject: Trivial RFR: 8036616: [TESTBUG] Embedded: sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be launched with -XX:+UsePerfData Message-ID: <5458AF13.209@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8036616 webrev: inline below Trivial test modification contributed by Pavel Chistyakov. I've reviewed it but would like a second review from serviceability please. I plan to push via hs-rt forest. Thanks, David diff -r ef6ec39fd6bd test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java --- a/test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java +++ b/test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java @@ -34,6 +34,7 @@ * @bug 6672135 * @summary setInterval() for local MonitoredHost and local MonitoredVm * @author Tomas Hurka + * @run main/othervm -XX:+UsePerfData CR6672135 */ public class CR6672135 { From david.holmes at oracle.com Tue Nov 4 10:56:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Nov 2014 20:56:46 +1000 Subject: [ping] Re: RFR 8058506: ThreadMXBeanStateTest throws exception In-Reply-To: <5458A12B.2020205@oracle.com> References: <5444EE20.6090803@oracle.com> <54465F27.3080204@oracle.com> <54469C35.8090005@oracle.com> <5448CE39.704@oracle.com> <5449032D.5070208@oracle.com> <545776ED.2030307@oracle.com> <54587745.8060502@oracle.com> <5458A12B.2020205@oracle.com> Message-ID: <5458B0EE.7010909@oracle.com> On 4/11/2014 7:49 PM, Jaroslav Bachorik wrote: > On 11/04/2014 07:50 AM, David Holmes wrote: >> On 3/11/2014 10:37 PM, Jaroslav Bachorik wrote: >>> May I have a (R)eviewer to take a look at this, please? >>> >>> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 >> >> I don't understand the need for the semaphore given you do: >> >> 116 thread.join(); >> 117 System.out.println(thread.getLog()); >> >> If join() returns normally, such that you call getLog() then run() must >> have completed and the semaphore has to be signalled. So the semaphore >> is serving no purpose here that I can see. If you want to ensure >> getLog() blocks until the thread has terminated then it could internally >> do a join(). > > I prefer having the precondition of "getLog()" method enforced inside > the ThreadStateController class and not to rely on the caller to do the > right thing. > > I've replaced the semaphore with the plain thrd.join() call as suggested. Ok. But then the test doesn't need the join() any more. :) Seems okay though - Reviewed. Thanks, David > http://cr.openjdk.java.net/~jbachorik/8058506/webrev.02 > > -JB- > >> >> David >> ----- >> >> David >> >>> -JB- >>> >>> On 10/23/2014 03:31 PM, Erik Gahlin wrote: >>>> Looks good! >>>> >>>> Erik >>>> >>>> Jaroslav Bachorik skrev 2014-10-23 11:45: >>>>> On 10/21/2014 07:47 PM, Jaroslav Bachorik wrote: >>>>>> On 10/21/2014 03:27 PM, Erik Gahlin wrote: >>>>>>> Have you considered creating a LogMessage class that keeps the >>>>>>> logCntr >>>>>>> value and the log message, instead of putting the counter into the >>>>>>> log >>>>>>> string and parsing it. >>>>>> >>>>>> Yes. And didn't go that way in order to prevent creating a lot of >>>>>> throwaway stringbuilder instances (the Formatter works that way) - >>>>>> but >>>>>> it might (almost certainly) be a premature optimization. I will >>>>>> clean it >>>>>> up and resubmit the request. >>>>> >>>>> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 >>>>> >>>>> I moved the log collection logic to a separate class available in the >>>>> testlib now. The code is much more concise now. >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> Seems simpler and easier to understand. >>>>>>> >>>>>>> Erik >>>>>>> >>>>>>> Jaroslav Bachorik skrev 2014-10-20 13:12: >>>>>>>> Please, review the following test change >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8058506 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8058506/webrev.00 >>>>>>>> >>>>>>>> The test fails intermittently due to the log printing blocking the >>>>>>>> test thread from time to time, resulting in incorrect data >>>>>>>> reported by >>>>>>>> ThreadMXBean. >>>>>>>> >>>>>>>> The solution is to use per-thread non-blocking StringBuilders >>>>>>>> (wrapped >>>>>>>> in Formatter instances) and aggregate the log output only after the >>>>>>>> test is finished. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>> >>>>>> >>>>> >>>> >>> > From jaroslav.bachorik at oracle.com Tue Nov 4 10:57:35 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 04 Nov 2014 11:57:35 +0100 Subject: Trivial RFR: 8036616: [TESTBUG] Embedded: sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be launched with -XX:+UsePerfData In-Reply-To: <5458AF13.209@oracle.com> References: <5458AF13.209@oracle.com> Message-ID: <5458B11F.8020705@oracle.com> Looks good. -JB- On 11/04/2014 11:48 AM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8036616 > > webrev: inline below > > Trivial test modification contributed by Pavel Chistyakov. I've reviewed > it but would like a second review from serviceability please. I plan to > push via hs-rt forest. > > Thanks, > David > > > diff -r ef6ec39fd6bd test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java > --- a/test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java > +++ b/test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java > @@ -34,6 +34,7 @@ > * @bug 6672135 > * @summary setInterval() for local MonitoredHost and local MonitoredVm > * @author Tomas Hurka > + * @run main/othervm -XX:+UsePerfData CR6672135 > */ > public class CR6672135 { From jaroslav.bachorik at oracle.com Tue Nov 4 11:10:00 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 04 Nov 2014 12:10:00 +0100 Subject: [ping] Re: RFR 8058506: ThreadMXBeanStateTest throws exception In-Reply-To: <5458B0EE.7010909@oracle.com> References: <5444EE20.6090803@oracle.com> <54465F27.3080204@oracle.com> <54469C35.8090005@oracle.com> <5448CE39.704@oracle.com> <5449032D.5070208@oracle.com> <545776ED.2030307@oracle.com> <54587745.8060502@oracle.com> <5458A12B.2020205@oracle.com> <5458B0EE.7010909@oracle.com> Message-ID: <5458B408.3030305@oracle.com> On 11/04/2014 11:56 AM, David Holmes wrote: > On 4/11/2014 7:49 PM, Jaroslav Bachorik wrote: >> On 11/04/2014 07:50 AM, David Holmes wrote: >>> On 3/11/2014 10:37 PM, Jaroslav Bachorik wrote: >>>> May I have a (R)eviewer to take a look at this, please? >>>> >>>> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 >>> >>> I don't understand the need for the semaphore given you do: >>> >>> 116 thread.join(); >>> 117 System.out.println(thread.getLog()); >>> >>> If join() returns normally, such that you call getLog() then run() must >>> have completed and the semaphore has to be signalled. So the semaphore >>> is serving no purpose here that I can see. If you want to ensure >>> getLog() blocks until the thread has terminated then it could internally >>> do a join(). >> >> I prefer having the precondition of "getLog()" method enforced inside >> the ThreadStateController class and not to rely on the caller to do the >> right thing. >> >> I've replaced the semaphore with the plain thrd.join() call as suggested. > > Ok. But then the test doesn't need the join() any more. :) Sounds fair :) -JB- > > Seems okay though - Reviewed. > > Thanks, > David > >> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.02 >> >> -JB- >> >>> >>> David >>> ----- >>> >>> David >>> >>>> -JB- >>>> >>>> On 10/23/2014 03:31 PM, Erik Gahlin wrote: >>>>> Looks good! >>>>> >>>>> Erik >>>>> >>>>> Jaroslav Bachorik skrev 2014-10-23 11:45: >>>>>> On 10/21/2014 07:47 PM, Jaroslav Bachorik wrote: >>>>>>> On 10/21/2014 03:27 PM, Erik Gahlin wrote: >>>>>>>> Have you considered creating a LogMessage class that keeps the >>>>>>>> logCntr >>>>>>>> value and the log message, instead of putting the counter into the >>>>>>>> log >>>>>>>> string and parsing it. >>>>>>> >>>>>>> Yes. And didn't go that way in order to prevent creating a lot of >>>>>>> throwaway stringbuilder instances (the Formatter works that way) - >>>>>>> but >>>>>>> it might (almost certainly) be a premature optimization. I will >>>>>>> clean it >>>>>>> up and resubmit the request. >>>>>> >>>>>> http://cr.openjdk.java.net/~jbachorik/8058506/webrev.01 >>>>>> >>>>>> I moved the log collection logic to a separate class available in the >>>>>> testlib now. The code is much more concise now. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> Seems simpler and easier to understand. >>>>>>>> >>>>>>>> Erik >>>>>>>> >>>>>>>> Jaroslav Bachorik skrev 2014-10-20 13:12: >>>>>>>>> Please, review the following test change >>>>>>>>> >>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8058506 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8058506/webrev.00 >>>>>>>>> >>>>>>>>> The test fails intermittently due to the log printing blocking the >>>>>>>>> test thread from time to time, resulting in incorrect data >>>>>>>>> reported by >>>>>>>>> ThreadMXBean. >>>>>>>>> >>>>>>>>> The solution is to use per-thread non-blocking StringBuilders >>>>>>>>> (wrapped >>>>>>>>> in Formatter instances) and aggregate the log output only after >>>>>>>>> the >>>>>>>>> test is finished. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From albert.noll at oracle.com Tue Nov 4 13:01:05 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 04 Nov 2014 14:01:05 +0100 Subject: [9] RFR(S): 8062735: CodeCacheSweeperThread missing from SA Message-ID: <5458CE11.305@oracle.com> Hi, could I get reviews for this small patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8062735 Problem: The fix for JDK-8046809 added the CodeCacheSweeperThread, but did not add this new type to SA. Solution: Add type to SA. Testing: Failing test cases. Webrev: http://cr.openjdk.java.net/~anoll/8062735/webrev.00/ Many thanks, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Nov 4 19:57:54 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Nov 2014 11:57:54 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <5457E36A.3020800@oracle.com> References: <5457E36A.3020800@oracle.com> Message-ID: <54592FC2.7090406@oracle.com> Hi Jeremy and Coleen, I'm reviewing this too. We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. Thanks, Serguei On 11/3/14 12:19 PM, Coleen Phillimore wrote: > > Hi Jeremy, > > I reviewed your new code and it looks fine. I had one comment in > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html > > > The name "need_to_resolve" doesn't make sense when reading this code. > Isn't it more like "need_to_ensure_space" ? I think method resolution > with the other name, which it doesn't do. > > I was trying to find a way to make this new code not appear twice > (maybe with a local jvmtiEnv function get_jmethodID(m) - instanceK_h > is m->method_holder()). Agreed on the above. > > Also, I was trying to figure out if the new class in utilities called > chunkedList.hpp could be used to store jmethodIDs, since the data > structures are similar. There is still more things in JNIMethodBlock > has to do so I think a specialized structure is still needed (which is > why I originally wrote it to be very simple). I'm not sure if the > comment above it still applies. Maybe only the first and third > sentences. Can you rewrite the comment slightly? > > Your other comments in the changes are good. > > I can't completely answer your question about reusing free_methods - > but if a jmethodID is created provisionally in > InstanceKlass::get_jmethod_id and not needed because it loses the race > in the method id cache, it's never handed back to native code, so it's > safe to reuse. This is different than jmethodIDs for methods that are > unloaded. They are cleared and never reused. At least that's my > reading of this caching code but it's pretty complicated stuff. > > I've also run our nsk and jck vm/jvmti on this change and they all > passed. I'd be happy to sponsor it with these suggested changes and > it needs another reviewer. > > Thanks for diagnosing and fixing this problem! > Coleen > > > On 10/30/2014 01:02 PM, Jeremy Manson wrote: >> There's a significant regression in the speed of JVMTI >> GetClassMethods in >> JDK8. I've tracked this down to allocation of jmethodids in a tight >> loop. >> The issue can be addressed by preallocating enough space for all of the >> jmethodids when starting the operation and not iterating over all of the >> existing jmethodids when you allocate a new one. >> >> A patch is here: >> >> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >> >> A reproducible test case can be found here: >> >> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >> >> It's a benchmark, though: I have no idea how to turn it into a test. >> >> For whoever reviews it: can you explain to me why it is okay that >> this code >> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a >> lot of >> problems stemming from accidental reuse. >> >> Jeremy > From jeremymanson at google.com Tue Nov 4 19:58:26 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 4 Nov 2014 11:58:26 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <5457E36A.3020800@oracle.com> References: <5457E36A.3020800@oracle.com> Message-ID: Thanks for taking a look, Coleen! On Mon, Nov 3, 2014 at 12:19 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > Hi Jeremy, > > I reviewed your new code and it looks fine. I had one comment in > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/ > share/vm/prims/jvmtiEnv.cpp.udiff.html > > The name "need_to_resolve" doesn't make sense when reading this code. > Isn't it more like "need_to_ensure_space" ? I think method resolution with > the other name, which it doesn't do. > Hmmm... it is there to tell you that there are jmethodids for that class that haven't been instantiated. Is it all right if I change it to "jmethodids_found" (and reverse the sense of it)? > I was trying to find a way to make this new code not appear twice (maybe > with a local jvmtiEnv function get_jmethodID(m) - instanceK_h is > m->method_holder()). > You know, I initially did that, but this file is parsed with some weird XSL setup that doesn't allow methods other than the ones that map directly to the JVMTI calls. Also, I was trying to figure out if the new class in utilities called > chunkedList.hpp could be used to store jmethodIDs, since the data > structures are similar. There is still more things in JNIMethodBlock has > to do so I think a specialized structure is still needed (which is why I > originally wrote it to be very simple). I'm not sure if the comment above > it still applies. Maybe only the first and third sentences. Can you > rewrite the comment slightly? > chunkedList wouldn't work as is, because it doesn't let you parameterize the bucket size, but it could probably be made to work (in the same way I made this one work). It's also an oddly bare-bones class - I'm not sure why it doesn't have contains and insert methods and so on. I'm not in love with the idea of doing it, because a) it would complicate my backport and b) I don't really have a lot of time to do hotspot refactoring, but if you think it should happen, I can make it happen (perhaps not in a timely way :) ). As for the comment, I'll eliminate all but the first and third sentences. > Your other comments in the changes are good. > > I can't completely answer your question about reusing free_methods - but > if a jmethodID is created provisionally in InstanceKlass::get_jmethod_id > and not needed because it loses the race in the method id cache, it's never > handed back to native code, so it's safe to reuse. This is different than > jmethodIDs for methods that are unloaded. They are cleared and never > reused. At least that's my reading of this caching code but it's pretty > complicated stuff. > Ah, I see. Thanks. > I've also run our nsk and jck vm/jvmti on this change and they all > passed. I'd be happy to sponsor it with these suggested changes and it > needs another reviewer. > I've cc'd Chuck Rasbold, who has already reviewed it internally and given it the thumbs-up. I'm sure he would be happy to do so publicly, too. Thanks for diagnosing and fixing this problem! Happy to do it! And so are the programs that use my JVMTI! Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Tue Nov 4 19:59:33 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 4 Nov 2014 11:59:33 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <54592FC2.7090406@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> Message-ID: Weird coincidence. On Tue, Nov 4, 2014 at 11:57 AM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jeremy and Coleen, > > I'm reviewing this too. > We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. > > Thanks, > Serguei > > On 11/3/14 12:19 PM, Coleen Phillimore wrote: > >> >> Hi Jeremy, >> >> I reviewed your new code and it looks fine. I had one comment in >> >> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/ >> share/vm/prims/jvmtiEnv.cpp.udiff.html >> >> The name "need_to_resolve" doesn't make sense when reading this code. >> Isn't it more like "need_to_ensure_space" ? I think method resolution with >> the other name, which it doesn't do. >> >> I was trying to find a way to make this new code not appear twice (maybe >> with a local jvmtiEnv function get_jmethodID(m) - instanceK_h is >> m->method_holder()). >> > > Agreed on the above. > Per my message to Coleen, you can't add methods to this file. All other possibilities seemed like overkill, but other suggestions welcome. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Nov 4 20:40:33 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 04 Nov 2014 15:40:33 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: <5457E36A.3020800@oracle.com> Message-ID: <545939C1.6040703@oracle.com> Hi Jeremy, Having Chuck reply publicly to the review would be good. We miss seeing his emails :) On 11/04/2014 02:58 PM, Jeremy Manson wrote: > > Thanks for taking a look, Coleen! > > On Mon, Nov 3, 2014 at 12:19 PM, Coleen Phillimore > > > wrote: > > > Hi Jeremy, > > I reviewed your new code and it looks fine. I had one comment in > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html > > > The name "need_to_resolve" doesn't make sense when reading this > code. Isn't it more like "need_to_ensure_space" ? I think method > resolution with the other name, which it doesn't do. > > > Hmmm... it is there to tell you that there are jmethodids for that > class that haven't been instantiated. Is it all right if I change it > to "jmethodids_found" (and reverse the sense of it)? Okay, yes jmethodids_found makes more sense to me in this context. > I was trying to find a way to make this new code not appear twice > (maybe with a local jvmtiEnv function get_jmethodID(m) - > instanceK_h is m->method_holder()). > > > You know, I initially did that, but this file is parsed with some > weird XSL setup that doesn't allow methods other than the ones that > map directly to the JVMTI calls. Oh, yes. You are right. The code is fine then. It's not too much duplicated. > > Also, I was trying to figure out if the new class in utilities > called chunkedList.hpp could be used to store jmethodIDs, since > the data structures are similar. There is still more things in > JNIMethodBlock has to do so I think a specialized structure is > still needed (which is why I originally wrote it to be very > simple). I'm not sure if the comment above it still applies. > Maybe only the first and third sentences. Can you rewrite the > comment slightly? > > > chunkedList wouldn't work as is, because it doesn't let you > parameterize the bucket size, but it could probably be made to work > (in the same way I made this one work). It's also an oddly bare-bones > class - I'm not sure why it doesn't have contains and insert methods > and so on. > > I'm not in love with the idea of doing it, because a) it would > complicate my backport and b) I don't really have a lot of time to do > hotspot refactoring, but if you think it should happen, I can make it > happen (perhaps not in a timely way :) ). > No, I don't think you should do this. It was a general comment that this utility class is available for such things but has only one use so far. > As for the comment, I'll eliminate all but the first and third sentences. Thanks! > Your other comments in the changes are good. > > I can't completely answer your question about reusing free_methods > - but if a jmethodID is created provisionally in > InstanceKlass::get_jmethod_id and not needed because it loses the > race in the method id cache, it's never handed back to native > code, so it's safe to reuse. This is different than jmethodIDs > for methods that are unloaded. They are cleared and never reused. > At least that's my reading of this caching code but it's pretty > complicated stuff. > > > Ah, I see. Thanks. > > I've also run our nsk and jck vm/jvmti on this change and they all > passed. I'd be happy to sponsor it with these suggested changes > and it needs another reviewer. > > > I've cc'd Chuck Rasbold, who has already reviewed it internally and > given it the thumbs-up. I'm sure he would be happy to do so publicly, > too. > > Thanks for diagnosing and fixing this problem! > > > Happy to do it! And so are the programs that use my JVMTI! > Thank you! If you commit and send me the result of hg export your changeset, then I'll get your comments also and won't get the chance to mess up and not use commit -u jmanson. Coleen > Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Nov 4 20:43:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 04 Nov 2014 15:43:02 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <54592FC2.7090406@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> Message-ID: <54593A56.4050603@oracle.com> On 11/04/2014 02:57 PM, serguei.spitsyn at oracle.com wrote: > Hi Jeremy and Coleen, > > I'm reviewing this too. > We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. Hi Serguei, I ran all of vm.quick.testlist on this which includes jvmti, jdi tests. I'll run jtreg jdi tests too (where are they?) Thanks, Coleen > > Thanks, > Serguei > > On 11/3/14 12:19 PM, Coleen Phillimore wrote: >> >> Hi Jeremy, >> >> I reviewed your new code and it looks fine. I had one comment in >> >> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html >> >> >> The name "need_to_resolve" doesn't make sense when reading this >> code. Isn't it more like "need_to_ensure_space" ? I think method >> resolution with the other name, which it doesn't do. >> >> I was trying to find a way to make this new code not appear twice >> (maybe with a local jvmtiEnv function get_jmethodID(m) - instanceK_h >> is m->method_holder()). > > Agreed on the above. > >> >> Also, I was trying to figure out if the new class in utilities called >> chunkedList.hpp could be used to store jmethodIDs, since the data >> structures are similar. There is still more things in JNIMethodBlock >> has to do so I think a specialized structure is still needed (which >> is why I originally wrote it to be very simple). I'm not sure if the >> comment above it still applies. Maybe only the first and third >> sentences. Can you rewrite the comment slightly? >> >> Your other comments in the changes are good. >> >> I can't completely answer your question about reusing free_methods - >> but if a jmethodID is created provisionally in >> InstanceKlass::get_jmethod_id and not needed because it loses the >> race in the method id cache, it's never handed back to native code, >> so it's safe to reuse. This is different than jmethodIDs for methods >> that are unloaded. They are cleared and never reused. At least >> that's my reading of this caching code but it's pretty complicated >> stuff. >> >> I've also run our nsk and jck vm/jvmti on this change and they all >> passed. I'd be happy to sponsor it with these suggested changes and >> it needs another reviewer. >> >> Thanks for diagnosing and fixing this problem! >> Coleen >> >> >> On 10/30/2014 01:02 PM, Jeremy Manson wrote: >>> There's a significant regression in the speed of JVMTI >>> GetClassMethods in >>> JDK8. I've tracked this down to allocation of jmethodids in a tight >>> loop. >>> The issue can be addressed by preallocating enough space for all of the >>> jmethodids when starting the operation and not iterating over all of >>> the >>> existing jmethodids when you allocate a new one. >>> >>> A patch is here: >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >>> >>> A reproducible test case can be found here: >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >>> >>> It's a benchmark, though: I have no idea how to turn it into a test. >>> >>> For whoever reviews it: can you explain to me why it is okay that >>> this code >>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a >>> lot of >>> problems stemming from accidental reuse. >>> >>> Jeremy >> > From jeremymanson at google.com Tue Nov 4 21:05:37 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 4 Nov 2014 13:05:37 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <54593A56.4050603@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <54593A56.4050603@oracle.com> Message-ID: FWIW, all of the JDK8 jtreg tests passed. On Tue, Nov 4, 2014 at 12:43 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > On 11/04/2014 02:57 PM, serguei.spitsyn at oracle.com wrote: > >> Hi Jeremy and Coleen, >> >> I'm reviewing this too. >> We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. >> > > Hi Serguei, I ran all of vm.quick.testlist on this which includes jvmti, > jdi tests. I'll run jtreg jdi tests too (where are they?) > > Thanks, > Coleen > > > >> Thanks, >> Serguei >> >> On 11/3/14 12:19 PM, Coleen Phillimore wrote: >> >>> >>> Hi Jeremy, >>> >>> I reviewed your new code and it looks fine. I had one comment in >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/ >>> share/vm/prims/jvmtiEnv.cpp.udiff.html >>> >>> The name "need_to_resolve" doesn't make sense when reading this code. >>> Isn't it more like "need_to_ensure_space" ? I think method resolution with >>> the other name, which it doesn't do. >>> >>> I was trying to find a way to make this new code not appear twice (maybe >>> with a local jvmtiEnv function get_jmethodID(m) - instanceK_h is >>> m->method_holder()). >>> >> >> Agreed on the above. >> >> >>> Also, I was trying to figure out if the new class in utilities called >>> chunkedList.hpp could be used to store jmethodIDs, since the data >>> structures are similar. There is still more things in JNIMethodBlock has >>> to do so I think a specialized structure is still needed (which is why I >>> originally wrote it to be very simple). I'm not sure if the comment above >>> it still applies. Maybe only the first and third sentences. Can you >>> rewrite the comment slightly? >>> >>> Your other comments in the changes are good. >>> >>> I can't completely answer your question about reusing free_methods - but >>> if a jmethodID is created provisionally in InstanceKlass::get_jmethod_id >>> and not needed because it loses the race in the method id cache, it's never >>> handed back to native code, so it's safe to reuse. This is different than >>> jmethodIDs for methods that are unloaded. They are cleared and never >>> reused. At least that's my reading of this caching code but it's pretty >>> complicated stuff. >>> >>> I've also run our nsk and jck vm/jvmti on this change and they all >>> passed. I'd be happy to sponsor it with these suggested changes and it >>> needs another reviewer. >>> >>> Thanks for diagnosing and fixing this problem! >>> Coleen >>> >>> >>> On 10/30/2014 01:02 PM, Jeremy Manson wrote: >>> >>>> There's a significant regression in the speed of JVMTI GetClassMethods >>>> in >>>> JDK8. I've tracked this down to allocation of jmethodids in a tight >>>> loop. >>>> The issue can be addressed by preallocating enough space for all of the >>>> jmethodids when starting the operation and not iterating over all of the >>>> existing jmethodids when you allocate a new one. >>>> >>>> A patch is here: >>>> >>>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >>>> >>>> A reproducible test case can be found here: >>>> >>>> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >>>> >>>> It's a benchmark, though: I have no idea how to turn it into a test. >>>> >>>> For whoever reviews it: can you explain to me why it is okay that this >>>> code >>>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a lot >>>> of >>>> problems stemming from accidental reuse. >>>> >>>> Jeremy >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Nov 4 21:07:55 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Nov 2014 13:07:55 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <54593A56.4050603@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <54593A56.4050603@oracle.com> Message-ID: <5459402B.5030304@oracle.com> On 11/4/14 12:43 PM, Coleen Phillimore wrote: > > On 11/04/2014 02:57 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jeremy and Coleen, >> >> I'm reviewing this too. >> We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. > > Hi Serguei, I ran all of vm.quick.testlist on this which includes > jvmti, jdi tests. I'll run jtreg jdi tests too (where are they?) Hi Coleen, It is more safe to run the nsk.jvmti.testlist and nsk.jdi.testlist instead of the vm.quick.testlist. The jtreg jdi tests are in the /jdk/test/com/sun/jdi folder. Thanks, Serguei > > Thanks, > Coleen > >> >> Thanks, >> Serguei >> >> On 11/3/14 12:19 PM, Coleen Phillimore wrote: >>> >>> Hi Jeremy, >>> >>> I reviewed your new code and it looks fine. I had one comment in >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html >>> >>> >>> The name "need_to_resolve" doesn't make sense when reading this >>> code. Isn't it more like "need_to_ensure_space" ? I think method >>> resolution with the other name, which it doesn't do. >>> >>> I was trying to find a way to make this new code not appear twice >>> (maybe with a local jvmtiEnv function get_jmethodID(m) - instanceK_h >>> is m->method_holder()). >> >> Agreed on the above. >> >>> >>> Also, I was trying to figure out if the new class in utilities >>> called chunkedList.hpp could be used to store jmethodIDs, since the >>> data structures are similar. There is still more things in >>> JNIMethodBlock has to do so I think a specialized structure is still >>> needed (which is why I originally wrote it to be very simple). I'm >>> not sure if the comment above it still applies. Maybe only the first >>> and third sentences. Can you rewrite the comment slightly? >>> >>> Your other comments in the changes are good. >>> >>> I can't completely answer your question about reusing free_methods - >>> but if a jmethodID is created provisionally in >>> InstanceKlass::get_jmethod_id and not needed because it loses the >>> race in the method id cache, it's never handed back to native code, >>> so it's safe to reuse. This is different than jmethodIDs for >>> methods that are unloaded. They are cleared and never reused. At >>> least that's my reading of this caching code but it's pretty >>> complicated stuff. >>> >>> I've also run our nsk and jck vm/jvmti on this change and they all >>> passed. I'd be happy to sponsor it with these suggested changes and >>> it needs another reviewer. >>> >>> Thanks for diagnosing and fixing this problem! >>> Coleen >>> >>> >>> On 10/30/2014 01:02 PM, Jeremy Manson wrote: >>>> There's a significant regression in the speed of JVMTI >>>> GetClassMethods in >>>> JDK8. I've tracked this down to allocation of jmethodids in a tight >>>> loop. >>>> The issue can be addressed by preallocating enough space for all of >>>> the >>>> jmethodids when starting the operation and not iterating over all >>>> of the >>>> existing jmethodids when you allocate a new one. >>>> >>>> A patch is here: >>>> >>>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >>>> >>>> A reproducible test case can be found here: >>>> >>>> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >>>> >>>> It's a benchmark, though: I have no idea how to turn it into a test. >>>> >>>> For whoever reviews it: can you explain to me why it is okay that >>>> this code >>>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a >>>> lot of >>>> problems stemming from accidental reuse. >>>> >>>> Jeremy >>> >> > From serguei.spitsyn at oracle.com Tue Nov 4 22:15:56 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Nov 2014 14:15:56 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <54592FC2.7090406@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> Message-ID: <5459501C.4040807@oracle.com> Jeremy and Coleen, Thank you for taking care about this bug! The fix looks good to me. I do not see any issues. Coleen, Please, let me know if you need any help with testing or anything else. Thanks, Serguei On 11/4/14 11:57 AM, serguei.spitsyn at oracle.com wrote: > Hi Jeremy and Coleen, > > I'm reviewing this too. > We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. > > Thanks, > Serguei > > On 11/3/14 12:19 PM, Coleen Phillimore wrote: >> >> Hi Jeremy, >> >> I reviewed your new code and it looks fine. I had one comment in >> >> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html >> >> >> The name "need_to_resolve" doesn't make sense when reading this >> code. Isn't it more like "need_to_ensure_space" ? I think method >> resolution with the other name, which it doesn't do. >> >> I was trying to find a way to make this new code not appear twice >> (maybe with a local jvmtiEnv function get_jmethodID(m) - instanceK_h >> is m->method_holder()). > > Agreed on the above. > >> >> Also, I was trying to figure out if the new class in utilities called >> chunkedList.hpp could be used to store jmethodIDs, since the data >> structures are similar. There is still more things in JNIMethodBlock >> has to do so I think a specialized structure is still needed (which >> is why I originally wrote it to be very simple). I'm not sure if the >> comment above it still applies. Maybe only the first and third >> sentences. Can you rewrite the comment slightly? >> >> Your other comments in the changes are good. >> >> I can't completely answer your question about reusing free_methods - >> but if a jmethodID is created provisionally in >> InstanceKlass::get_jmethod_id and not needed because it loses the >> race in the method id cache, it's never handed back to native code, >> so it's safe to reuse. This is different than jmethodIDs for methods >> that are unloaded. They are cleared and never reused. At least >> that's my reading of this caching code but it's pretty complicated >> stuff. >> >> I've also run our nsk and jck vm/jvmti on this change and they all >> passed. I'd be happy to sponsor it with these suggested changes and >> it needs another reviewer. >> >> Thanks for diagnosing and fixing this problem! >> Coleen >> >> >> On 10/30/2014 01:02 PM, Jeremy Manson wrote: >>> There's a significant regression in the speed of JVMTI >>> GetClassMethods in >>> JDK8. I've tracked this down to allocation of jmethodids in a tight >>> loop. >>> The issue can be addressed by preallocating enough space for all of the >>> jmethodids when starting the operation and not iterating over all of >>> the >>> existing jmethodids when you allocate a new one. >>> >>> A patch is here: >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >>> >>> A reproducible test case can be found here: >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >>> >>> It's a benchmark, though: I have no idea how to turn it into a test. >>> >>> For whoever reviews it: can you explain to me why it is okay that >>> this code >>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a >>> lot of >>> problems stemming from accidental reuse. >>> >>> Jeremy >> > From serguei.spitsyn at oracle.com Tue Nov 4 22:32:56 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Nov 2014 14:32:56 -0800 Subject: [9] RFR(S): 8062735: CodeCacheSweeperThread missing from SA In-Reply-To: <5458CE11.305@oracle.com> References: <5458CE11.305@oracle.com> Message-ID: <54595418.6060300@oracle.com> Hi Albert, The fix looks good. Thanks, Serguei On 11/4/14 5:01 AM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8062735 > > Problem: > The fix for JDK-8046809 added the CodeCacheSweeperThread, but did not > add this new type to SA. > > Solution: > Add type to SA. > > Testing: > Failing test cases. > > Webrev: > http://cr.openjdk.java.net/~anoll/8062735/webrev.00/ > > Many thanks, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Nov 4 23:08:27 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Nov 2014 09:08:27 +1000 Subject: Trivial RFR: 8036616: [TESTBUG] Embedded: sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be launched with -XX:+UsePerfData In-Reply-To: <5458B11F.8020705@oracle.com> References: <5458AF13.209@oracle.com> <5458B11F.8020705@oracle.com> Message-ID: <54595C6B.20900@oracle.com> Thanks Jaroslav! David On 4/11/2014 8:57 PM, Jaroslav Bachorik wrote: > Looks good. > > -JB- > > On 11/04/2014 11:48 AM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8036616 >> >> webrev: inline below >> >> Trivial test modification contributed by Pavel Chistyakov. I've reviewed >> it but would like a second review from serviceability please. I plan to >> push via hs-rt forest. >> >> Thanks, >> David >> >> >> diff -r ef6ec39fd6bd test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java >> --- a/test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java >> +++ b/test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java >> @@ -34,6 +34,7 @@ >> * @bug 6672135 >> * @summary setInterval() for local MonitoredHost and local MonitoredVm >> * @author Tomas Hurka >> + * @run main/othervm -XX:+UsePerfData CR6672135 >> */ >> public class CR6672135 { > From rasbold at google.com Tue Nov 4 21:11:32 2014 From: rasbold at google.com (Chuck Rasbold) Date: Tue, 4 Nov 2014 13:11:32 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <54593A56.4050603@oracle.com> Message-ID: Jeremy's webrev looks good to me. -- Chuck On Tue, Nov 4, 2014 at 1:05 PM, Jeremy Manson wrote: > FWIW, all of the JDK8 jtreg tests passed. > > On Tue, Nov 4, 2014 at 12:43 PM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> On 11/04/2014 02:57 PM, serguei.spitsyn at oracle.com wrote: >> >>> Hi Jeremy and Coleen, >>> >>> I'm reviewing this too. >>> We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. >>> >> >> Hi Serguei, I ran all of vm.quick.testlist on this which includes jvmti, >> jdi tests. I'll run jtreg jdi tests too (where are they?) >> >> Thanks, >> Coleen >> >> >> >>> Thanks, >>> Serguei >>> >>> On 11/3/14 12:19 PM, Coleen Phillimore wrote: >>> >>>> >>>> Hi Jeremy, >>>> >>>> I reviewed your new code and it looks fine. I had one comment in >>>> >>>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/ >>>> share/vm/prims/jvmtiEnv.cpp.udiff.html >>>> >>>> The name "need_to_resolve" doesn't make sense when reading this code. >>>> Isn't it more like "need_to_ensure_space" ? I think method resolution with >>>> the other name, which it doesn't do. >>>> >>>> I was trying to find a way to make this new code not appear twice >>>> (maybe with a local jvmtiEnv function get_jmethodID(m) - instanceK_h is >>>> m->method_holder()). >>>> >>> >>> Agreed on the above. >>> >>> >>>> Also, I was trying to figure out if the new class in utilities called >>>> chunkedList.hpp could be used to store jmethodIDs, since the data >>>> structures are similar. There is still more things in JNIMethodBlock has >>>> to do so I think a specialized structure is still needed (which is why I >>>> originally wrote it to be very simple). I'm not sure if the comment above >>>> it still applies. Maybe only the first and third sentences. Can you >>>> rewrite the comment slightly? >>>> >>>> Your other comments in the changes are good. >>>> >>>> I can't completely answer your question about reusing free_methods - >>>> but if a jmethodID is created provisionally in >>>> InstanceKlass::get_jmethod_id and not needed because it loses the race in >>>> the method id cache, it's never handed back to native code, so it's safe to >>>> reuse. This is different than jmethodIDs for methods that are unloaded. >>>> They are cleared and never reused. At least that's my reading of this >>>> caching code but it's pretty complicated stuff. >>>> >>>> I've also run our nsk and jck vm/jvmti on this change and they all >>>> passed. I'd be happy to sponsor it with these suggested changes and it >>>> needs another reviewer. >>>> >>>> Thanks for diagnosing and fixing this problem! >>>> Coleen >>>> >>>> >>>> On 10/30/2014 01:02 PM, Jeremy Manson wrote: >>>> >>>>> There's a significant regression in the speed of JVMTI GetClassMethods >>>>> in >>>>> JDK8. I've tracked this down to allocation of jmethodids in a tight >>>>> loop. >>>>> The issue can be addressed by preallocating enough space for all of the >>>>> jmethodids when starting the operation and not iterating over all of >>>>> the >>>>> existing jmethodids when you allocate a new one. >>>>> >>>>> A patch is here: >>>>> >>>>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >>>>> >>>>> A reproducible test case can be found here: >>>>> >>>>> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >>>>> >>>>> It's a benchmark, though: I have no idea how to turn it into a test. >>>>> >>>>> For whoever reviews it: can you explain to me why it is okay that this >>>>> code >>>>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a lot >>>>> of >>>>> problems stemming from accidental reuse. >>>>> >>>>> Jeremy >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Nov 5 00:09:38 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Nov 2014 10:09:38 +1000 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545729A3.7090301@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> Message-ID: <54596AC2.6050502@oracle.com> Hi Serguei, On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: > On 11/2/14 8:58 PM, David Holmes wrote: >> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Thank you for good finding. This approach looks much better for me. >>> >>> The fix looks good. >>> >>> Is it necessary to release vmDeathLock locks at >>> eventHandler.c:1244 before call >>> >>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >> >> I agree this looks necessary, or at least more clean (if things are >> failing we really don't know what is happening). > > Agreed (replied to Dmitry). > >> >> More generally I'm concerned about whether any of the code paths taken >> while holding the new lock can result in deadlock - in particular with >> regard to the resumeLock ? > > The cbVMDeath() function never holds both vmDeathLock and resumeLock at > the same time, > so there is no chance for a deadlock that involves both these locks. > > Two more locks used in the cbVMDeath() are the callbackBlock and > callbackLock. > These two locks look completely unrelated to the debugLoop_run(). > > The debugLoop_run() function also uses the cmdQueueLock. > The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at the > same time. > > So that I do not see any potential to introduce new deadlock with the > vmDeathLock. > > However, it is still easy to overlook something here. > Please, let me know if you see any danger. I was mainly concerned about what might happen in the call chain for threadControl_resumeAll() (it certainly sounds like it might need to use a resumeLock :) ). I see direct use of the threadLock and indirectly the eventHandler lock; but there are further call paths I did not explore. Wish there was an easy way to determine the transitive closure of all locks used from a given call. Thanks, David > Thanks, > Serguei > >> >> David >> >>> -Dmitry >>> >>> >>> >>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>> >>>> It is 3-rd round of review for: >>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>> >>>> New webrev: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>> >>>> >>>> >>>> Summary >>>> >>>> For failing scenario, please, refer to the 1-st round RFR below. >>>> >>>> I've found what is missed in the jdwp agent shutdown and decided to >>>> switch from a workaround to a real fix. >>>> >>>> The agent VM_DEATH callback sets the gdata field: gdata->vmDead = 1. >>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>> >>>> 165 } else if (gdata->vmDead && >>>> 166 ((cmd->cmdSet) != >>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>> 167 /* Protect the VM from calls while dead. >>>> 168 * VirtualMachine cmdSet quietly ignores some >>>> cmds >>>> 169 * after VM death, so, it sends it's own errors. >>>> 170 */ >>>> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >>>> >>>> >>>> However, the guard above does not help much if the VM_DEATH event >>>> happens in the middle of a command execution. >>>> There is a lack of synchronization here. >>>> >>>> The fix introduces new lock (vmDeathLock) which does not allow to >>>> execute the commands >>>> and the VM_DEATH event callback concurrently. >>>> It should work well for any function that is used in >>>> implementation of >>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>> >>>> >>>> Testing: >>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>> The updated webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>> >>>>> >>>>> >>>>> The changes are: >>>>> - added a comment recommended by Staffan >>>>> - removed the ignore_wrong_phase() call from function >>>>> classSignature() >>>>> >>>>> The classSignature() function is called in 16 places. >>>>> Most of them do not tolerate the NULL in place of returned signature >>>>> and will crash. >>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>> return to this >>>>> issue after gaining experience with more failure cases that are still >>>>> expected. >>>>> The failure with the classSignature() involved was observed only once >>>>> in the nightly >>>>> and should be extremely rare reproducible. >>>>> I'll file a placeholder bug if necessary. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The failing scenario: >>>>>> The debugger and the debuggee are well aware a VM shutdown has >>>>>> been started in the target process. >>>>>> The debugger at this point is not expected to send any commands >>>>>> to the JDWP agent. >>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>> (debuggee side) >>>>>> are not in sync with the consumer layers. >>>>>> >>>>>> One reason is because the test debugger does not invoke the JDI >>>>>> method VirtualMachine.dispose(). >>>>>> Another reason is that the Debugger and the debuggee processes >>>>>> are uneasy to sync in general. >>>>>> >>>>>> As a result the following steps are possible: >>>>>> - The test debugger sends a 'quit' command to the test >>>>>> debuggee >>>>>> - The debuggee is normally exiting >>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>> anonymous class unload event >>>>>> - The JDI InternalEventHandler thread handles the >>>>>> ClassUnloadEvent event >>>>>> - The InternalEventHandler wants to uncache the matching >>>>>> reference type. >>>>>> If there is more than one class with the same host class >>>>>> signature, it can't distinguish them, >>>>>> and so, deletes all references and re-retrieves them again >>>>>> (see tracing below): >>>>>> MY_TRACE: JDI: >>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>> - The jdwp backend debugLoop_run() gets the command from JDI >>>>>> and calls the functions >>>>>> classesForSignature() and classStatus() recursively. >>>>>> - The classStatus() makes a call to the JVMTI >>>>>> GetClassStatus() >>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>> - As a result the jdwp backend reports the JVMTI error to the >>>>>> JDI, and so, the test fails >>>>>> >>>>>> For details, see the analysis in bug report closed as a dup of >>>>>> the bug 6988950: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>> >>>>>> Some similar cases can be found in the two bug reports (6988950 >>>>>> and 8024865) describing this issue. >>>>>> >>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE error >>>>>> as it is normal at the VM shutdown. >>>>>> The original jdwp backend implementation had a similar approach >>>>>> for the raw monitor functions. >>>>>> Threy use the ignore_vm_death() to workaround the >>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>> For reference, please, see the file: src/share/back/util.c >>>>>> >>>>>> >>>>>> Testing: >>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>> tests >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >>> > From jeremymanson at google.com Wed Nov 5 01:52:50 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 4 Nov 2014 17:52:50 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <5459501C.4040807@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> Message-ID: Updated patch here: http://cr.openjdk.java.net/~jmanson/8062116/webrev.01/ Jeremy On Tue, Nov 4, 2014 at 2:15 PM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Jeremy and Coleen, > > Thank you for taking care about this bug! > > The fix looks good to me. > I do not see any issues. > > Coleen, > > Please, let me know if you need any help with testing or anything else. > > Thanks, > Serguei > > > On 11/4/14 11:57 AM, serguei.spitsyn at oracle.com wrote: > >> Hi Jeremy and Coleen, >> >> I'm reviewing this too. >> We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. >> >> Thanks, >> Serguei >> >> On 11/3/14 12:19 PM, Coleen Phillimore wrote: >> >>> >>> Hi Jeremy, >>> >>> I reviewed your new code and it looks fine. I had one comment in >>> >>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/ >>> share/vm/prims/jvmtiEnv.cpp.udiff.html >>> >>> The name "need_to_resolve" doesn't make sense when reading this code. >>> Isn't it more like "need_to_ensure_space" ? I think method resolution with >>> the other name, which it doesn't do. >>> >>> I was trying to find a way to make this new code not appear twice (maybe >>> with a local jvmtiEnv function get_jmethodID(m) - instanceK_h is >>> m->method_holder()). >>> >> >> Agreed on the above. >> >> >>> Also, I was trying to figure out if the new class in utilities called >>> chunkedList.hpp could be used to store jmethodIDs, since the data >>> structures are similar. There is still more things in JNIMethodBlock has >>> to do so I think a specialized structure is still needed (which is why I >>> originally wrote it to be very simple). I'm not sure if the comment above >>> it still applies. Maybe only the first and third sentences. Can you >>> rewrite the comment slightly? >>> >>> Your other comments in the changes are good. >>> >>> I can't completely answer your question about reusing free_methods - but >>> if a jmethodID is created provisionally in InstanceKlass::get_jmethod_id >>> and not needed because it loses the race in the method id cache, it's never >>> handed back to native code, so it's safe to reuse. This is different than >>> jmethodIDs for methods that are unloaded. They are cleared and never >>> reused. At least that's my reading of this caching code but it's pretty >>> complicated stuff. >>> >>> I've also run our nsk and jck vm/jvmti on this change and they all >>> passed. I'd be happy to sponsor it with these suggested changes and it >>> needs another reviewer. >>> >>> Thanks for diagnosing and fixing this problem! >>> Coleen >>> >>> >>> On 10/30/2014 01:02 PM, Jeremy Manson wrote: >>> >>>> There's a significant regression in the speed of JVMTI GetClassMethods >>>> in >>>> JDK8. I've tracked this down to allocation of jmethodids in a tight >>>> loop. >>>> The issue can be addressed by preallocating enough space for all of the >>>> jmethodids when starting the operation and not iterating over all of the >>>> existing jmethodids when you allocate a new one. >>>> >>>> A patch is here: >>>> >>>> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >>>> >>>> A reproducible test case can be found here: >>>> >>>> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >>>> >>>> It's a benchmark, though: I have no idea how to turn it into a test. >>>> >>>> For whoever reviews it: can you explain to me why it is okay that this >>>> code >>>> reuses jmethodIDs (in JNIMethodBlock::add_method? I can imagine a lot >>>> of >>>> problems stemming from accidental reuse. >>>> >>>> Jeremy >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Nov 5 04:56:27 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Nov 2014 20:56:27 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> Message-ID: <5459ADFB.4090808@oracle.com> The fix looks good in general. src/share/vm/oops/method.cpp 1785 bool contains(Method** m) { 1786 if (m == NULL) return false; 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { *1789 ptrdiff_t idx = m - b->_methods;** **1790 if (b->_methods + idx == m) {** 1791 return true; 1792 }* 1793 } 1794 } 1795 return false; // not found 1796 } Just noticed that the lines 1789-1792 can be replaced with one liner: * return true;* It is because the condition *(b->_methods + idx == m)* is always true. :) Also, should we check the condition: **m != _free_method*** ? What about the following ?: * return (****m != _free_method***);* Thanks, Serguei On 11/4/14 5:52 PM, Jeremy Manson wrote: > Updated patch here: > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.01/ > > > Jeremy > > On Tue, Nov 4, 2014 at 2:15 PM, serguei.spitsyn at oracle.com > > wrote: > > Jeremy and Coleen, > > Thank you for taking care about this bug! > > The fix looks good to me. > I do not see any issues. > > Coleen, > > Please, let me know if you need any help with testing or anything > else. > > Thanks, > Serguei > > > On 11/4/14 11:57 AM, serguei.spitsyn at oracle.com > wrote: > > Hi Jeremy and Coleen, > > I'm reviewing this too. > We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. > > Thanks, > Serguei > > On 11/3/14 12:19 PM, Coleen Phillimore wrote: > > > Hi Jeremy, > > I reviewed your new code and it looks fine. I had one > comment in > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html > > > > The name "need_to_resolve" doesn't make sense when reading > this code. Isn't it more like "need_to_ensure_space" ? I > think method resolution with the other name, which it > doesn't do. > > I was trying to find a way to make this new code not > appear twice (maybe with a local jvmtiEnv function > get_jmethodID(m) - instanceK_h is m->method_holder()). > > > Agreed on the above. > > > Also, I was trying to figure out if the new class in > utilities called chunkedList.hpp could be used to store > jmethodIDs, since the data structures are similar. There > is still more things in JNIMethodBlock has to do so I > think a specialized structure is still needed (which is > why I originally wrote it to be very simple). I'm not > sure if the comment above it still applies. Maybe only the > first and third sentences. Can you rewrite the comment > slightly? > > Your other comments in the changes are good. > > I can't completely answer your question about reusing > free_methods - but if a jmethodID is created provisionally > in InstanceKlass::get_jmethod_id and not needed because it > loses the race in the method id cache, it's never handed > back to native code, so it's safe to reuse. This is > different than jmethodIDs for methods that are unloaded. > They are cleared and never reused. At least that's my > reading of this caching code but it's pretty complicated > stuff. > > I've also run our nsk and jck vm/jvmti on this change and > they all passed. I'd be happy to sponsor it with these > suggested changes and it needs another reviewer. > > Thanks for diagnosing and fixing this problem! > Coleen > > > On 10/30/2014 01:02 PM, Jeremy Manson wrote: > > There's a significant regression in the speed of JVMTI > GetClassMethods in > JDK8. I've tracked this down to allocation of > jmethodids in a tight loop. > The issue can be addressed by preallocating enough > space for all of the > jmethodids when starting the operation and not > iterating over all of the > existing jmethodids when you allocate a new one. > > A patch is here: > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ > > > A reproducible test case can be found here: > > http://cr.openjdk.java.net/~jmanson/8062116/repro/ > > > It's a benchmark, though: I have no idea how to turn > it into a test. > > For whoever reviews it: can you explain to me why it > is okay that this code > reuses jmethodIDs (in JNIMethodBlock::add_method? I > can imagine a lot of > problems stemming from accidental reuse. > > Jeremy > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Nov 5 06:08:05 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Nov 2014 22:08:05 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <5459ADFB.4090808@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> Message-ID: <5459BEC5.4090809@oracle.com> Got rid of the bold selection below to make it more readable. Thanks, Serguei On 11/4/14 8:56 PM, serguei.spitsyn at oracle.com wrote: > The fix looks good in general. > > src/share/vm/oops/method.cpp > 1785 bool contains(Method** m) { > 1786 if (m == NULL) return false; > 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { > 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { > 1789 ptrdiff_t idx = m - b->_methods; > 1790 if (b->_methods + idx == m) { > 1791 return true; > 1792 } > 1793 } > 1794 } > 1795 return false; // not found > 1796 } > > Just noticed that the lines 1789-1792 can be replaced with one liner: > **return true; > > It is because the condition (b->_methods + idx == m) is always true. > :) > > Also, should we check the condition: *m != _free_method? > What about the following ?: > **return (*m != _free_method); > > > Thanks, > Serguei > > > On 11/4/14 5:52 PM, Jeremy Manson wrote: >> Updated patch here: >> >> http://cr.openjdk.java.net/~jmanson/8062116/webrev.01/ >> >> >> Jeremy >> >> On Tue, Nov 4, 2014 at 2:15 PM, serguei.spitsyn at oracle.com >> > > wrote: >> >> Jeremy and Coleen, >> >> Thank you for taking care about this bug! >> >> The fix looks good to me. >> I do not see any issues. >> >> Coleen, >> >> Please, let me know if you need any help with testing or anything >> else. >> >> Thanks, >> Serguei >> >> >> On 11/4/14 11:57 AM, serguei.spitsyn at oracle.com >> wrote: >> >> Hi Jeremy and Coleen, >> >> I'm reviewing this too. >> We also need to run the nsk.jvmti, nsk.jdi and jtreg jdi tests. >> >> Thanks, >> Serguei >> >> On 11/3/14 12:19 PM, Coleen Phillimore wrote: >> >> >> Hi Jeremy, >> >> I reviewed your new code and it looks fine. I had one >> comment in >> >> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/share/vm/prims/jvmtiEnv.cpp.udiff.html >> >> >> >> The name "need_to_resolve" doesn't make sense when >> reading this code. Isn't it more like >> "need_to_ensure_space" ? I think method resolution with >> the other name, which it doesn't do. >> >> I was trying to find a way to make this new code not >> appear twice (maybe with a local jvmtiEnv function >> get_jmethodID(m) - instanceK_h is m->method_holder()). >> >> >> Agreed on the above. >> >> >> Also, I was trying to figure out if the new class in >> utilities called chunkedList.hpp could be used to store >> jmethodIDs, since the data structures are similar. There >> is still more things in JNIMethodBlock has to do so I >> think a specialized structure is still needed (which is >> why I originally wrote it to be very simple). I'm not >> sure if the comment above it still applies. Maybe only >> the first and third sentences. Can you rewrite the >> comment slightly? >> >> Your other comments in the changes are good. >> >> I can't completely answer your question about reusing >> free_methods - but if a jmethodID is created >> provisionally in InstanceKlass::get_jmethod_id and not >> needed because it loses the race in the method id cache, >> it's never handed back to native code, so it's safe to >> reuse. This is different than jmethodIDs for methods >> that are unloaded. They are cleared and never reused. >> At least that's my reading of this caching code but it's >> pretty complicated stuff. >> >> I've also run our nsk and jck vm/jvmti on this change and >> they all passed. I'd be happy to sponsor it with these >> suggested changes and it needs another reviewer. >> >> Thanks for diagnosing and fixing this problem! >> Coleen >> >> >> On 10/30/2014 01:02 PM, Jeremy Manson wrote: >> >> There's a significant regression in the speed of >> JVMTI GetClassMethods in >> JDK8. I've tracked this down to allocation of >> jmethodids in a tight loop. >> The issue can be addressed by preallocating enough >> space for all of the >> jmethodids when starting the operation and not >> iterating over all of the >> existing jmethodids when you allocate a new one. >> >> A patch is here: >> >> http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/ >> >> A reproducible test case can be found here: >> >> http://cr.openjdk.java.net/~jmanson/8062116/repro/ >> >> >> It's a benchmark, though: I have no idea how to turn >> it into a test. >> >> For whoever reviews it: can you explain to me why it >> is okay that this code >> reuses jmethodIDs (in JNIMethodBlock::add_method? I >> can imagine a lot of >> problems stemming from accidental reuse. >> >> Jeremy >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Wed Nov 5 08:03:23 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 05 Nov 2014 09:03:23 +0100 Subject: RFR 8062896: TEST_BUG: java/lang/Thread/ThreadStateTest.java can't compile with change for 8058506 Message-ID: <5459D9CB.4030602@oracle.com> Please, review the following fix Issue : https://bugs.openjdk.java.net/browse/JDK-8062896 Webrev: http://cr.openjdk.java.net/~jbachorik/8062896/webrev.00/ Unfortunately, JTREG does not allow for automatic building library dependencies from the library classes themselves and therefore the @build section for the transitive closure of the library classes must be specified in all the tests using those library classes. Thanks, -JB- From david.holmes at oracle.com Wed Nov 5 08:45:00 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Nov 2014 18:45:00 +1000 Subject: RFR 8062896: TEST_BUG: java/lang/Thread/ThreadStateTest.java can't compile with change for 8058506 In-Reply-To: <5459D9CB.4030602@oracle.com> References: <5459D9CB.4030602@oracle.com> Message-ID: <5459E38C.5060107@oracle.com> On 5/11/2014 6:03 PM, Jaroslav Bachorik wrote: > Please, review the following fix > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062896 > Webrev: http://cr.openjdk.java.net/~jbachorik/8062896/webrev.00/ > > Unfortunately, JTREG does not allow for automatic building library > dependencies from the library classes themselves and therefore the > @build section for the transitive closure of the library classes must be > specified in all the tests using those library classes. Ok. But this should be have been detected before the other push was done. David > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Nov 5 08:48:38 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 05 Nov 2014 09:48:38 +0100 Subject: RFR 8062896: TEST_BUG: java/lang/Thread/ThreadStateTest.java can't compile with change for 8058506 In-Reply-To: <5459E38C.5060107@oracle.com> References: <5459D9CB.4030602@oracle.com> <5459E38C.5060107@oracle.com> Message-ID: <5459E466.8060904@oracle.com> On 11/05/2014 09:45 AM, David Holmes wrote: > On 5/11/2014 6:03 PM, Jaroslav Bachorik wrote: >> Please, review the following fix >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8062896 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8062896/webrev.00/ >> >> Unfortunately, JTREG does not allow for automatic building library >> dependencies from the library classes themselves and therefore the >> @build section for the transitive closure of the library classes must be >> specified in all the tests using those library classes. > > Ok. But this should be have been detected before the other push was done. It really depends on the order of execution of the tests :( If ThreadMXBeanStateTest is executed before ThreadStateTest the LockFreeLogManager class has already been compiled and the test will pass. If the order reverts the ThreadStateTest fails with compilation error. I should have searched for the uses of ThreadStateController more thoroughly :( -JB- > > David > >> Thanks, >> >> -JB- From albert.noll at oracle.com Wed Nov 5 09:12:32 2014 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 05 Nov 2014 10:12:32 +0100 Subject: [9] RFR(S): 8062735: CodeCacheSweeperThread missing from SA In-Reply-To: <54595418.6060300@oracle.com> References: <5458CE11.305@oracle.com> <54595418.6060300@oracle.com> Message-ID: <5459EA00.9070109@oracle.com> Coleen, Vladimir, Serguei, thanks for reviewing this. Best, Albert On 11/04/2014 11:32 PM, serguei.spitsyn at oracle.com wrote: > Hi Albert, > > The fix looks good. > > Thanks, > Serguei > > > On 11/4/14 5:01 AM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8062735 >> >> Problem: >> The fix for JDK-8046809 added the CodeCacheSweeperThread, but did not >> add this new type to SA. >> >> Solution: >> Add type to SA. >> >> Testing: >> Failing test cases. >> >> Webrev: >> http://cr.openjdk.java.net/~anoll/8062735/webrev.00/ >> >> Many thanks, >> Albert >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Nov 5 10:27:34 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 05 Nov 2014 02:27:34 -0800 Subject: 3-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <54596AC2.6050502@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> Message-ID: <5459FB96.9020404@oracle.com> Hi David, Thank you for the concerns! Testing showed several tests failing with deadlocks. Scenarios are similar to that you describe. Trying to understand the details. Thanks, Serguei On 11/4/14 4:09 PM, David Holmes wrote: > Hi Serguei, > > On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >> On 11/2/14 8:58 PM, David Holmes wrote: >>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> Thank you for good finding. This approach looks much better for me. >>>> >>>> The fix looks good. >>>> >>>> Is it necessary to release vmDeathLock locks at >>>> eventHandler.c:1244 before call >>>> >>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>> >>> I agree this looks necessary, or at least more clean (if things are >>> failing we really don't know what is happening). >> >> Agreed (replied to Dmitry). >> >>> >>> More generally I'm concerned about whether any of the code paths taken >>> while holding the new lock can result in deadlock - in particular with >>> regard to the resumeLock ? >> >> The cbVMDeath() function never holds both vmDeathLock and resumeLock at >> the same time, >> so there is no chance for a deadlock that involves both these locks. >> >> Two more locks used in the cbVMDeath() are the callbackBlock and >> callbackLock. >> These two locks look completely unrelated to the debugLoop_run(). >> >> The debugLoop_run() function also uses the cmdQueueLock. >> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at the >> same time. >> >> So that I do not see any potential to introduce new deadlock with the >> vmDeathLock. >> >> However, it is still easy to overlook something here. >> Please, let me know if you see any danger. > > I was mainly concerned about what might happen in the call chain for > threadControl_resumeAll() (it certainly sounds like it might need to > use a resumeLock :) ). I see direct use of the threadLock and > indirectly the eventHandler lock; but there are further call paths I > did not explore. Wish there was an easy way to determine the > transitive closure of all locks used from a given call. > > Thanks, > David > >> Thanks, >> Serguei >> >>> >>> David >>> >>>> -Dmitry >>>> >>>> >>>> >>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> It is 3-rd round of review for: >>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>> >>>>> New webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>> >>>>> >>>>> >>>>> >>>>> Summary >>>>> >>>>> For failing scenario, please, refer to the 1-st round RFR below. >>>>> >>>>> I've found what is missed in the jdwp agent shutdown and >>>>> decided to >>>>> switch from a workaround to a real fix. >>>>> >>>>> The agent VM_DEATH callback sets the gdata field: gdata->vmDead >>>>> = 1. >>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>> >>>>> 165 } else if (gdata->vmDead && >>>>> 166 ((cmd->cmdSet) != >>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>> 167 /* Protect the VM from calls while dead. >>>>> 168 * VirtualMachine cmdSet quietly ignores some >>>>> cmds >>>>> 169 * after VM death, so, it sends it's own >>>>> errors. >>>>> 170 */ >>>>> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >>>>> >>>>> >>>>> However, the guard above does not help much if the VM_DEATH event >>>>> happens in the middle of a command execution. >>>>> There is a lack of synchronization here. >>>>> >>>>> The fix introduces new lock (vmDeathLock) which does not allow to >>>>> execute the commands >>>>> and the VM_DEATH event callback concurrently. >>>>> It should work well for any function that is used in >>>>> implementation of >>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>> >>>>> >>>>> Testing: >>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>> tests >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>> The updated webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The changes are: >>>>>> - added a comment recommended by Staffan >>>>>> - removed the ignore_wrong_phase() call from function >>>>>> classSignature() >>>>>> >>>>>> The classSignature() function is called in 16 places. >>>>>> Most of them do not tolerate the NULL in place of returned signature >>>>>> and will crash. >>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>> return to this >>>>>> issue after gaining experience with more failure cases that are >>>>>> still >>>>>> expected. >>>>>> The failure with the classSignature() involved was observed only >>>>>> once >>>>>> in the nightly >>>>>> and should be extremely rare reproducible. >>>>>> I'll file a placeholder bug if necessary. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>> >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> The failing scenario: >>>>>>> The debugger and the debuggee are well aware a VM shutdown >>>>>>> has >>>>>>> been started in the target process. >>>>>>> The debugger at this point is not expected to send any >>>>>>> commands >>>>>>> to the JDWP agent. >>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>> (debuggee side) >>>>>>> are not in sync with the consumer layers. >>>>>>> >>>>>>> One reason is because the test debugger does not invoke >>>>>>> the JDI >>>>>>> method VirtualMachine.dispose(). >>>>>>> Another reason is that the Debugger and the debuggee >>>>>>> processes >>>>>>> are uneasy to sync in general. >>>>>>> >>>>>>> As a result the following steps are possible: >>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>> debuggee >>>>>>> - The debuggee is normally exiting >>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>> anonymous class unload event >>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>> ClassUnloadEvent event >>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>> reference type. >>>>>>> If there is more than one class with the same host class >>>>>>> signature, it can't distinguish them, >>>>>>> and so, deletes all references and re-retrieves them >>>>>>> again >>>>>>> (see tracing below): >>>>>>> MY_TRACE: JDI: >>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>> - The jdwp backend debugLoop_run() gets the command from >>>>>>> JDI >>>>>>> and calls the functions >>>>>>> classesForSignature() and classStatus() recursively. >>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>> GetClassStatus() >>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>> to the >>>>>>> JDI, and so, the test fails >>>>>>> >>>>>>> For details, see the analysis in bug report closed as a >>>>>>> dup of >>>>>>> the bug 6988950: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>> >>>>>>> Some similar cases can be found in the two bug reports >>>>>>> (6988950 >>>>>>> and 8024865) describing this issue. >>>>>>> >>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>> error >>>>>>> as it is normal at the VM shutdown. >>>>>>> The original jdwp backend implementation had a similar >>>>>>> approach >>>>>>> for the raw monitor functions. >>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>> tests >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>>> >> From staffan.larsen at oracle.com Wed Nov 5 10:37:34 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 5 Nov 2014 11:37:34 +0100 Subject: RFR 8062896: TEST_BUG: java/lang/Thread/ThreadStateTest.java can't compile with change for 8058506 In-Reply-To: <5459D9CB.4030602@oracle.com> References: <5459D9CB.4030602@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 5 nov 2014, at 09:03, Jaroslav Bachorik wrote: > > Please, review the following fix > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062896 > Webrev: http://cr.openjdk.java.net/~jbachorik/8062896/webrev.00/ > > Unfortunately, JTREG does not allow for automatic building library dependencies from the library classes themselves and therefore the @build section for the transitive closure of the library classes must be specified in all the tests using those library classes. > > Thanks, > > -JB- From evgeniya.stepanova at oracle.com Wed Nov 5 15:33:59 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Wed, 05 Nov 2014 19:33:59 +0400 Subject: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests Message-ID: <545A4367.1070407@oracle.com> Hi, Please review changes for 8062536, the OpenJDK/jdk part of the JDK-8019361 bug: https://bugs.openjdk.java.net/browse/JDK-8062536 fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ Problem: Some tests explicitly set GC and fail when another GC is set outside Solution: Such tests marked with the jtreg tag "requires" to skip test if there is a conflict Tested locally with different GC flags (-XX:+UseG1GC, -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without any GC flag). Tests are being excluded as expected. No tests failed because of the conflict. Thanks, Evgeniya Stepanova // -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Wed Nov 5 23:13:45 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 5 Nov 2014 15:13:45 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <5459ADFB.4090808@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> Message-ID: On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > The fix looks good in general. > > src/share/vm/oops/method.cpp > > 1785 bool contains(Method** m) {1786 if (m == NULL) return false;1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) {1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) {*1789 ptrdiff_t idx = m - b->_methods;**1790 if (b->_methods + idx == m) {** > 1791 return true; > 1792 }* > 1793 } > 1794 } > 1795 return false; // not found > 1796 } > > > Just noticed that the lines 1789-1792 can be replaced with one liner: > * return true;* > Ah, you have found our crappy workaround for wild pointers to non-aligned places in the middle of _methods. > It is because the condition * (b->_methods + idx == m)* is always true. > :) > > Also, should we check the condition: **m != _free_method* ? > What about the following ?: > * return (***m != _free_method);* > I don't mind adding this, if Coleen thinks those are the semantics this needs. It wasn't there before, of course. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Nov 5 23:40:17 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Nov 2014 18:40:17 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> Message-ID: <545AB561.9020204@oracle.com> On 11/5/14, 6:13 PM, Jeremy Manson wrote: > > > On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com > > wrote: > > The fix looks good in general. > > src/share/vm/oops/method.cpp > > 1785 bool contains(Method** m) { > 1786 if (m == NULL) return false; > 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { > 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { > *1789 ptrdiff_t idx = m - b->_methods;** > **1790 if (b->_methods + idx == m) {** > 1791 return true; > 1792 }* > 1793 } > 1794 } > 1795 return false; // not found > 1796 } > > > Just noticed that the lines 1789-1792 can be replaced with one liner: > * return true;* > > > Ah, you have found our crappy workaround for wild pointers to > non-aligned places in the middle of _methods. Can you explain this? Why are there wild pointers? > > It is because the condition *(b->_methods + idx == m)* is always > true. :) > > Also, should we check the condition: **m != _free_method*** ? > What about the following ?: > * return (****m != _free_method***);* > > > I don't mind adding this, if Coleen thinks those are the semantics > this needs. It wasn't there before, of course. > The semantics weren't there before and the way this is called has already checked that *m != _free_method. Would it be an improvement? I don't think so. It seems that contains() should just check that the Method** is contained in the methodID table. To be more correct, is_method_id should check that it's not a freed methodID but the caller verifies this already. So I don't think this should change. BTW, I've run the test sets suggested by Serguei and they all passed. Coleen > Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Nov 5 23:51:03 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 05 Nov 2014 15:51:03 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545AB561.9020204@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> Message-ID: <545AB7E7.4020809@oracle.com> On 11/5/14 3:40 PM, Coleen Phillimore wrote: > > On 11/5/14, 6:13 PM, Jeremy Manson wrote: >> >> >> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >> > > wrote: >> >> The fix looks good in general. >> >> src/share/vm/oops/method.cpp >> >> 1785 bool contains(Method** m) { >> 1786 if (m == NULL) return false; >> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { >> 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { >> *1789 ptrdiff_t idx = m - b->_methods;** >> **1790 if (b->_methods + idx == m) {** >> 1791 return true; >> 1792 }* >> 1793 } >> 1794 } >> 1795 return false; // not found >> 1796 } >> >> >> Just noticed that the lines 1789-1792 can be replaced with one liner: >> * return true;* >> >> >> Ah, you have found our crappy workaround for wild pointers to >> non-aligned places in the middle of _methods. > > Can you explain this? Why are there wild pointers? >> >> It is because the condition *(b->_methods + idx == m)* is always >> true. :) >> >> Also, should we check the condition: **m != _free_method*** ? >> What about the following ?: >> * return (****m != _free_method***);* >> >> >> I don't mind adding this, if Coleen thinks those are the semantics >> this needs. It wasn't there before, of course. >> > > The semantics weren't there before and the way this is called has > already checked that *m != _free_method. Would it be an improvement? > I don't think so. It seems that contains() should just check that the > Method** is contained in the methodID table. To be more correct, > is_method_id should check that it's not a freed methodID but the > caller verifies this already. So I don't think this should change. Agreed. Thank you for the explanation! > > BTW, I've run the test sets suggested by Serguei and they all passed. Nice! Thanks, Serguei > > Coleen > >> Jeremy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Thu Nov 6 00:35:23 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 5 Nov 2014 16:35:23 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545AB561.9020204@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> Message-ID: On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > On 11/5/14, 6:13 PM, Jeremy Manson wrote: > > > > On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > >> The fix looks good in general. >> >> src/share/vm/oops/method.cpp >> >> 1785 bool contains(Method** m) {1786 if (m == NULL) return false;1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) {1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) {*1789 ptrdiff_t idx = m - b->_methods;**1790 if (b->_methods + idx == m) {** >> 1791 return true; >> 1792 }* >> 1793 } >> 1794 } >> 1795 return false; // not found >> 1796 } >> >> >> Just noticed that the lines 1789-1792 can be replaced with one liner: >> * return true;* >> > > Ah, you have found our crappy workaround for wild pointers to > non-aligned places in the middle of _methods. > > > Can you explain this? Why are there wild pointers? > My belief was that end user code could pass any old garbage to this function. It's called by Method::is_method_id, which is called by jniCheck::validate_jmethod_id. The idea was that this would help check jni deliver useful information in the case of the end user inputting garbage that happened to be in the right memory range. Having said that, at a second glance, it looks as if it that call is protected by a call to is_method() (in checked_resolve_jmethod_id), so the program will probably crash before it gets to this check. The other point about it was that the result of >= and < is technically unspecified; if it were ever implemented as anything other than a binary comparison between integers (which it never is, now that no one has a segmented architecture), the comparison could pass spuriously, so checking would be a good thing. Of course, the comparison could fail spuriously, too. Anyway, I'm happy to leave it in as belt-and-suspenders (and add a comment, obviously, since it has caused confusion), or take it out. Your call. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Nov 6 00:41:42 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Nov 2014 19:41:42 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> Message-ID: <545AC3C6.6070105@oracle.com> Yes, leave it in and add a comment then (sorry for top-posting). Thank you for the explanation. Coleen On 11/5/14, 7:35 PM, Jeremy Manson wrote: > > > On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore > > > wrote: > > > On 11/5/14, 6:13 PM, Jeremy Manson wrote: >> >> >> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >> > > wrote: >> >> The fix looks good in general. >> >> src/share/vm/oops/method.cpp >> >> 1785 bool contains(Method** m) { >> 1786 if (m == NULL) return false; >> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { >> 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { >> *1789 ptrdiff_t idx = m - b->_methods;** >> **1790 if (b->_methods + idx == m) {** >> 1791 return true; >> 1792 }* >> 1793 } >> 1794 } >> 1795 return false; // not found >> 1796 } >> >> >> Just noticed that the lines 1789-1792 can be replaced with >> one liner: >> * return true;* >> >> >> Ah, you have found our crappy workaround for wild pointers to >> non-aligned places in the middle of _methods. > > Can you explain this? Why are there wild pointers? > > > My belief was that end user code could pass any old garbage to this > function. It's called by Method::is_method_id, which is called > by jniCheck::validate_jmethod_id. The idea was that this would help > check jni deliver useful information in the case of the end user > inputting garbage that happened to be in the right memory range. > > Having said that, at a second glance, it looks as if it that call is > protected by a call to is_method() (in checked_resolve_jmethod_id), so > the program will probably crash before it gets to this check. > > The other point about it was that the result of >= and < is > technically unspecified; if it were ever implemented as anything other > than a binary comparison between integers (which it never is, now that > no one has a segmented architecture), the comparison could pass > spuriously, so checking would be a good thing. Of course, the > comparison could fail spuriously, too. > > Anyway, I'm happy to leave it in as belt-and-suspenders (and add a > comment, obviously, since it has caused confusion), or take it out. > Your call. > > Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Nov 6 01:11:00 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 05 Nov 2014 17:11:00 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> Message-ID: <545ACAA4.3020906@oracle.com> On 11/5/14 4:35 PM, Jeremy Manson wrote: > > > On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore > > > wrote: > > > On 11/5/14, 6:13 PM, Jeremy Manson wrote: >> >> >> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >> > > wrote: >> >> The fix looks good in general. >> >> src/share/vm/oops/method.cpp >> >> 1785 bool contains(Method** m) { >> 1786 if (m == NULL) return false; >> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { >> 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { >> *1789 ptrdiff_t idx = m - b->_methods;** >> **1790 if (b->_methods + idx == m) {** >> 1791 return true; >> 1792 }* >> 1793 } >> 1794 } >> 1795 return false; // not found >> 1796 } >> >> >> Just noticed that the lines 1789-1792 can be replaced with >> one liner: >> * return true;* >> >> >> Ah, you have found our crappy workaround for wild pointers to >> non-aligned places in the middle of _methods. > > Can you explain this? Why are there wild pointers? > > > My belief was that end user code could pass any old garbage to this > function. It's called by Method::is_method_id, which is called > by jniCheck::validate_jmethod_id. The idea was that this would help > check jni deliver useful information in the case of the end user > inputting garbage that happened to be in the right memory range. > > Having said that, at a second glance, it looks as if it that call is > protected by a call to is_method() (in checked_resolve_jmethod_id), so > the program will probably crash before it gets to this check. > > The other point about it was that the result of >= and < is > technically unspecified; if it were ever implemented as anything other > than a binary comparison between integers (which it never is, now that > no one has a segmented architecture), the comparison could pass > spuriously, so checking would be a good thing. Of course, the > comparison could fail spuriously, too. > > Anyway, I'm happy to leave it in as belt-and-suspenders (and add a > comment, obviously, since it has caused confusion), or take it out. > Your call. I'm still confused. How this code could possibly check anything? ptrdiff_t idx = m - b->_methods; if (b->_methods + idx == m) { The condition above always gives true: b->_methods + (idx) == b->_methods + (m - b->_methods) == (b->_methods- b->_methods) + m == (0 + m) == m Even if m was unaligned then at the end we compare m with m which is still true. Do I miss anything? Thanks, Serguei ** > > Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Nov 6 02:20:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Nov 2014 12:20:07 +1000 Subject: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545A4367.1070407@oracle.com> References: <545A4367.1070407@oracle.com> Message-ID: <545ADAD7.7040902@oracle.com> Hi Evgeniya, On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: > Hi, > > Please review changes for 8062536, the OpenJDK/jdk part of the JDK-8019361 > > bug: https://bugs.openjdk.java.net/browse/JDK-8062536 > fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ > > Problem: Some tests explicitly set GC and fail when another GC is set > outside I don't see why you have done this for the test/sun/tools/jps/TestJps*.java tests. They don't set any GC flags. > Solution: Such tests marked with the jtreg tag "requires" to skip test > if there is a conflict Just wondering: Does a skipped test get a .jtr file showing it was skipped; or does it only appear in the higher-level jtreg log? Thanks, David > Tested locally with different GC flags (-XX:+UseG1GC, > -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without > any GC flag). Tests are being excluded as expected. No tests failed > because of the conflict. > > Thanks, > Evgeniya Stepanova > > // From coleen.phillimore at oracle.com Thu Nov 6 03:00:42 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Nov 2014 22:00:42 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545ACAA4.3020906@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> <545ACAA4.3020906@oracle.com> Message-ID: <545AE45A.5080003@oracle.com> On 11/5/14, 8:11 PM, serguei.spitsyn at oracle.com wrote: > > On 11/5/14 4:35 PM, Jeremy Manson wrote: >> >> >> On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore >> > >> wrote: >> >> >> On 11/5/14, 6:13 PM, Jeremy Manson wrote: >>> >>> >>> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >>> >> > wrote: >>> >>> The fix looks good in general. >>> >>> src/share/vm/oops/method.cpp >>> >>> 1785 bool contains(Method** m) { >>> 1786 if (m == NULL) return false; >>> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { >>> 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { >>> *1789 ptrdiff_t idx = m - b->_methods;** >>> **1790 if (b->_methods + idx == m) {** >>> 1791 return true; >>> 1792 }* >>> 1793 } >>> 1794 } >>> 1795 return false; // not found >>> 1796 } >>> >>> >>> Just noticed that the lines 1789-1792 can be replaced with >>> one liner: >>> * return true;* >>> >>> >>> Ah, you have found our crappy workaround for wild pointers to >>> non-aligned places in the middle of _methods. >> >> Can you explain this? Why are there wild pointers? >> >> >> My belief was that end user code could pass any old garbage to this >> function. It's called by Method::is_method_id, which is called >> by jniCheck::validate_jmethod_id. The idea was that this would help >> check jni deliver useful information in the case of the end user >> inputting garbage that happened to be in the right memory range. >> >> Having said that, at a second glance, it looks as if it that call is >> protected by a call to is_method() (in checked_resolve_jmethod_id), >> so the program will probably crash before it gets to this check. >> >> The other point about it was that the result of >= and < is >> technically unspecified; if it were ever implemented as anything >> other than a binary comparison between integers (which it never is, >> now that no one has a segmented architecture), the comparison could >> pass spuriously, so checking would be a good thing. Of course, the >> comparison could fail spuriously, too. >> >> Anyway, I'm happy to leave it in as belt-and-suspenders (and add a >> comment, obviously, since it has caused confusion), or take it out. >> Your call. > > I'm still confused. > > How this code could possibly check anything? > ptrdiff_t idx = m - b->_methods; > if (b->_methods + idx == m) { > > The condition above always gives true: > b->_methods + (idx) == b->_methods + (m - b->_methods) == > (b->_methods- b->_methods) + m == (0 + m) == m > > Even if m was unaligned then at the end we compare m with m which is > still true. > Do I miss anything? If 'm' is unaligned we would fail this comparison: (gdb) print &methods->_data[2] $34 = (Method **) 0x7fffe0022440 (gdb) print &methods->_data[0] $35 = (Method **) 0x7fffe0022430 (gdb) print 0x7fffe0022444 - 0x7fffe0022430 $32 = 20 (gdb) print 20/8 $33 = 2 if m is misaligned 0x7fffe0022444 the idx would be 2 and the expression (b->_methods + idx) would evaluate to the aligned 0xfffe0022440 so not equal m. But the code could check for misaligned m instead (or it would have already crashed). I think all bets are off if the address space is segmented. The comment Jeremy added is: if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { // This is a bit of extra checking, for two reasons. One is // that contains() deals with pointers that are passed in by // JNI code, so making sure that the pointer is aligned // correctly is valuable. The other is that <= and > are // technically not defined on pointers, so the if guard can // pass spuriously; no modern compiler is likely to make that // a problem, though (and if one did, the guard could also // fail spuriously, which would be bad). ptrdiff_t idx = m - b->_methods; if (b->_methods + idx == m) { return true; } Coleen > > > Thanks, > Serguei > > ** >> >> Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Nov 6 03:11:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Nov 2014 13:11:18 +1000 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545AE45A.5080003@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> <545ACAA4.3020906@oracle.com> <545AE45A.5080003@oracle.com> Message-ID: <545AE6D6.4040401@oracle.com> On 6/11/2014 1:00 PM, Coleen Phillimore wrote: > > On 11/5/14, 8:11 PM, serguei.spitsyn at oracle.com wrote: >> >> On 11/5/14 4:35 PM, Jeremy Manson wrote: >>> >>> >>> On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore >>> > >>> wrote: >>> >>> >>> On 11/5/14, 6:13 PM, Jeremy Manson wrote: >>>> >>>> >>>> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >>>> >>> > wrote: >>>> >>>> The fix looks good in general. >>>> >>>> src/share/vm/oops/method.cpp >>>> >>>> 1785 bool contains(Method** m) { >>>> 1786 if (m == NULL) return false; >>>> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b = b->_next) { >>>> 1788 if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { >>>> *1789 ptrdiff_t idx = m - b->_methods;** >>>> **1790 if (b->_methods + idx == m) {** >>>> 1791 return true; >>>> 1792 }* >>>> 1793 } >>>> 1794 } >>>> 1795 return false; // not found >>>> 1796 } >>>> >>>> >>>> Just noticed that the lines 1789-1792 can be replaced with >>>> one liner: >>>> * return true;* >>>> >>>> >>>> Ah, you have found our crappy workaround for wild pointers to >>>> non-aligned places in the middle of _methods. >>> >>> Can you explain this? Why are there wild pointers? >>> >>> >>> My belief was that end user code could pass any old garbage to this >>> function. It's called by Method::is_method_id, which is called >>> by jniCheck::validate_jmethod_id. The idea was that this would help >>> check jni deliver useful information in the case of the end user >>> inputting garbage that happened to be in the right memory range. >>> >>> Having said that, at a second glance, it looks as if it that call is >>> protected by a call to is_method() (in checked_resolve_jmethod_id), >>> so the program will probably crash before it gets to this check. >>> >>> The other point about it was that the result of >= and < is >>> technically unspecified; if it were ever implemented as anything >>> other than a binary comparison between integers (which it never is, >>> now that no one has a segmented architecture), the comparison could >>> pass spuriously, so checking would be a good thing. Of course, the >>> comparison could fail spuriously, too. >>> >>> Anyway, I'm happy to leave it in as belt-and-suspenders (and add a >>> comment, obviously, since it has caused confusion), or take it out. >>> Your call. >> >> I'm still confused. >> >> How this code could possibly check anything? >> ptrdiff_t idx = m - b->_methods; >> if (b->_methods + idx == m) { >> >> The condition above always gives true: >> b->_methods + (idx) == b->_methods + (m - b->_methods) == >> (b->_methods- b->_methods) + m == (0 + m) == m >> >> Even if m was unaligned then at the end we compare m with m which is >> still true. >> Do I miss anything? > > If 'm' is unaligned we would fail this comparison: > > (gdb) print &methods->_data[2] > $34 = (Method **) 0x7fffe0022440 > (gdb) print &methods->_data[0] > $35 = (Method **) 0x7fffe0022430 > (gdb) print 0x7fffe0022444 - 0x7fffe0022430 > $32 = 20 I was confused about this too. What we have here is pointer arithmetic, not regular arithmetic, so I'm assuming an unaligned value has to be adjusted before the actual difference is computed. So in practice: m - b->_methods is really adjusted_for_alignment(m) - b->_methods David ----- > (gdb) print 20/8 > $33 = 2 > > if m is misaligned 0x7fffe0022444 the idx would be 2 and the expression > (b->_methods + idx) would evaluate to the aligned 0xfffe0022440 so not > equal m. > > But the code could check for misaligned m instead (or it would have > already crashed). I think all bets are off if the address space is > segmented. > > The comment Jeremy added is: > > if (b->_methods <= m && m < b->_methods + b->_number_of_methods) { > // This is a bit of extra checking, for two reasons. One is > // that contains() deals with pointers that are passed in by > // JNI code, so making sure that the pointer is aligned > // correctly is valuable. The other is that <= and > are > // technically not defined on pointers, so the if guard can > // pass spuriously; no modern compiler is likely to make that > // a problem, though (and if one did, the guard could also > // fail spuriously, which would be bad). > ptrdiff_t idx = m - b->_methods; > if (b->_methods + idx == m) { > return true; > } > > Coleen >> >> >> Thanks, >> Serguei >> >> ** >>> >>> Jeremy >> > From coleen.phillimore at oracle.com Thu Nov 6 05:02:01 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 06 Nov 2014 00:02:01 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545AE6D6.4040401@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> <545ACAA4.3020906@oracle.com> <545AE45A.5080003@oracle.com> <545AE6D6.4040401@oracle.com> Message-ID: <545B00C9.1070502@oracle.com> David and Serguei (and Jeremy), see below. Summary: I think Jeremy's code and comments are good. On 11/5/14, 10:11 PM, David Holmes wrote: > On 6/11/2014 1:00 PM, Coleen Phillimore wrote: >> >> On 11/5/14, 8:11 PM, serguei.spitsyn at oracle.com wrote: >>> >>> On 11/5/14 4:35 PM, Jeremy Manson wrote: >>>> >>>> >>>> On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore >>>> > >>>> wrote: >>>> >>>> >>>> On 11/5/14, 6:13 PM, Jeremy Manson wrote: >>>>> >>>>> >>>>> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >>>>> >>>> > wrote: >>>>> >>>>> The fix looks good in general. >>>>> >>>>> src/share/vm/oops/method.cpp >>>>> >>>>> 1785 bool contains(Method** m) { >>>>> 1786 if (m == NULL) return false; >>>>> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b >>>>> = b->_next) { >>>>> 1788 if (b->_methods <= m && m < b->_methods + >>>>> b->_number_of_methods) { >>>>> *1789 ptrdiff_t idx = m - b->_methods;** >>>>> **1790 if (b->_methods + idx == m) {** >>>>> 1791 return true; >>>>> 1792 }* >>>>> 1793 } >>>>> 1794 } >>>>> 1795 return false; // not found >>>>> 1796 } >>>>> >>>>> >>>>> Just noticed that the lines 1789-1792 can be replaced with >>>>> one liner: >>>>> * return true;* >>>>> >>>>> >>>>> Ah, you have found our crappy workaround for wild pointers to >>>>> non-aligned places in the middle of _methods. >>>> >>>> Can you explain this? Why are there wild pointers? >>>> >>>> >>>> My belief was that end user code could pass any old garbage to this >>>> function. It's called by Method::is_method_id, which is called >>>> by jniCheck::validate_jmethod_id. The idea was that this would help >>>> check jni deliver useful information in the case of the end user >>>> inputting garbage that happened to be in the right memory range. >>>> >>>> Having said that, at a second glance, it looks as if it that call is >>>> protected by a call to is_method() (in checked_resolve_jmethod_id), >>>> so the program will probably crash before it gets to this check. >>>> >>>> The other point about it was that the result of >= and < is >>>> technically unspecified; if it were ever implemented as anything >>>> other than a binary comparison between integers (which it never is, >>>> now that no one has a segmented architecture), the comparison could >>>> pass spuriously, so checking would be a good thing. Of course, the >>>> comparison could fail spuriously, too. >>>> >>>> Anyway, I'm happy to leave it in as belt-and-suspenders (and add a >>>> comment, obviously, since it has caused confusion), or take it out. >>>> Your call. >>> >>> I'm still confused. >>> >>> How this code could possibly check anything? >>> ptrdiff_t idx = m - b->_methods; >>> if (b->_methods + idx == m) { >>> >>> The condition above always gives true: >>> b->_methods + (idx) == b->_methods + (m - b->_methods) == >>> (b->_methods- b->_methods) + m == (0 + m) == m >>> >>> Even if m was unaligned then at the end we compare m with m which is >>> still true. >>> Do I miss anything? >> >> If 'm' is unaligned we would fail this comparison: >> >> (gdb) print &methods->_data[2] >> $34 = (Method **) 0x7fffe0022440 >> (gdb) print &methods->_data[0] >> $35 = (Method **) 0x7fffe0022430 >> (gdb) print 0x7fffe0022444 - 0x7fffe0022430 >> $32 = 20 > > I was confused about this too. What we have here is pointer > arithmetic, not regular arithmetic, so I'm assuming an unaligned value > has to be adjusted before the actual difference is computed. So in > practice: > > m - b->_methods > > is really > > adjusted_for_alignment(m) - b->_methods It's not adjusted for alignment: #include extern "C" int printf(const char *,...); class Method { int i ; int j; int k; }; Method* array[10] = { new Method(),new Method(),new Method(),new Method(),new Method(),n ew Method(),new Method(),new Method(),new Method(),new Method() }; void test(Method** m) { printf("m is 0x%p ", m); ptrdiff_t idx = m - array; if (array + idx == m) { printf("true %ld\n", idx); } else { printf("false %ld\n", idx); } } main() { Method** xx = &array[3]; test(xx); test((Method**)(((char*)xx) - 2)); } cphilli% a.out m is 0x0x601098 true 3 m is 0x0x601096 false 2 Coleen > > David > ----- > >> (gdb) print 20/8 >> $33 = 2 >> >> if m is misaligned 0x7fffe0022444 the idx would be 2 and the expression >> (b->_methods + idx) would evaluate to the aligned 0xfffe0022440 so not >> equal m. >> >> But the code could check for misaligned m instead (or it would have >> already crashed). I think all bets are off if the address space is >> segmented. >> >> The comment Jeremy added is: >> >> if (b->_methods <= m && m < b->_methods + >> b->_number_of_methods) { >> // This is a bit of extra checking, for two reasons. One is >> // that contains() deals with pointers that are passed in by >> // JNI code, so making sure that the pointer is aligned >> // correctly is valuable. The other is that <= and > are >> // technically not defined on pointers, so the if guard can >> // pass spuriously; no modern compiler is likely to make that >> // a problem, though (and if one did, the guard could also >> // fail spuriously, which would be bad). >> ptrdiff_t idx = m - b->_methods; >> if (b->_methods + idx == m) { >> return true; >> } >> >> Coleen >>> >>> >>> Thanks, >>> Serguei >>> >>> ** >>>> >>>> Jeremy >>> >> From david.holmes at oracle.com Thu Nov 6 05:35:10 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Nov 2014 15:35:10 +1000 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545B00C9.1070502@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> <545ACAA4.3020906@oracle.com> <545AE45A.5080003@oracle.com> <545AE6D6.4040401@oracle.com> <545B00C9.1070502@oracle.com> Message-ID: <545B088E.20903@oracle.com> On 6/11/2014 3:02 PM, Coleen Phillimore wrote: > > David and Serguei (and Jeremy), see below. Summary: I think Jeremy's > code and comments are good. > > On 11/5/14, 10:11 PM, David Holmes wrote: >> On 6/11/2014 1:00 PM, Coleen Phillimore wrote: >>> >>> On 11/5/14, 8:11 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> On 11/5/14 4:35 PM, Jeremy Manson wrote: >>>>> >>>>> >>>>> On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> On 11/5/14, 6:13 PM, Jeremy Manson wrote: >>>>>> >>>>>> >>>>>> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >>>>>> >>>>> > wrote: >>>>>> >>>>>> The fix looks good in general. >>>>>> >>>>>> src/share/vm/oops/method.cpp >>>>>> >>>>>> 1785 bool contains(Method** m) { >>>>>> 1786 if (m == NULL) return false; >>>>>> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b >>>>>> = b->_next) { >>>>>> 1788 if (b->_methods <= m && m < b->_methods + >>>>>> b->_number_of_methods) { >>>>>> *1789 ptrdiff_t idx = m - b->_methods;** >>>>>> **1790 if (b->_methods + idx == m) {** >>>>>> 1791 return true; >>>>>> 1792 }* >>>>>> 1793 } >>>>>> 1794 } >>>>>> 1795 return false; // not found >>>>>> 1796 } >>>>>> >>>>>> >>>>>> Just noticed that the lines 1789-1792 can be replaced with >>>>>> one liner: >>>>>> * return true;* >>>>>> >>>>>> >>>>>> Ah, you have found our crappy workaround for wild pointers to >>>>>> non-aligned places in the middle of _methods. >>>>> >>>>> Can you explain this? Why are there wild pointers? >>>>> >>>>> >>>>> My belief was that end user code could pass any old garbage to this >>>>> function. It's called by Method::is_method_id, which is called >>>>> by jniCheck::validate_jmethod_id. The idea was that this would help >>>>> check jni deliver useful information in the case of the end user >>>>> inputting garbage that happened to be in the right memory range. >>>>> >>>>> Having said that, at a second glance, it looks as if it that call is >>>>> protected by a call to is_method() (in checked_resolve_jmethod_id), >>>>> so the program will probably crash before it gets to this check. >>>>> >>>>> The other point about it was that the result of >= and < is >>>>> technically unspecified; if it were ever implemented as anything >>>>> other than a binary comparison between integers (which it never is, >>>>> now that no one has a segmented architecture), the comparison could >>>>> pass spuriously, so checking would be a good thing. Of course, the >>>>> comparison could fail spuriously, too. >>>>> >>>>> Anyway, I'm happy to leave it in as belt-and-suspenders (and add a >>>>> comment, obviously, since it has caused confusion), or take it out. >>>>> Your call. >>>> >>>> I'm still confused. >>>> >>>> How this code could possibly check anything? >>>> ptrdiff_t idx = m - b->_methods; >>>> if (b->_methods + idx == m) { >>>> >>>> The condition above always gives true: >>>> b->_methods + (idx) == b->_methods + (m - b->_methods) == >>>> (b->_methods- b->_methods) + m == (0 + m) == m >>>> >>>> Even if m was unaligned then at the end we compare m with m which is >>>> still true. >>>> Do I miss anything? >>> >>> If 'm' is unaligned we would fail this comparison: >>> >>> (gdb) print &methods->_data[2] >>> $34 = (Method **) 0x7fffe0022440 >>> (gdb) print &methods->_data[0] >>> $35 = (Method **) 0x7fffe0022430 >>> (gdb) print 0x7fffe0022444 - 0x7fffe0022430 >>> $32 = 20 >> >> I was confused about this too. What we have here is pointer >> arithmetic, not regular arithmetic, so I'm assuming an unaligned value >> has to be adjusted before the actual difference is computed. So in >> practice: >> >> m - b->_methods >> >> is really >> >> adjusted_for_alignment(m) - b->_methods > > It's not adjusted for alignment: Right - now I get it. Pointer difference is an algebraic subtraction with "div sizeof what is pointed to". For aligned pointers there will be no remainder and adding back the difference to the initial pointer will yield the end pointer. But if one of the pointers is not aligned that is not the case. All rather icky. Thanks, David ---- > #include > > extern "C" int printf(const char *,...); > class Method { > int i ; int j; int k; > }; > > Method* array[10] = { new Method(),new Method(),new Method(),new > Method(),new Method(),n > ew Method(),new Method(),new Method(),new Method(),new Method() }; > > void test(Method** m) { > printf("m is 0x%p ", m); > ptrdiff_t idx = m - array; > if (array + idx == m) { > printf("true %ld\n", idx); > } else { > printf("false %ld\n", idx); > } > } > main() { > Method** xx = &array[3]; > test(xx); > test((Method**)(((char*)xx) - 2)); > } > > cphilli% a.out > m is 0x0x601098 true 3 > m is 0x0x601096 false 2 > > > Coleen > >> >> David >> ----- >> >>> (gdb) print 20/8 >>> $33 = 2 >>> >>> if m is misaligned 0x7fffe0022444 the idx would be 2 and the expression >>> (b->_methods + idx) would evaluate to the aligned 0xfffe0022440 so not >>> equal m. >>> >>> But the code could check for misaligned m instead (or it would have >>> already crashed). I think all bets are off if the address space is >>> segmented. >>> >>> The comment Jeremy added is: >>> >>> if (b->_methods <= m && m < b->_methods + >>> b->_number_of_methods) { >>> // This is a bit of extra checking, for two reasons. One is >>> // that contains() deals with pointers that are passed in by >>> // JNI code, so making sure that the pointer is aligned >>> // correctly is valuable. The other is that <= and > are >>> // technically not defined on pointers, so the if guard can >>> // pass spuriously; no modern compiler is likely to make that >>> // a problem, though (and if one did, the guard could also >>> // fail spuriously, which would be bad). >>> ptrdiff_t idx = m - b->_methods; >>> if (b->_methods + idx == m) { >>> return true; >>> } >>> >>> Coleen >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> ** >>>>> >>>>> Jeremy >>>> >>> > From jeremymanson at google.com Thu Nov 6 05:44:53 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 5 Nov 2014 21:44:53 -0800 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545B088E.20903@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> <545ACAA4.3020906@oracle.com> <545AE45A.5080003@oracle.com> <545AE6D6.4040401@oracle.com> <545B00C9.1070502@oracle.com> <545B088E.20903@oracle.com> Message-ID: Wow, go take care of my toddler for a few hours, come back, and all the questions are answered for me! Thanks, Coleen. To be fair, the original code was actually correct (instead of, you know, implementation-dependent-correct), so I feel a little weird about the whole thing. Jeremy On Wed, Nov 5, 2014 at 9:35 PM, David Holmes wrote: > On 6/11/2014 3:02 PM, Coleen Phillimore wrote: > >> >> David and Serguei (and Jeremy), see below. Summary: I think Jeremy's >> code and comments are good. >> >> On 11/5/14, 10:11 PM, David Holmes wrote: >> >>> On 6/11/2014 1:00 PM, Coleen Phillimore wrote: >>> >>>> >>>> On 11/5/14, 8:11 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>>> >>>>> On 11/5/14 4:35 PM, Jeremy Manson wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 5, 2014 at 3:40 PM, Coleen Phillimore >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> On 11/5/14, 6:13 PM, Jeremy Manson wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 4, 2014 at 8:56 PM, serguei.spitsyn at oracle.com >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> The fix looks good in general. >>>>>>> >>>>>>> src/share/vm/oops/method.cpp >>>>>>> >>>>>>> 1785 bool contains(Method** m) { >>>>>>> 1786 if (m == NULL) return false; >>>>>>> 1787 for (JNIMethodBlockNode* b = &_head; b != NULL; b >>>>>>> = b->_next) { >>>>>>> 1788 if (b->_methods <= m && m < b->_methods + >>>>>>> b->_number_of_methods) { >>>>>>> *1789 ptrdiff_t idx = m - b->_methods;** >>>>>>> **1790 if (b->_methods + idx == m) {** >>>>>>> 1791 return true; >>>>>>> 1792 }* >>>>>>> 1793 } >>>>>>> 1794 } >>>>>>> 1795 return false; // not found >>>>>>> 1796 } >>>>>>> >>>>>>> >>>>>>> Just noticed that the lines 1789-1792 can be replaced with >>>>>>> one liner: >>>>>>> * return true;* >>>>>>> >>>>>>> >>>>>>> Ah, you have found our crappy workaround for wild pointers to >>>>>>> non-aligned places in the middle of _methods. >>>>>>> >>>>>> >>>>>> Can you explain this? Why are there wild pointers? >>>>>> >>>>>> >>>>>> My belief was that end user code could pass any old garbage to this >>>>>> function. It's called by Method::is_method_id, which is called >>>>>> by jniCheck::validate_jmethod_id. The idea was that this would help >>>>>> check jni deliver useful information in the case of the end user >>>>>> inputting garbage that happened to be in the right memory range. >>>>>> >>>>>> Having said that, at a second glance, it looks as if it that call is >>>>>> protected by a call to is_method() (in checked_resolve_jmethod_id), >>>>>> so the program will probably crash before it gets to this check. >>>>>> >>>>>> The other point about it was that the result of >= and < is >>>>>> technically unspecified; if it were ever implemented as anything >>>>>> other than a binary comparison between integers (which it never is, >>>>>> now that no one has a segmented architecture), the comparison could >>>>>> pass spuriously, so checking would be a good thing. Of course, the >>>>>> comparison could fail spuriously, too. >>>>>> >>>>>> Anyway, I'm happy to leave it in as belt-and-suspenders (and add a >>>>>> comment, obviously, since it has caused confusion), or take it out. >>>>>> Your call. >>>>>> >>>>> >>>>> I'm still confused. >>>>> >>>>> How this code could possibly check anything? >>>>> ptrdiff_t idx = m - b->_methods; >>>>> if (b->_methods + idx == m) { >>>>> >>>>> The condition above always gives true: >>>>> b->_methods + (idx) == b->_methods + (m - b->_methods) == >>>>> (b->_methods- b->_methods) + m == (0 + m) == m >>>>> >>>>> Even if m was unaligned then at the end we compare m with m which is >>>>> still true. >>>>> Do I miss anything? >>>>> >>>> >>>> If 'm' is unaligned we would fail this comparison: >>>> >>>> (gdb) print &methods->_data[2] >>>> $34 = (Method **) 0x7fffe0022440 >>>> (gdb) print &methods->_data[0] >>>> $35 = (Method **) 0x7fffe0022430 >>>> (gdb) print 0x7fffe0022444 - 0x7fffe0022430 >>>> $32 = 20 >>>> >>> >>> I was confused about this too. What we have here is pointer >>> arithmetic, not regular arithmetic, so I'm assuming an unaligned value >>> has to be adjusted before the actual difference is computed. So in >>> practice: >>> >>> m - b->_methods >>> >>> is really >>> >>> adjusted_for_alignment(m) - b->_methods >>> >> >> It's not adjusted for alignment: >> > > Right - now I get it. Pointer difference is an algebraic subtraction with > "div sizeof what is pointed to". For aligned pointers there will be no > remainder and adding back the difference to the initial pointer will yield > the end pointer. But if one of the pointers is not aligned that is not the > case. > > All rather icky. > > Thanks, > David > ---- > > > #include >> >> extern "C" int printf(const char *,...); >> class Method { >> int i ; int j; int k; >> }; >> >> Method* array[10] = { new Method(),new Method(),new Method(),new >> Method(),new Method(),n >> ew Method(),new Method(),new Method(),new Method(),new Method() }; >> >> void test(Method** m) { >> printf("m is 0x%p ", m); >> ptrdiff_t idx = m - array; >> if (array + idx == m) { >> printf("true %ld\n", idx); >> } else { >> printf("false %ld\n", idx); >> } >> } >> main() { >> Method** xx = &array[3]; >> test(xx); >> test((Method**)(((char*)xx) - 2)); >> } >> >> cphilli% a.out >> m is 0x0x601098 true 3 >> m is 0x0x601096 false 2 >> >> >> Coleen >> >> >>> David >>> ----- >>> >>> (gdb) print 20/8 >>>> $33 = 2 >>>> >>>> if m is misaligned 0x7fffe0022444 the idx would be 2 and the expression >>>> (b->_methods + idx) would evaluate to the aligned 0xfffe0022440 so not >>>> equal m. >>>> >>>> But the code could check for misaligned m instead (or it would have >>>> already crashed). I think all bets are off if the address space is >>>> segmented. >>>> >>>> The comment Jeremy added is: >>>> >>>> if (b->_methods <= m && m < b->_methods + >>>> b->_number_of_methods) { >>>> // This is a bit of extra checking, for two reasons. One is >>>> // that contains() deals with pointers that are passed in by >>>> // JNI code, so making sure that the pointer is aligned >>>> // correctly is valuable. The other is that <= and > are >>>> // technically not defined on pointers, so the if guard can >>>> // pass spuriously; no modern compiler is likely to make that >>>> // a problem, though (and if one did, the guard could also >>>> // fail spuriously, which would be bad). >>>> ptrdiff_t idx = m - b->_methods; >>>> if (b->_methods + idx == m) { >>>> return true; >>>> } >>>> >>>> Coleen >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> ** >>>>> >>>>>> >>>>>> Jeremy >>>>>> >>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Thu Nov 6 10:05:48 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Thu, 06 Nov 2014 14:05:48 +0400 Subject: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545ADAD7.7040902@oracle.com> References: <545A4367.1070407@oracle.com> <545ADAD7.7040902@oracle.com> Message-ID: <545B47FC.1070305@oracle.com> Hi David, tag added because tests contain string cmd.addAll(JpsHelper.getVmArgs()); and JpsHelper defines ... public static final String[] VM_ARGS = {"-Xmx512m", "-XX:+UseParallelGC"}; ... public static List getVmArgs() throws IOException { if (testVmArgs == null) { testVmArgs = new ArrayList<>(); testVmArgs.addAll(Arrays.asList(VM_ARGS)); testVmArgs.add("-XX:Flags=" + getVmFlagsFile().getAbsolutePath()); } return testVmArgs; } Tests itself wouldn't fail if we use another GC, tag added for cleanup-if we use for example SerialGC we must be sure that tests passed with this GC, not with another one. Now you will assume that concrete test passed with Serial GC, but it run only with Parallel GC. Plus there is no any sense to run test twice in TC (with different GC, since it use only Parallel) Thanks, Evgeniya Stepanova On 06.11.2014 6:20, David Holmes wrote: > Hi Evgeniya, > > On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >> Hi, >> >> Please review changes for 8062536, the OpenJDK/jdk part of the >> JDK-8019361 >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >> >> Problem: Some tests explicitly set GC and fail when another GC is set >> outside > > I don't see why you have done this for the > > test/sun/tools/jps/TestJps*.java > > tests. They don't set any GC flags. > >> Solution: Such tests marked with the jtreg tag "requires" to skip test >> if there is a conflict > > Just wondering: Does a skipped test get a .jtr file showing it was > skipped; or does it only appear in the higher-level jtreg log? > > Thanks, > David > >> Tested locally with different GC flags (-XX:+UseG1GC, >> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without >> any GC flag). Tests are being excluded as expected. No tests failed >> because of the conflict. >> >> Thanks, >> Evgeniya Stepanova >> >> // -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.friberg at oracle.com Thu Nov 6 10:12:22 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 06 Nov 2014 11:12:22 +0100 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <5416D64C.9020207@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> Message-ID: <545B4986.1050700@oracle.com> Hi, After further off list discussion it was decided to keep the gc_tracer in par_promote as is. I have uploaded a new webrev, http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05 The main change here is a rewrite of the G1 code which is cleaner and also reuses the read age. By sending the markOop down through the call we can now trust the read age and do not need to reread it when incrementing which improves the YC performance slightly as it avoids the rather complex bit extraction. Cheers, Staffan On 09/15/2014 02:06 PM, Bengt Rutisson wrote: > > Hi Staffan, > > psPromotionManager.inline.hpp > > I think the PSPromotionManager::copy_to_survivor_space() might send > multiple events. If the allocation to the young gen fails we will fall > through to do an old gen allocation. But we send the events before we > realize that the allocation has failed, i.e. new_obj is NULL. > > I talked to Erik a bit about how to handle the gc_tracer in > par_promote. He'll get back to you with some thoughts on that. > > Thanks, > Bengt > > > On 2014-09-06 00:20, Staffan Friberg wrote: >> Hi, >> >> I have uploaded a new webrev here, >> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >> >> It contains several changes >> >> - Split event into two events (PromoteObjectInNewPLAB, >> PromoteObjectOutsidePLAB) >> - Moved events to "vm/gc/detailed/PromoteObject..." >> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >> - Not sure if the way I do it with passing the ParNewTracer >> is the best solution, please let me know if you have an idea how to >> improve it >> - Simplified the G1 code to avoid sending age and having a single >> call site >> - Fixed so that the generated event has size information in bytes >> rather than words >> >> Thanks for offline comments and suggestions from Dmitry and Thomas. >> >> Cheers, >> Staffan >> >> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>> Hi Erik, >>> >>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in >>>> this thread, I'm adding it back) >>>> >>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>> Hi Erik, >>>>> >>>>> Thanks for the comments. >>>>>> - Aren't the events for promotion to the tenured generation >>>>>> (SerialOld) >>>>>> and the CMS generation missing? >>>>> The reason for leaving out these two, Serial completely and CMS >>>>> promotion, was due to that neither as far as I understand make use of >>>>> PLABs. >>>> >>>> I might be wrong here, but looking at the function >>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks >>>> to me like SerialOld is using PLABs when ParNew is promoting >>>> objects from young to old. >>>> >>>> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote >>>> (in concurrentMarkSweepGeneration.cpp) it seems like each >>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local >>>> Allocation Buffer) that is a thread-local allocation buffer. See >>>> compactibleFreeListSpace.{hpp,cpp} for more details. >>>> >>>> Given this, I think we should add events for Serial and CMS as well. >>>> >>> >>> Ok I see what you mean with CMS, basically the equivalent to getting >>> a PLAB would be when we refill the CFLS_LAB in the alloc function. >>> It still does the allocation to a small memory (~ size of object) >>> area from the freelist, but at least we did extra work to refill the >>> local CFLS_LAB. Need to do some analysis to see how often we refill >>> so the overhead doesn't get too high. >>> The only issue I run into is how I can in a nice way get access to >>> the ParNewTracer from ParNewGeneration to call the report function. >>> Let's sync up next week and see how it can be solved. >>> >>> The tenured GC requires something similar to be supported, however >>> since ParNewGC is deprecated for usage without CMS in JDK 8 we might >>> want to skip that combination. >>> >>> >>>> >>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>> - Would it make sense to differentiate, either by separate events >>>>>> or by >>>>>> a field in a event, between promotions to to-space and to the old >>>>>> generation? >>>>>> - The are two events for TLAB allocations, >>>>>> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >>>>>> What do you think about using two events for PLAB allocations >>>>>> as well: >>>>>> - java/object_alloc_in_new_PLAB >>>>>> - java/object_alloc_outside_PLAB >>>>> I think this is a matter of taste and probably how similar we want >>>>> the >>>>> event to be to the existing allocation event. I personally prefer a >>>>> single event but if the GC team and serviceability team feel it >>>>> would be >>>>> better to have two I can certainly rewrite. The reason for me >>>>> preferring >>>>> a single event is just ease of analysis, you can easily filter a >>>>> list of >>>>> events on a field, it is harder to merge two different events with >>>>> different fields and work with them in an straight forward fashion. >>>>> >>>>> Any general preference for having a single or multiple events? >>>> >>>> I would prefer to have two events in this case and try to follow >>>> the existing allocation events as much as possible (both in naming >>>> and in style). Keeping the tenured field (I missed it the first >>>> time I read the patch) is good. >>>> >>> Yes, tenured would be independent of having two events, only PLAB >>> size and directAllocation would be affected when having two event types. >>> >>> *Erik Gahlin*, any preference from your end? >>> >>> >>> >>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>> - In PSPromotionManager, instead of utilizing the C++ friendship >>>>>> with >>>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>>> Created a getter function. >>>> >>>> Thanks! If you make report_promotion_sample const, then the getter >>>> can return a const ParallelScavengeTracer*, right? >>>> >>> Done >>> >>> //Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Nov 6 10:13:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Nov 2014 20:13:23 +1000 Subject: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B47FC.1070305@oracle.com> References: <545A4367.1070407@oracle.com> <545ADAD7.7040902@oracle.com> <545B47FC.1070305@oracle.com> Message-ID: <545B49C3.2040007@oracle.com> On 6/11/2014 8:05 PM, Evgeniya Stepanova wrote: > Hi David, > > tag added because tests contain string > cmd.addAll(JpsHelper.getVmArgs()); > > and JpsHelper defines > ... > public static final String[] VM_ARGS = {"-Xmx512m", "-XX:+UseParallelGC"}; Ah I see! Strange. Thanks for clarifying. Looks okay then. David ----- > ... > public static List getVmArgs() throws IOException { > if (testVmArgs == null) { > testVmArgs = new ArrayList<>(); > testVmArgs.addAll(Arrays.asList(VM_ARGS)); > testVmArgs.add("-XX:Flags=" + > getVmFlagsFile().getAbsolutePath()); > } > return testVmArgs; > } > > Tests itself wouldn't fail if we use another GC, tag added for > cleanup-if we use for example SerialGC we must be sure that tests passed > with this GC, not with another one. Now you will assume that concrete > test passed with Serial GC, but it run only with Parallel GC. Plus there > is no any sense to run test twice in TC (with different GC, since it use > only Parallel) > > Thanks, > Evgeniya Stepanova > On 06.11.2014 6:20, David Holmes wrote: >> Hi Evgeniya, >> >> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>> Hi, >>> >>> Please review changes for 8062536, the OpenJDK/jdk part of the >>> JDK-8019361 >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>> >>> Problem: Some tests explicitly set GC and fail when another GC is set >>> outside >> >> I don't see why you have done this for the >> >> test/sun/tools/jps/TestJps*.java >> >> tests. They don't set any GC flags. >> >>> Solution: Such tests marked with the jtreg tag "requires" to skip test >>> if there is a conflict >> >> Just wondering: Does a skipped test get a .jtr file showing it was >> skipped; or does it only appear in the higher-level jtreg log? >> >> Thanks, >> David >> >>> Tested locally with different GC flags (-XX:+UseG1GC, >>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without >>> any GC flag). Tests are being excluded as expected. No tests failed >>> because of the conflict. >>> >>> Thanks, >>> Evgeniya Stepanova >>> >>> // > > -- > /Evgeniya Stepanova/ From yekaterina.kantserova at oracle.com Thu Nov 6 10:27:24 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 06 Nov 2014 11:27:24 +0100 Subject: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B47FC.1070305@oracle.com> References: <545A4367.1070407@oracle.com> <545ADAD7.7040902@oracle.com> <545B47FC.1070305@oracle.com> Message-ID: <545B4D0C.2010005@oracle.com> Hi Evgeniya, As David has pointed out these jps tests are not testing gc. The -XX:+UseParallelGC is just an arbitrary chosen test flag. There should not be any conflicts either since these tests are running in driver mode: ... * @run driver TestJpsJar ... which means no flags from above are accepted. Thanks, Katja On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: > Hi David, > > tag added because tests contain string > cmd.addAll(JpsHelper.getVmArgs()); > > and JpsHelper defines > ... > public static final String[] VM_ARGS = {"-Xmx512m", "-XX:+UseParallelGC"}; > ... > public static List getVmArgs() throws IOException { > if (testVmArgs == null) { > testVmArgs = new ArrayList<>(); > testVmArgs.addAll(Arrays.asList(VM_ARGS)); > testVmArgs.add("-XX:Flags=" + > getVmFlagsFile().getAbsolutePath()); > } > return testVmArgs; > } > > Tests itself wouldn't fail if we use another GC, tag added for > cleanup-if we use for example SerialGC we must be sure that tests > passed with this GC, not with another one. Now you will assume that > concrete test passed with Serial GC, but it run only with Parallel GC. > Plus there is no any sense to run test twice in TC (with different GC, > since it use only Parallel) > > Thanks, > Evgeniya Stepanova > On 06.11.2014 6:20, David Holmes wrote: >> Hi Evgeniya, >> >> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>> Hi, >>> >>> Please review changes for 8062536, the OpenJDK/jdk part of the >>> JDK-8019361 >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>> >>> Problem: Some tests explicitly set GC and fail when another GC is set >>> outside >> >> I don't see why you have done this for the >> >> test/sun/tools/jps/TestJps*.java >> >> tests. They don't set any GC flags. >> >>> Solution: Such tests marked with the jtreg tag "requires" to skip test >>> if there is a conflict >> >> Just wondering: Does a skipped test get a .jtr file showing it was >> skipped; or does it only appear in the higher-level jtreg log? >> >> Thanks, >> David >> >>> Tested locally with different GC flags (-XX:+UseG1GC, >>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without >>> any GC flag). Tests are being excluded as expected. No tests failed >>> because of the conflict. >>> >>> Thanks, >>> Evgeniya Stepanova >>> >>> // > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Thu Nov 6 10:55:07 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 06 Nov 2014 11:55:07 +0100 Subject: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B4D0C.2010005@oracle.com> References: <545A4367.1070407@oracle.com> <545ADAD7.7040902@oracle.com> <545B47FC.1070305@oracle.com> <545B4D0C.2010005@oracle.com> Message-ID: <545B538B.4060403@oracle.com> If it's confusing the tests are using -XX:+UseParallelGC we can change them to use some other neutral flag. "Plus there is no any sense to run test twice in TC (with different GC, since it use only Parallel)" I agree it's meaningless to run them with all possible GC combinations because these tests are GC neutral. // Katja On 11/06/2014 11:27 AM, Yekaterina Kantserova wrote: > Hi Evgeniya, > > As David has pointed out these jps tests are not testing gc. The > -XX:+UseParallelGC is just an arbitrary chosen test flag. There should > not be any conflicts either since these tests are running in driver mode: > > ... > * @run driver TestJpsJar > ... > > which means no flags from above are accepted. > > Thanks, > Katja > > > > On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >> Hi David, >> >> tag added because tests contain string >> cmd.addAll(JpsHelper.getVmArgs()); >> >> and JpsHelper defines >> ... >> public static final String[] VM_ARGS = {"-Xmx512m", >> "-XX:+UseParallelGC"}; >> ... >> public static List getVmArgs() throws IOException { >> if (testVmArgs == null) { >> testVmArgs = new ArrayList<>(); >> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >> testVmArgs.add("-XX:Flags=" + >> getVmFlagsFile().getAbsolutePath()); >> } >> return testVmArgs; >> } >> >> Tests itself wouldn't fail if we use another GC, tag added for >> cleanup-if we use for example SerialGC we must be sure that tests >> passed with this GC, not with another one. Now you will assume that >> concrete test passed with Serial GC, but it run only with Parallel >> GC. Plus there is no any sense to run test twice in TC (with >> different GC, since it use only Parallel) >> >> Thanks, >> Evgeniya Stepanova >> On 06.11.2014 6:20, David Holmes wrote: >>> Hi Evgeniya, >>> >>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>> Hi, >>>> >>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>> JDK-8019361 >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>> >>>> Problem: Some tests explicitly set GC and fail when another GC is set >>>> outside >>> >>> I don't see why you have done this for the >>> >>> test/sun/tools/jps/TestJps*.java >>> >>> tests. They don't set any GC flags. >>> >>>> Solution: Such tests marked with the jtreg tag "requires" to skip test >>>> if there is a conflict >>> >>> Just wondering: Does a skipped test get a .jtr file showing it was >>> skipped; or does it only appear in the higher-level jtreg log? >>> >>> Thanks, >>> David >>> >>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>> without >>>> any GC flag). Tests are being excluded as expected. No tests failed >>>> because of the conflict. >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> >>>> // >> >> -- >> /Evgeniya Stepanova/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu Nov 6 11:01:52 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 06 Nov 2014 12:01:52 +0100 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <545B4986.1050700@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> <545B4986.1050700@oracle.com> Message-ID: <545B5520.7010407@oracle.com> Hi Staffan, On 2014-11-06 11:12, Staffan Friberg wrote: > Hi, > > After further off list discussion it was decided to keep the gc_tracer > in par_promote as is. > > I have uploaded a new webrev, > http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05 > > The main change here is a rewrite of the G1 code which is cleaner and > also reuses the read age. By sending the markOop down through the call > we can now trust the read age and do not need to reread it when > incrementing which improves the YC performance slightly as it avoids > the rather complex bit extraction. Looks good to me. One detail in parNewGeneration.cpp: 274 } else { 275 // Too large; allocate the object individually. 276 gc_tracer()->report_promotion_outside_plab_event(old, word_sz, age, false); 277 obj = sp->par_allocate(word_sz); 278 } Seems like par_allocate() return NULL. Maybe we should check that before reporting the event. Similarly to what you do in the other GCs, for example G1: g1Allocator.cpp 141 obj = _g1h->par_allocate_during_gc(purpose, word_sz, context); 142 if (obj != NULL 143 && _g1h->_gc_tracer_stw->should_report_promotion_outside_plab_event()) { 144 bool tenured = _g1h->heap_region_containing_raw(obj)->is_old(); 145 _g1h->_gc_tracer_stw->report_promotion_outside_plab_event(old, word_sz, 146 age, tenured); 147 } Thanks, Bengt > > Cheers, > Staffan > > On 09/15/2014 02:06 PM, Bengt Rutisson wrote: >> >> Hi Staffan, >> >> psPromotionManager.inline.hpp >> >> I think the PSPromotionManager::copy_to_survivor_space() might send >> multiple events. If the allocation to the young gen fails we will >> fall through to do an old gen allocation. But we send the events >> before we realize that the allocation has failed, i.e. new_obj is NULL. >> >> I talked to Erik a bit about how to handle the gc_tracer in >> par_promote. He'll get back to you with some thoughts on that. >> >> Thanks, >> Bengt >> >> >> On 2014-09-06 00:20, Staffan Friberg wrote: >>> Hi, >>> >>> I have uploaded a new webrev here, >>> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >>> >>> It contains several changes >>> >>> - Split event into two events (PromoteObjectInNewPLAB, >>> PromoteObjectOutsidePLAB) >>> - Moved events to "vm/gc/detailed/PromoteObject..." >>> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >>> - Not sure if the way I do it with passing the ParNewTracer >>> is the best solution, please let me know if you have an idea how to >>> improve it >>> - Simplified the G1 code to avoid sending age and having a >>> single call site >>> - Fixed so that the generated event has size information in >>> bytes rather than words >>> >>> Thanks for offline comments and suggestions from Dmitry and Thomas. >>> >>> Cheers, >>> Staffan >>> >>> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>>> Hi Erik, >>>> >>>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere >>>>> in this thread, I'm adding it back) >>>>> >>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>> Hi Erik, >>>>>> >>>>>> Thanks for the comments. >>>>>>> - Aren't the events for promotion to the tenured generation >>>>>>> (SerialOld) >>>>>>> and the CMS generation missing? >>>>>> The reason for leaving out these two, Serial completely and CMS >>>>>> promotion, was due to that neither as far as I understand make >>>>>> use of >>>>>> PLABs. >>>>> >>>>> I might be wrong here, but looking at the function >>>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks >>>>> to me like SerialOld is using PLABs when ParNew is promoting >>>>> objects from young to old. >>>>> >>>>> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote >>>>> (in concurrentMarkSweepGeneration.cpp) it seems like each >>>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local >>>>> Allocation Buffer) that is a thread-local allocation buffer. See >>>>> compactibleFreeListSpace.{hpp,cpp} for more details. >>>>> >>>>> Given this, I think we should add events for Serial and CMS as well. >>>>> >>>> >>>> Ok I see what you mean with CMS, basically the equivalent to >>>> getting a PLAB would be when we refill the CFLS_LAB in the alloc >>>> function. It still does the allocation to a small memory (~ size of >>>> object) area from the freelist, but at least we did extra work to >>>> refill the local CFLS_LAB. Need to do some analysis to see how >>>> often we refill so the overhead doesn't get too high. >>>> The only issue I run into is how I can in a nice way get access to >>>> the ParNewTracer from ParNewGeneration to call the report function. >>>> Let's sync up next week and see how it can be solved. >>>> >>>> The tenured GC requires something similar to be supported, however >>>> since ParNewGC is deprecated for usage without CMS in JDK 8 we >>>> might want to skip that combination. >>>> >>>> >>>>> >>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>> - Would it make sense to differentiate, either by separate >>>>>>> events or by >>>>>>> a field in a event, between promotions to to-space and to the old >>>>>>> generation? >>>>>>> - The are two events for TLAB allocations, >>>>>>> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >>>>>>> What do you think about using two events for PLAB allocations >>>>>>> as well: >>>>>>> - java/object_alloc_in_new_PLAB >>>>>>> - java/object_alloc_outside_PLAB >>>>>> I think this is a matter of taste and probably how similar we >>>>>> want the >>>>>> event to be to the existing allocation event. I personally prefer a >>>>>> single event but if the GC team and serviceability team feel it >>>>>> would be >>>>>> better to have two I can certainly rewrite. The reason for me >>>>>> preferring >>>>>> a single event is just ease of analysis, you can easily filter a >>>>>> list of >>>>>> events on a field, it is harder to merge two different events with >>>>>> different fields and work with them in an straight forward fashion. >>>>>> >>>>>> Any general preference for having a single or multiple events? >>>>> >>>>> I would prefer to have two events in this case and try to follow >>>>> the existing allocation events as much as possible (both in naming >>>>> and in style). Keeping the tenured field (I missed it the first >>>>> time I read the patch) is good. >>>>> >>>> Yes, tenured would be independent of having two events, only PLAB >>>> size and directAllocation would be affected when having two event >>>> types. >>>> >>>> *Erik Gahlin*, any preference from your end? >>>> >>>> >>>> >>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>> - In PSPromotionManager, instead of utilizing the C++ friendship >>>>>>> with >>>>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>>>> Created a getter function. >>>>> >>>>> Thanks! If you make report_promotion_sample const, then the getter >>>>> can return a const ParallelScavengeTracer*, right? >>>>> >>>> Done >>>> >>>> //Staffan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.fazunenko at oracle.com Thu Nov 6 10:22:46 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 06 Nov 2014 14:22:46 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B51A1.7080905@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> Message-ID: <545B4BF6.4040209@oracle.com> Hi Katja, You are right, there will be no conflict, because test ignores any external VM flags. So, adding @requires seems unnecessary here, but... Ignoring external options is bad thing, such "selfish" tests are not applicable for other areas, like GC, compiler, RT. @requires will allow to modify tests to include external vm options without any risk of bumping into conflict and extend area of test applicability. But if you still believe, that @requires is not necessary - it's not a problem, tests could be kept as is. Thanks, Dima On 06.11.2014 16:27, Yekaterina Kantserova wrote: > > Hi Evgeniya, > > As David has pointed out these jps tests are not testing gc. The > -XX:+UseParallelGC is just an arbitrary chosen test flag. There should > not be any conflicts either since these tests are running in driver mode: > > ... > * @run driver TestJpsJar > ... > > which means no flags from above are accepted. > > Thanks, > Katja > > > > On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >> Hi David, >> >> tag added because tests contain string >> cmd.addAll(JpsHelper.getVmArgs()); >> >> and JpsHelper defines >> ... >> public static final String[] VM_ARGS = {"-Xmx512m", >> "-XX:+UseParallelGC"}; >> ... >> public static List getVmArgs() throws IOException { >> if (testVmArgs == null) { >> testVmArgs = new ArrayList<>(); >> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >> testVmArgs.add("-XX:Flags=" + >> getVmFlagsFile().getAbsolutePath()); >> } >> return testVmArgs; >> } >> >> Tests itself wouldn't fail if we use another GC, tag added for >> cleanup-if we use for example SerialGC we must be sure that tests >> passed with this GC, not with another one. Now you will assume that >> concrete test passed with Serial GC, but it run only with Parallel >> GC. Plus there is no any sense to run test twice in TC (with >> different GC, since it use only Parallel) >> >> Thanks, >> Evgeniya Stepanova >> On 06.11.2014 6:20, David Holmes wrote: >>> Hi Evgeniya, >>> >>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>> Hi, >>>> >>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>> JDK-8019361 >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>> >>>> Problem: Some tests explicitly set GC and fail when another GC is set >>>> outside >>> >>> I don't see why you have done this for the >>> >>> test/sun/tools/jps/TestJps*.java >>> >>> tests. They don't set any GC flags. >>> >>>> Solution: Such tests marked with the jtreg tag "requires" to skip test >>>> if there is a conflict >>> >>> Just wondering: Does a skipped test get a .jtr file showing it was >>> skipped; or does it only appear in the higher-level jtreg log? >>> >>> Thanks, >>> David >>> >>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>> without >>>> any GC flag). Tests are being excluded as expected. No tests failed >>>> because of the conflict. >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> >>>> // >> >> -- >> /Evgeniya Stepanova/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Thu Nov 6 12:56:38 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 06 Nov 2014 13:56:38 +0100 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B4BF6.4040209@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> Message-ID: <545B7006.5080104@oracle.com> Hi Dima, On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: > Hi Katja, > > You are right, there will be no conflict, because test ignores any > external VM flags. > So, adding @requires seems unnecessary here, but... > > Ignoring external options is bad thing, such "selfish" tests are not > applicable for other areas, like GC, compiler, RT. This particular case is to test the defined flags are shown up as expected. Evgeniya, would you mind to change JpsHelper.java instead? +++ b/test/sun/tools/jps/JpsHelper.java @@ -93,7 +93,7 @@ /** * VM arguments to start test application with */ - public static final String[] VM_ARGS = {"-Xmx512m", "-XX:+UseParallelGC"}; + public static final String[] VM_ARGS = {"-Xmx512m", "-XX:+PrintGCDetails"}; /** * VM flag to start test application with */ Best regards, Katja > > @requires will allow to modify tests to include external vm options > without any risk of bumping into conflict and extend area of test > applicability. > > But if you still believe, that @requires is not necessary - it's not a > problem, tests could be kept as is. > > Thanks, > Dima > > > On 06.11.2014 16:27, Yekaterina Kantserova wrote: >> >> Hi Evgeniya, >> >> As David has pointed out these jps tests are not testing gc. The >> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >> should not be any conflicts either since these tests are running in >> driver mode: >> >> ... >> * @run driver TestJpsJar >> ... >> >> which means no flags from above are accepted. >> >> Thanks, >> Katja >> >> >> >> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>> Hi David, >>> >>> tag added because tests contain string >>> cmd.addAll(JpsHelper.getVmArgs()); >>> >>> and JpsHelper defines >>> ... >>> public static final String[] VM_ARGS = {"-Xmx512m", >>> "-XX:+UseParallelGC"}; >>> ... >>> public static List getVmArgs() throws IOException { >>> if (testVmArgs == null) { >>> testVmArgs = new ArrayList<>(); >>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>> testVmArgs.add("-XX:Flags=" + >>> getVmFlagsFile().getAbsolutePath()); >>> } >>> return testVmArgs; >>> } >>> >>> Tests itself wouldn't fail if we use another GC, tag added for >>> cleanup-if we use for example SerialGC we must be sure that tests >>> passed with this GC, not with another one. Now you will assume that >>> concrete test passed with Serial GC, but it run only with Parallel >>> GC. Plus there is no any sense to run test twice in TC (with >>> different GC, since it use only Parallel) >>> >>> Thanks, >>> Evgeniya Stepanova >>> On 06.11.2014 6:20, David Holmes wrote: >>>> Hi Evgeniya, >>>> >>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>> Hi, >>>>> >>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>> JDK-8019361 >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>> >>>>> Problem: Some tests explicitly set GC and fail when another GC is set >>>>> outside >>>> >>>> I don't see why you have done this for the >>>> >>>> test/sun/tools/jps/TestJps*.java >>>> >>>> tests. They don't set any GC flags. >>>> >>>>> Solution: Such tests marked with the jtreg tag "requires" to skip >>>>> test >>>>> if there is a conflict >>>> >>>> Just wondering: Does a skipped test get a .jtr file showing it was >>>> skipped; or does it only appear in the higher-level jtreg log? >>>> >>>> Thanks, >>>> David >>>> >>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>> without >>>>> any GC flag). Tests are being excluded as expected. No tests failed >>>>> because of the conflict. >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> >>>>> // >>> >>> -- >>> /Evgeniya Stepanova/ >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.friberg at oracle.com Thu Nov 6 13:00:02 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 06 Nov 2014 14:00:02 +0100 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <545B5520.7010407@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> <545B4986.1050700@oracle.com> <545B5520.7010407@oracle.com> Message-ID: <545B70D2.9080008@oracle.com> Good catch, fixed. // Too large; allocate the object individually. obj = sp->par_allocate(word_sz); if (obj != NULL) { gc_tracer()->report_promotion_outside_plab_event(old, word_sz, age, false); } Please let me know if anyone wants a full new webrev with this. Thanks, Staffan On 11/06/2014 12:01 PM, Bengt Rutisson wrote: > > Hi Staffan, > > On 2014-11-06 11:12, Staffan Friberg wrote: >> Hi, >> >> After further off list discussion it was decided to keep the >> gc_tracer in par_promote as is. >> >> I have uploaded a new webrev, >> http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05 >> >> The main change here is a rewrite of the G1 code which is cleaner and >> also reuses the read age. By sending the markOop down through the >> call we can now trust the read age and do not need to reread it when >> incrementing which improves the YC performance slightly as it avoids >> the rather complex bit extraction. > > > Looks good to me. One detail in parNewGeneration.cpp: > > 274 } else { > 275 // Too large; allocate the object individually. > 276 gc_tracer()->report_promotion_outside_plab_event(old, word_sz, > age, false); > 277 obj = sp->par_allocate(word_sz); > 278 } > > Seems like par_allocate() return NULL. Maybe we should check that > before reporting the event. Similarly to what you do in the other GCs, > for example G1: > > g1Allocator.cpp > > 141 obj = _g1h->par_allocate_during_gc(purpose, word_sz, context); > 142 if (obj != NULL > 143 && > _g1h->_gc_tracer_stw->should_report_promotion_outside_plab_event()) { > 144 bool tenured = _g1h->heap_region_containing_raw(obj)->is_old(); > 145 _g1h->_gc_tracer_stw->report_promotion_outside_plab_event(old, > word_sz, > 146 age, tenured); > 147 } > > Thanks, > Bengt > > > >> >> Cheers, >> Staffan >> >> On 09/15/2014 02:06 PM, Bengt Rutisson wrote: >>> >>> Hi Staffan, >>> >>> psPromotionManager.inline.hpp >>> >>> I think the PSPromotionManager::copy_to_survivor_space() might send >>> multiple events. If the allocation to the young gen fails we will >>> fall through to do an old gen allocation. But we send the events >>> before we realize that the allocation has failed, i.e. new_obj is NULL. >>> >>> I talked to Erik a bit about how to handle the gc_tracer in >>> par_promote. He'll get back to you with some thoughts on that. >>> >>> Thanks, >>> Bengt >>> >>> >>> On 2014-09-06 00:20, Staffan Friberg wrote: >>>> Hi, >>>> >>>> I have uploaded a new webrev here, >>>> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >>>> >>>> It contains several changes >>>> >>>> - Split event into two events (PromoteObjectInNewPLAB, >>>> PromoteObjectOutsidePLAB) >>>> - Moved events to "vm/gc/detailed/PromoteObject..." >>>> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >>>> - Not sure if the way I do it with passing the >>>> ParNewTracer is the best solution, please let me know if you have >>>> an idea how to improve it >>>> - Simplified the G1 code to avoid sending age and having a >>>> single call site >>>> - Fixed so that the generated event has size information in >>>> bytes rather than words >>>> >>>> Thanks for offline comments and suggestions from Dmitry and Thomas. >>>> >>>> Cheers, >>>> Staffan >>>> >>>> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>>>> Hi Erik, >>>>> >>>>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere >>>>>> in this thread, I'm adding it back) >>>>>> >>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> Thanks for the comments. >>>>>>>> - Aren't the events for promotion to the tenured generation >>>>>>>> (SerialOld) >>>>>>>> and the CMS generation missing? >>>>>>> The reason for leaving out these two, Serial completely and CMS >>>>>>> promotion, was due to that neither as far as I understand make >>>>>>> use of >>>>>>> PLABs. >>>>>> >>>>>> I might be wrong here, but looking at the function >>>>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it >>>>>> looks to me like SerialOld is using PLABs when ParNew is >>>>>> promoting objects from young to old. >>>>>> >>>>>> As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote >>>>>> (in concurrentMarkSweepGeneration.cpp) it seems like each >>>>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace >>>>>> Local Allocation Buffer) that is a thread-local allocation >>>>>> buffer. See compactibleFreeListSpace.{hpp,cpp} for more details. >>>>>> >>>>>> Given this, I think we should add events for Serial and CMS as well. >>>>>> >>>>> >>>>> Ok I see what you mean with CMS, basically the equivalent to >>>>> getting a PLAB would be when we refill the CFLS_LAB in the alloc >>>>> function. It still does the allocation to a small memory (~ size >>>>> of object) area from the freelist, but at least we did extra work >>>>> to refill the local CFLS_LAB. Need to do some analysis to see how >>>>> often we refill so the overhead doesn't get too high. >>>>> The only issue I run into is how I can in a nice way get access to >>>>> the ParNewTracer from ParNewGeneration to call the report >>>>> function. Let's sync up next week and see how it can be solved. >>>>> >>>>> The tenured GC requires something similar to be supported, however >>>>> since ParNewGC is deprecated for usage without CMS in JDK 8 we >>>>> might want to skip that combination. >>>>> >>>>> >>>>>> >>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>> - Would it make sense to differentiate, either by separate >>>>>>>> events or by >>>>>>>> a field in a event, between promotions to to-space and to the >>>>>>>> old >>>>>>>> generation? >>>>>>>> - The are two events for TLAB allocations, >>>>>>>> java/object_alloc_in_new_TLAB and >>>>>>>> java/object_alloc_outside_TLAB. >>>>>>>> What do you think about using two events for PLAB allocations >>>>>>>> as well: >>>>>>>> - java/object_alloc_in_new_PLAB >>>>>>>> - java/object_alloc_outside_PLAB >>>>>>> I think this is a matter of taste and probably how similar we >>>>>>> want the >>>>>>> event to be to the existing allocation event. I personally prefer a >>>>>>> single event but if the GC team and serviceability team feel it >>>>>>> would be >>>>>>> better to have two I can certainly rewrite. The reason for me >>>>>>> preferring >>>>>>> a single event is just ease of analysis, you can easily filter a >>>>>>> list of >>>>>>> events on a field, it is harder to merge two different events with >>>>>>> different fields and work with them in an straight forward fashion. >>>>>>> >>>>>>> Any general preference for having a single or multiple events? >>>>>> >>>>>> I would prefer to have two events in this case and try to follow >>>>>> the existing allocation events as much as possible (both in >>>>>> naming and in style). Keeping the tenured field (I missed it the >>>>>> first time I read the patch) is good. >>>>>> >>>>> Yes, tenured would be independent of having two events, only PLAB >>>>> size and directAllocation would be affected when having two event >>>>> types. >>>>> >>>>> *Erik Gahlin*, any preference from your end? >>>>> >>>>> >>>>> >>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>> - In PSPromotionManager, instead of utilizing the C++ >>>>>>>> friendship with >>>>>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>>>>> Created a getter function. >>>>>> >>>>>> Thanks! If you make report_promotion_sample const, then the >>>>>> getter can return a const ParallelScavengeTracer*, right? >>>>>> >>>>> Done >>>>> >>>>> //Staffan >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu Nov 6 12:53:44 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 06 Nov 2014 13:53:44 +0100 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <545B70D2.9080008@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> <545B4986.1050700@oracle.com> <545B5520.7010407@oracle.com> <545B70D2.9080008@oracle.com> Message-ID: <545B6F58.2000907@oracle.com> On 2014-11-06 14:00, Staffan Friberg wrote: > Good catch, fixed. > > // Too large; allocate the object individually. > obj = sp->par_allocate(word_sz); > if (obj != NULL) { > gc_tracer()->report_promotion_outside_plab_event(old, word_sz, > age, false); > } > > Please let me know if anyone wants a full new webrev with this. Looks good. Reviewed. Bengt > > Thanks, > Staffan > > > On 11/06/2014 12:01 PM, Bengt Rutisson wrote: >> >> Hi Staffan, >> >> On 2014-11-06 11:12, Staffan Friberg wrote: >>> Hi, >>> >>> After further off list discussion it was decided to keep the >>> gc_tracer in par_promote as is. >>> >>> I have uploaded a new webrev, >>> http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05 >>> >>> The main change here is a rewrite of the G1 code which is cleaner >>> and also reuses the read age. By sending the markOop down through >>> the call we can now trust the read age and do not need to reread it >>> when incrementing which improves the YC performance slightly as it >>> avoids the rather complex bit extraction. >> >> >> Looks good to me. One detail in parNewGeneration.cpp: >> >> 274 } else { >> 275 // Too large; allocate the object individually. >> 276 gc_tracer()->report_promotion_outside_plab_event(old, word_sz, >> age, false); >> 277 obj = sp->par_allocate(word_sz); >> 278 } >> >> Seems like par_allocate() return NULL. Maybe we should check that >> before reporting the event. Similarly to what you do in the other >> GCs, for example G1: >> >> g1Allocator.cpp >> >> 141 obj = _g1h->par_allocate_during_gc(purpose, word_sz, context); >> 142 if (obj != NULL >> 143 && >> _g1h->_gc_tracer_stw->should_report_promotion_outside_plab_event()) { >> 144 bool tenured = >> _g1h->heap_region_containing_raw(obj)->is_old(); >> 145 _g1h->_gc_tracer_stw->report_promotion_outside_plab_event(old, >> word_sz, >> 146 age, tenured); >> 147 } >> >> Thanks, >> Bengt >> >> >> >>> >>> Cheers, >>> Staffan >>> >>> On 09/15/2014 02:06 PM, Bengt Rutisson wrote: >>>> >>>> Hi Staffan, >>>> >>>> psPromotionManager.inline.hpp >>>> >>>> I think the PSPromotionManager::copy_to_survivor_space() might send >>>> multiple events. If the allocation to the young gen fails we will >>>> fall through to do an old gen allocation. But we send the events >>>> before we realize that the allocation has failed, i.e. new_obj is NULL. >>>> >>>> I talked to Erik a bit about how to handle the gc_tracer in >>>> par_promote. He'll get back to you with some thoughts on that. >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 2014-09-06 00:20, Staffan Friberg wrote: >>>>> Hi, >>>>> >>>>> I have uploaded a new webrev here, >>>>> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >>>>> >>>>> It contains several changes >>>>> >>>>> - Split event into two events (PromoteObjectInNewPLAB, >>>>> PromoteObjectOutsidePLAB) >>>>> - Moved events to "vm/gc/detailed/PromoteObject..." >>>>> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >>>>> - Not sure if the way I do it with passing the >>>>> ParNewTracer is the best solution, please let me know if you have >>>>> an idea how to improve it >>>>> - Simplified the G1 code to avoid sending age and having a >>>>> single call site >>>>> - Fixed so that the generated event has size information in >>>>> bytes rather than words >>>>> >>>>> Thanks for offline comments and suggestions from Dmitry and Thomas. >>>>> >>>>> Cheers, >>>>> Staffan >>>>> >>>>> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>>>>> Hi Erik, >>>>>> >>>>>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>>>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere >>>>>>> in this thread, I'm adding it back) >>>>>>> >>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> Thanks for the comments. >>>>>>>>> - Aren't the events for promotion to the tenured generation >>>>>>>>> (SerialOld) >>>>>>>>> and the CMS generation missing? >>>>>>>> The reason for leaving out these two, Serial completely and CMS >>>>>>>> promotion, was due to that neither as far as I understand make >>>>>>>> use of >>>>>>>> PLABs. >>>>>>> >>>>>>> I might be wrong here, but looking at the function >>>>>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it >>>>>>> looks to me like SerialOld is using PLABs when ParNew is >>>>>>> promoting objects from young to old. >>>>>>> >>>>>>> As for CMS, looking at >>>>>>> ConcurrentMarkSweepGeneration::par_promote (in >>>>>>> concurrentMarkSweepGeneration.cpp) it seems like each >>>>>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace >>>>>>> Local Allocation Buffer) that is a thread-local allocation >>>>>>> buffer. See compactibleFreeListSpace.{hpp,cpp} for more details. >>>>>>> >>>>>>> Given this, I think we should add events for Serial and CMS as >>>>>>> well. >>>>>>> >>>>>> >>>>>> Ok I see what you mean with CMS, basically the equivalent to >>>>>> getting a PLAB would be when we refill the CFLS_LAB in the alloc >>>>>> function. It still does the allocation to a small memory (~ size >>>>>> of object) area from the freelist, but at least we did extra work >>>>>> to refill the local CFLS_LAB. Need to do some analysis to see how >>>>>> often we refill so the overhead doesn't get too high. >>>>>> The only issue I run into is how I can in a nice way get access >>>>>> to the ParNewTracer from ParNewGeneration to call the report >>>>>> function. Let's sync up next week and see how it can be solved. >>>>>> >>>>>> The tenured GC requires something similar to be supported, >>>>>> however since ParNewGC is deprecated for usage without CMS in JDK >>>>>> 8 we might want to skip that combination. >>>>>> >>>>>> >>>>>>> >>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>> - Would it make sense to differentiate, either by separate >>>>>>>>> events or by >>>>>>>>> a field in a event, between promotions to to-space and to >>>>>>>>> the old >>>>>>>>> generation? >>>>>>>>> - The are two events for TLAB allocations, >>>>>>>>> java/object_alloc_in_new_TLAB and >>>>>>>>> java/object_alloc_outside_TLAB. >>>>>>>>> What do you think about using two events for PLAB >>>>>>>>> allocations as well: >>>>>>>>> - java/object_alloc_in_new_PLAB >>>>>>>>> - java/object_alloc_outside_PLAB >>>>>>>> I think this is a matter of taste and probably how similar we >>>>>>>> want the >>>>>>>> event to be to the existing allocation event. I personally >>>>>>>> prefer a >>>>>>>> single event but if the GC team and serviceability team feel it >>>>>>>> would be >>>>>>>> better to have two I can certainly rewrite. The reason for me >>>>>>>> preferring >>>>>>>> a single event is just ease of analysis, you can easily filter >>>>>>>> a list of >>>>>>>> events on a field, it is harder to merge two different events with >>>>>>>> different fields and work with them in an straight forward >>>>>>>> fashion. >>>>>>>> >>>>>>>> Any general preference for having a single or multiple events? >>>>>>> >>>>>>> I would prefer to have two events in this case and try to follow >>>>>>> the existing allocation events as much as possible (both in >>>>>>> naming and in style). Keeping the tenured field (I missed it the >>>>>>> first time I read the patch) is good. >>>>>>> >>>>>> Yes, tenured would be independent of having two events, only PLAB >>>>>> size and directAllocation would be affected when having two event >>>>>> types. >>>>>> >>>>>> *Erik Gahlin*, any preference from your end? >>>>>> >>>>>> >>>>>> >>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>> - In PSPromotionManager, instead of utilizing the C++ >>>>>>>>> friendship with >>>>>>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>>>>>> Created a getter function. >>>>>>> >>>>>>> Thanks! If you make report_promotion_sample const, then the >>>>>>> getter can return a const ParallelScavengeTracer*, right? >>>>>>> >>>>>> Done >>>>>> >>>>>> //Staffan >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Thu Nov 6 13:05:48 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Thu, 06 Nov 2014 17:05:48 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B7006.5080104@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> Message-ID: <545B722C.3020406@oracle.com> Hi Katja, Ok, this seems to be a perfect solution. Thank you. I'll change the diff accordingly. Thanks, Evgeniya Stepanova On 06.11.2014 16:56, Yekaterina Kantserova wrote: > Hi Dima, > > On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >> Hi Katja, >> >> You are right, there will be no conflict, because test ignores any >> external VM flags. >> So, adding @requires seems unnecessary here, but... >> >> Ignoring external options is bad thing, such "selfish" tests are not >> applicable for other areas, like GC, compiler, RT. > > This particular case is to test the defined flags are shown up as > expected. > > Evgeniya, > > would you mind to change JpsHelper.java instead? > > +++ b/test/sun/tools/jps/JpsHelper.java > @@ -93,7 +93,7 @@ > /** > * VM arguments to start test application with > */ > - public static final String[] VM_ARGS = {"-Xmx512m", > "-XX:+UseParallelGC"}; > + public static final String[] VM_ARGS = {"-Xmx512m", > "-XX:+PrintGCDetails"}; > /** > * VM flag to start test application with > */ > > Best regards, > Katja > > > >> >> @requires will allow to modify tests to include external vm options >> without any risk of bumping into conflict and extend area of test >> applicability. >> >> But if you still believe, that @requires is not necessary - it's not >> a problem, tests could be kept as is. >> >> Thanks, >> Dima >> >> >> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>> >>> Hi Evgeniya, >>> >>> As David has pointed out these jps tests are not testing gc. The >>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>> should not be any conflicts either since these tests are running in >>> driver mode: >>> >>> ... >>> * @run driver TestJpsJar >>> ... >>> >>> which means no flags from above are accepted. >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>> Hi David, >>>> >>>> tag added because tests contain string >>>> cmd.addAll(JpsHelper.getVmArgs()); >>>> >>>> and JpsHelper defines >>>> ... >>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>> "-XX:+UseParallelGC"}; >>>> ... >>>> public static List getVmArgs() throws IOException { >>>> if (testVmArgs == null) { >>>> testVmArgs = new ArrayList<>(); >>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>> testVmArgs.add("-XX:Flags=" + >>>> getVmFlagsFile().getAbsolutePath()); >>>> } >>>> return testVmArgs; >>>> } >>>> >>>> Tests itself wouldn't fail if we use another GC, tag added for >>>> cleanup-if we use for example SerialGC we must be sure that tests >>>> passed with this GC, not with another one. Now you will assume that >>>> concrete test passed with Serial GC, but it run only with Parallel >>>> GC. Plus there is no any sense to run test twice in TC (with >>>> different GC, since it use only Parallel) >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> On 06.11.2014 6:20, David Holmes wrote: >>>>> Hi Evgeniya, >>>>> >>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>> Hi, >>>>>> >>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>> JDK-8019361 >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>> >>>>>> Problem: Some tests explicitly set GC and fail when another GC is >>>>>> set >>>>>> outside >>>>> >>>>> I don't see why you have done this for the >>>>> >>>>> test/sun/tools/jps/TestJps*.java >>>>> >>>>> tests. They don't set any GC flags. >>>>> >>>>>> Solution: Such tests marked with the jtreg tag "requires" to skip >>>>>> test >>>>>> if there is a conflict >>>>> >>>>> Just wondering: Does a skipped test get a .jtr file showing it was >>>>> skipped; or does it only appear in the higher-level jtreg log? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>> without >>>>>> any GC flag). Tests are being excluded as expected. No tests failed >>>>>> because of the conflict. >>>>>> >>>>>> Thanks, >>>>>> Evgeniya Stepanova >>>>>> >>>>>> // >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >>> >>> >> > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Thu Nov 6 13:35:57 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 06 Nov 2014 14:35:57 +0100 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B722C.3020406@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> Message-ID: <545B793D.5000008@oracle.com> Thanks a lot! On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: > Hi Katja, > > Ok, this seems to be a perfect solution. Thank you. I'll change the > diff accordingly. > > > Thanks, > Evgeniya Stepanova > On 06.11.2014 16:56, Yekaterina Kantserova wrote: >> Hi Dima, >> >> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>> Hi Katja, >>> >>> You are right, there will be no conflict, because test ignores any >>> external VM flags. >>> So, adding @requires seems unnecessary here, but... >>> >>> Ignoring external options is bad thing, such "selfish" tests are not >>> applicable for other areas, like GC, compiler, RT. >> >> This particular case is to test the defined flags are shown up as >> expected. >> >> Evgeniya, >> >> would you mind to change JpsHelper.java instead? >> >> +++ b/test/sun/tools/jps/JpsHelper.java >> @@ -93,7 +93,7 @@ >> /** >> * VM arguments to start test application with >> */ >> - public static final String[] VM_ARGS = {"-Xmx512m", >> "-XX:+UseParallelGC"}; >> + public static final String[] VM_ARGS = {"-Xmx512m", >> "-XX:+PrintGCDetails"}; >> /** >> * VM flag to start test application with >> */ >> >> Best regards, >> Katja >> >> >> >>> >>> @requires will allow to modify tests to include external vm options >>> without any risk of bumping into conflict and extend area of test >>> applicability. >>> >>> But if you still believe, that @requires is not necessary - it's not >>> a problem, tests could be kept as is. >>> >>> Thanks, >>> Dima >>> >>> >>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>> >>>> Hi Evgeniya, >>>> >>>> As David has pointed out these jps tests are not testing gc. The >>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>> should not be any conflicts either since these tests are running in >>>> driver mode: >>>> >>>> ... >>>> * @run driver TestJpsJar >>>> ... >>>> >>>> which means no flags from above are accepted. >>>> >>>> Thanks, >>>> Katja >>>> >>>> >>>> >>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>> Hi David, >>>>> >>>>> tag added because tests contain string >>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>> >>>>> and JpsHelper defines >>>>> ... >>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>> "-XX:+UseParallelGC"}; >>>>> ... >>>>> public static List getVmArgs() throws IOException { >>>>> if (testVmArgs == null) { >>>>> testVmArgs = new ArrayList<>(); >>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>> testVmArgs.add("-XX:Flags=" + >>>>> getVmFlagsFile().getAbsolutePath()); >>>>> } >>>>> return testVmArgs; >>>>> } >>>>> >>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>> cleanup-if we use for example SerialGC we must be sure that tests >>>>> passed with this GC, not with another one. Now you will assume >>>>> that concrete test passed with Serial GC, but it run only with >>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>> (with different GC, since it use only Parallel) >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>> Hi Evgeniya, >>>>>> >>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>> JDK-8019361 >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>> >>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>> is set >>>>>>> outside >>>>>> >>>>>> I don't see why you have done this for the >>>>>> >>>>>> test/sun/tools/jps/TestJps*.java >>>>>> >>>>>> tests. They don't set any GC flags. >>>>>> >>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>> skip test >>>>>>> if there is a conflict >>>>>> >>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>> was skipped; or does it only appear in the higher-level jtreg log? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>>> without >>>>>>> any GC flag). Tests are being excluded as expected. No tests failed >>>>>>> because of the conflict. >>>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> >>>>>>> // >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>>> >>>> >>>> >>> >> > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Nov 6 13:49:12 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 06 Nov 2014 08:49:12 -0500 Subject: RFR 8062116: JVMTI GetClassMethods is Slow In-Reply-To: <545B088E.20903@oracle.com> References: <5457E36A.3020800@oracle.com> <54592FC2.7090406@oracle.com> <5459501C.4040807@oracle.com> <5459ADFB.4090808@oracle.com> <545AB561.9020204@oracle.com> <545ACAA4.3020906@oracle.com> <545AE45A.5080003@oracle.com> <545AE6D6.4040401@oracle.com> <545B00C9.1070502@oracle.com> <545B088E.20903@oracle.com> Message-ID: <545B7C58.8070404@oracle.com> David, you didn't recommend taking the code out, because it looked like something that would trick people, so we'll leave it in. It's benign. The rest of the change improves performance, which we want. Thanks, Coleen On 11/6/14, 12:35 AM, David Holmes wrote: > Right - now I get it. Pointer difference is an algebraic subtraction > with "div sizeof what is pointed to". For aligned pointers there will > be no remainder and adding back the difference to the initial pointer > will yield the end pointer. But if one of the pointers is not aligned > that is not the case. > > All rather icky. > > Thanks, > David > ---- From evgeniya.stepanova at oracle.com Thu Nov 6 14:36:39 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Thu, 06 Nov 2014 18:36:39 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B793D.5000008@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> Message-ID: <545B8777.6080403@oracle.com> New webrev: http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ Thanks, Evgeniya Stepanova On 06.11.2014 17:35, Yekaterina Kantserova wrote: > Thanks a lot! > > On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >> Hi Katja, >> >> Ok, this seems to be a perfect solution. Thank you. I'll change the >> diff accordingly. >> >> >> Thanks, >> Evgeniya Stepanova >> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>> Hi Dima, >>> >>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>> Hi Katja, >>>> >>>> You are right, there will be no conflict, because test ignores any >>>> external VM flags. >>>> So, adding @requires seems unnecessary here, but... >>>> >>>> Ignoring external options is bad thing, such "selfish" tests are >>>> not applicable for other areas, like GC, compiler, RT. >>> >>> This particular case is to test the defined flags are shown up as >>> expected. >>> >>> Evgeniya, >>> >>> would you mind to change JpsHelper.java instead? >>> >>> +++ b/test/sun/tools/jps/JpsHelper.java >>> @@ -93,7 +93,7 @@ >>> /** >>> * VM arguments to start test application with >>> */ >>> - public static final String[] VM_ARGS = {"-Xmx512m", >>> "-XX:+UseParallelGC"}; >>> + public static final String[] VM_ARGS = {"-Xmx512m", >>> "-XX:+PrintGCDetails"}; >>> /** >>> * VM flag to start test application with >>> */ >>> >>> Best regards, >>> Katja >>> >>> >>> >>>> >>>> @requires will allow to modify tests to include external vm >>>> options without any risk of bumping into conflict and extend area >>>> of test applicability. >>>> >>>> But if you still believe, that @requires is not necessary - it's >>>> not a problem, tests could be kept as is. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>> >>>>> Hi Evgeniya, >>>>> >>>>> As David has pointed out these jps tests are not testing gc. The >>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>> should not be any conflicts either since these tests are running >>>>> in driver mode: >>>>> >>>>> ... >>>>> * @run driver TestJpsJar >>>>> ... >>>>> >>>>> which means no flags from above are accepted. >>>>> >>>>> Thanks, >>>>> Katja >>>>> >>>>> >>>>> >>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>> Hi David, >>>>>> >>>>>> tag added because tests contain string >>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>> >>>>>> and JpsHelper defines >>>>>> ... >>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>> "-XX:+UseParallelGC"}; >>>>>> ... >>>>>> public static List getVmArgs() throws IOException { >>>>>> if (testVmArgs == null) { >>>>>> testVmArgs = new ArrayList<>(); >>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>> testVmArgs.add("-XX:Flags=" + >>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>> } >>>>>> return testVmArgs; >>>>>> } >>>>>> >>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>> cleanup-if we use for example SerialGC we must be sure that tests >>>>>> passed with this GC, not with another one. Now you will assume >>>>>> that concrete test passed with Serial GC, but it run only with >>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>> (with different GC, since it use only Parallel) >>>>>> >>>>>> Thanks, >>>>>> Evgeniya Stepanova >>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>> Hi Evgeniya, >>>>>>> >>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>> JDK-8019361 >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>> >>>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>>> is set >>>>>>>> outside >>>>>>> >>>>>>> I don't see why you have done this for the >>>>>>> >>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>> >>>>>>> tests. They don't set any GC flags. >>>>>>> >>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>> skip test >>>>>>>> if there is a conflict >>>>>>> >>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>> was skipped; or does it only appear in the higher-level jtreg log? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>>>> without >>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>> failed >>>>>>>> because of the conflict. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> >>>>>>>> // >>>>>> >>>>>> -- >>>>>> /Evgeniya Stepanova/ >>>>> >>>>> >>>>> >>>> >>> >> >> -- >> /Evgeniya Stepanova/ > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Thu Nov 6 14:02:34 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 06 Nov 2014 18:02:34 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B8777.6080403@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> Message-ID: <545B7F7A.7070406@oracle.com> Hi Evgeniya, it seems like there is no need to use Serial GC in java/lang/ref/EnqueuePollRace.java [1], so it does make sense to remove that option instead of adding the @requires tag. Thanks, Filipp. [1] https://bugs.openjdk.java.net/browse/JDK-8051723 On 11/06/2014 06:36 PM, Evgeniya Stepanova wrote: > New webrev: > http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ > > Thanks, > Evgeniya Stepanova > On 06.11.2014 17:35, Yekaterina Kantserova wrote: >> Thanks a lot! >> >> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>> Hi Katja, >>> >>> Ok, this seems to be a perfect solution. Thank you. I'll change the diff >>> accordingly. >>> >>> >>> Thanks, >>> Evgeniya Stepanova >>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>> Hi Dima, >>>> >>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>> Hi Katja, >>>>> >>>>> You are right, there will be no conflict, because test ignores any >>>>> external VM flags. >>>>> So, adding @requires seems unnecessary here, but... >>>>> >>>>> Ignoring external options is bad thing, such "selfish" tests are not >>>>> applicable for other areas, like GC, compiler, RT. >>>> >>>> This particular case is to test the defined flags are shown up as expected. >>>> >>>> Evgeniya, >>>> >>>> would you mind to change JpsHelper.java instead? >>>> >>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>> @@ -93,7 +93,7 @@ >>>> /** >>>> * VM arguments to start test application with >>>> */ >>>> - public static final String[] VM_ARGS = {"-Xmx512m", "-XX:+UseParallelGC"}; >>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>> "-XX:+PrintGCDetails"}; >>>> /** >>>> * VM flag to start test application with >>>> */ >>>> >>>> Best regards, >>>> Katja >>>> >>>> >>>> >>>>> >>>>> @requires will allow to modify tests to include external vm options >>>>> without any risk of bumping into conflict and extend area of test >>>>> applicability. >>>>> >>>>> But if you still believe, that @requires is not necessary - it's not a >>>>> problem, tests could be kept as is. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>> >>>>>> Hi Evgeniya, >>>>>> >>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There should >>>>>> not be any conflicts either since these tests are running in driver mode: >>>>>> >>>>>> ... >>>>>> * @run driver TestJpsJar >>>>>> ... >>>>>> >>>>>> which means no flags from above are accepted. >>>>>> >>>>>> Thanks, >>>>>> Katja >>>>>> >>>>>> >>>>>> >>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> tag added because tests contain string >>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>> >>>>>>> and JpsHelper defines >>>>>>> ... >>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", "-XX:+UseParallelGC"}; >>>>>>> ... >>>>>>> public static List getVmArgs() throws IOException { >>>>>>> if (testVmArgs == null) { >>>>>>> testVmArgs = new ArrayList<>(); >>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>> } >>>>>>> return testVmArgs; >>>>>>> } >>>>>>> >>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>> cleanup-if we use for example SerialGC we must be sure that tests passed >>>>>>> with this GC, not with another one. Now you will assume that concrete >>>>>>> test passed with Serial GC, but it run only with Parallel GC. Plus there >>>>>>> is no any sense to run test twice in TC (with different GC, since it use >>>>>>> only Parallel) >>>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>> Hi Evgeniya, >>>>>>>> >>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>>> JDK-8019361 >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>> >>>>>>>>> Problem: Some tests explicitly set GC and fail when another GC is set >>>>>>>>> outside >>>>>>>> >>>>>>>> I don't see why you have done this for the >>>>>>>> >>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>> >>>>>>>> tests. They don't set any GC flags. >>>>>>>> >>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to skip test >>>>>>>>> if there is a conflict >>>>>>>> >>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it was >>>>>>>> skipped; or does it only appear in the higher-level jtreg log? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without >>>>>>>>> any GC flag). Tests are being excluded as expected. No tests failed >>>>>>>>> because of the conflict. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Evgeniya Stepanova >>>>>>>>> >>>>>>>>> // >>>>>>> >>>>>>> -- >>>>>>> /Evgeniya Stepanova/ >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> -- >>> /Evgeniya Stepanova/ >> > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Nov 6 22:27:25 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 06 Nov 2014 14:27:25 -0800 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <5459FB96.9020404@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> Message-ID: <545BF5CD.6010008@oracle.com> Hi reviewers, I'm suggesting to review a modified fix: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ The 3-rd round fix is not right as it caused deadlocks in several tests (in nsk.jdi.testlist and jtreg com/sun/jdi). Here is a deadlock example: ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, d4400, 0, ffffffff7e357440, 100138730) + 100 ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, 100137000, 0, 1004405d0, 6e750, 0) + a4 ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, 100137000, 0, 0, 1, 20000000) + 358 ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, 100137000, 1, deab, 60000000, 100137000) + c8 ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 ffffffff7da2284c jvmtiError JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, ffffffffffffffff, 4, 9aeb0, 100137000) + 8c ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, ffffffffffefd118, ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, 1, 2) + 10c ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + 138 ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, ffffffff7ab3ad18, 1018, 1000) + 1d8 ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, ffffffff7e3e6b70) + 30c ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, ffffffff7e3e8b30, ffffffff7e357440, 0, 10013700) + 1bc ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, 10035de68, 0, ffffffff7e4143b0) + 860 ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 12 / thread# 12 -------------------- ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, d4400, 0, ffffffff7e357440, 100349930) + 100 ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 ffffffff7da22450 jvmtiError JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 ffffffff7da56b18 void JvmtiAgentThread::call_start_function() (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + 128 ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, 3d8, 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, fffffffea5f3e048, 3d8, 1003497f8) + 3ac ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 13 / thread# 13 -------------------- ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, d4400, 0, ffffffff7e357440, 10034d330) + 100 ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, 10034c000) + e0 ffffffff7da2284c jvmtiError JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, 0, 10000000) + ac ffffffff7da56b18 void JvmtiAgentThread::call_start_function() (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + 128 ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, 3d8, 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, fffffffea5f3e290, 3d8, 10034cfe8) + 3ac ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) The details: - Thread #2: The cbVMDeath() event handler is waiting on the commandCompleteLock in the enqueueCommand(). The call chain is: cbVMDeath() -> event_callback() -> reportEvents() -> eventHelper_reportEvents() -> enqueueCommand(). The enqueueCommand() depends on the commandLoop() that has to call completeCommand(command) for the command being enqueued. This has not been set yet: gdata->vmDead = JNI_TRUE - Thread #12: The debugLoop_run blocked on the vmDeathLock enter - Thread #13: The commandLoop is waiting on the blockCommandLoopLock in the doBlockCommandLoop(). It is because blockCommandLoop == JNI_TRUE which is set in the needBlockCommandLoop() if the following condition is true: (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && cmd->u.reportEventComposite.suspendPolicy == JDWP_SUSPEND_POLICY(ALL)) It seems, the debugLoop_run() block on the vmDeathLock causes the commandLoop() to wait indefinitely. The cbVMDeath() can not proceed because the commandLoop() does not make a progress. The vmDeathLock critical section in the cbVMDeath() event callback seems to be an overkill (unnecessary). A less intrusive synchronization is required here which is to wait until the current command is completed before returning to the JvmtiExport::post_vm_death(). The new approach (see new webrev) is to extend the resumeLock synchronization pattern to all VirtualMachine set of commands, not only the resume command. The resumeLock name is replaced with the vmDeathLock to reflect new semantics. In general, we could consider to do the same for the rest of the JDWP command sets. But it is better to be careful and see how this change goes first. Thanks, Serguei On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for the concerns! > Testing showed several tests failing with deadlocks. > Scenarios are similar to that you describe. > > Trying to understand the details. > > Thanks, > Serguei > > On 11/4/14 4:09 PM, David Holmes wrote: >> Hi Serguei, >> >> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>> On 11/2/14 8:58 PM, David Holmes wrote: >>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>> Serguei, >>>>> >>>>> Thank you for good finding. This approach looks much better for me. >>>>> >>>>> The fix looks good. >>>>> >>>>> Is it necessary to release vmDeathLock locks at >>>>> eventHandler.c:1244 before call >>>>> >>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>> >>>> I agree this looks necessary, or at least more clean (if things are >>>> failing we really don't know what is happening). >>> >>> Agreed (replied to Dmitry). >>> >>>> >>>> More generally I'm concerned about whether any of the code paths taken >>>> while holding the new lock can result in deadlock - in particular with >>>> regard to the resumeLock ? >>> >>> The cbVMDeath() function never holds both vmDeathLock and resumeLock at >>> the same time, >>> so there is no chance for a deadlock that involves both these locks. >>> >>> Two more locks used in the cbVMDeath() are the callbackBlock and >>> callbackLock. >>> These two locks look completely unrelated to the debugLoop_run(). >>> >>> The debugLoop_run() function also uses the cmdQueueLock. >>> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at >>> the >>> same time. >>> >>> So that I do not see any potential to introduce new deadlock with the >>> vmDeathLock. >>> >>> However, it is still easy to overlook something here. >>> Please, let me know if you see any danger. >> >> I was mainly concerned about what might happen in the call chain for >> threadControl_resumeAll() (it certainly sounds like it might need to >> use a resumeLock :) ). I see direct use of the threadLock and >> indirectly the eventHandler lock; but there are further call paths I >> did not explore. Wish there was an easy way to determine the >> transitive closure of all locks used from a given call. >> >> Thanks, >> David >> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> >>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> It is 3-rd round of review for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>> >>>>>> New webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Summary >>>>>> >>>>>> For failing scenario, please, refer to the 1-st round RFR below. >>>>>> >>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>> decided to >>>>>> switch from a workaround to a real fix. >>>>>> >>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>> gdata->vmDead = 1. >>>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>>> >>>>>> 165 } else if (gdata->vmDead && >>>>>> 166 ((cmd->cmdSet) != >>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>> 167 /* Protect the VM from calls while dead. >>>>>> 168 * VirtualMachine cmdSet quietly ignores some >>>>>> cmds >>>>>> 169 * after VM death, so, it sends it's own >>>>>> errors. >>>>>> 170 */ >>>>>> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >>>>>> >>>>>> >>>>>> However, the guard above does not help much if the VM_DEATH event >>>>>> happens in the middle of a command execution. >>>>>> There is a lack of synchronization here. >>>>>> >>>>>> The fix introduces new lock (vmDeathLock) which does not allow to >>>>>> execute the commands >>>>>> and the VM_DEATH event callback concurrently. >>>>>> It should work well for any function that is used in >>>>>> implementation of >>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>> >>>>>> >>>>>> Testing: >>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>> tests >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> The updated webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The changes are: >>>>>>> - added a comment recommended by Staffan >>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>> classSignature() >>>>>>> >>>>>>> The classSignature() function is called in 16 places. >>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>> signature >>>>>>> and will crash. >>>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>>> return to this >>>>>>> issue after gaining experience with more failure cases that are >>>>>>> still >>>>>>> expected. >>>>>>> The failure with the classSignature() involved was observed only >>>>>>> once >>>>>>> in the nightly >>>>>>> and should be extremely rare reproducible. >>>>>>> I'll file a placeholder bug if necessary. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>> >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> The failing scenario: >>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>> shutdown has >>>>>>>> been started in the target process. >>>>>>>> The debugger at this point is not expected to send any >>>>>>>> commands >>>>>>>> to the JDWP agent. >>>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>>> (debuggee side) >>>>>>>> are not in sync with the consumer layers. >>>>>>>> >>>>>>>> One reason is because the test debugger does not invoke >>>>>>>> the JDI >>>>>>>> method VirtualMachine.dispose(). >>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>> processes >>>>>>>> are uneasy to sync in general. >>>>>>>> >>>>>>>> As a result the following steps are possible: >>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>> debuggee >>>>>>>> - The debuggee is normally exiting >>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>> anonymous class unload event >>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>> ClassUnloadEvent event >>>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>>> reference type. >>>>>>>> If there is more than one class with the same host class >>>>>>>> signature, it can't distinguish them, >>>>>>>> and so, deletes all references and re-retrieves them >>>>>>>> again >>>>>>>> (see tracing below): >>>>>>>> MY_TRACE: JDI: >>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>> from JDI >>>>>>>> and calls the functions >>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>> GetClassStatus() >>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>>> to the >>>>>>>> JDI, and so, the test fails >>>>>>>> >>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>> dup of >>>>>>>> the bug 6988950: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>> >>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>> (6988950 >>>>>>>> and 8024865) describing this issue. >>>>>>>> >>>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>>> error >>>>>>>> as it is normal at the VM shutdown. >>>>>>>> The original jdwp backend implementation had a similar >>>>>>>> approach >>>>>>>> for the raw monitor functions. >>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>> tests >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Nov 6 22:56:50 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 06 Nov 2014 14:56:50 -0800 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545BF5CD.6010008@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> Message-ID: <545BFCB2.5070802@oracle.com> I forgot to tell that all the nsk.jdi.testlist, nsk.jdwp.testlist and gtreg com/sun/jdi tests successfully passed with the new fix. No deadlocks are observed. Thanks, Serguei On 11/6/14 2:27 PM, serguei.spitsyn at oracle.com wrote: > Hi reviewers, > > I'm suggesting to review a modified fix: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ > > > The 3-rd round fix is not right as it caused deadlocks in several > tests (in nsk.jdi.testlist and jtreg com/sun/jdi). > > Here is a deadlock example: > > ----------------- lwp# 2 / thread# 2 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, > d4400, 0, ffffffff7e357440, 100138730) + 100 > ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, > 100137000, 0, 1004405d0, 6e750, 0) + a4 > ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, > 100137000, 0, 0, 1, 20000000) + 358 > ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, > 100137000, 1, deab, 60000000, 100137000) + c8 > ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) > (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 > ffffffff7da2284c jvmtiError > JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, > ffffffffffffffff, 4, 9aeb0, 100137000) + 8c > ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, > ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c > ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, ffffffffffefd118, > ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c > ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, 1, 2) > + 10c > ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + 138 > ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, > ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 > ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, > ffffffff7ab3ad18, 1018, 1000) + 1d8 > ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, > ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 > ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, > ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, > ffffffff7e3e6b70) + 30c > ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, > ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 > ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, > ffffffff7e3e8b30, ffffffff7e357440, 0, 10013700) + 1bc > ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, > 10035de68, 0, ffffffff7e4143b0) + 860 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > ----------------- lwp# 12 / thread# 12 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, > d4400, 0, ffffffff7e357440, 100349930) + 100 > ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, > 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 > ffffffff7da22450 jvmtiError > JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, > 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 > ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, > ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 > ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, > ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c > ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, > ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 > ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, > ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 > ffffffff7da56b18 void JvmtiAgentThread::call_start_function() > (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + 128 > ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, > 3d8, 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 > ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, > fffffffea5f3e048, 3d8, 1003497f8) + 3ac > ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, > ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > ----------------- lwp# 13 / thread# 13 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, > d4400, 0, ffffffff7e357440, 10034d330) + 100 > ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) > (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 > ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) > (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, > 10034c000) + e0 > ffffffff7da2284c jvmtiError > JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, > ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c > ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, > ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c > ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, > 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 > ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, > 0, 10000000) + ac > ffffffff7da56b18 void JvmtiAgentThread::call_start_function() > (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + 128 > ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, > 3d8, 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 > ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, > fffffffea5f3e290, 3d8, 10034cfe8) + 3ac > ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, > ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > > The details: > - Thread #2: The cbVMDeath() event handler is waiting on the > commandCompleteLock in the enqueueCommand(). > The call chain is: > cbVMDeath() -> event_callback() -> reportEvents() -> > eventHelper_reportEvents() -> enqueueCommand(). > The enqueueCommand() depends on the commandLoop() that has to call > completeCommand(command) for the command being enqueued. > This has not been set yet: gdata->vmDead = JNI_TRUE > > - Thread #12: The debugLoop_run blocked on the vmDeathLock enter > > - Thread #13: The commandLoop is waiting on the blockCommandLoopLock > in the doBlockCommandLoop(). > It is because blockCommandLoop == JNI_TRUE which is set in the > needBlockCommandLoop() > if the following condition is true: > (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && > cmd->u.reportEventComposite.suspendPolicy == > JDWP_SUSPEND_POLICY(ALL)) > > > It seems, the debugLoop_run() block on the vmDeathLock causes the > commandLoop() to wait indefinitely. > The cbVMDeath() can not proceed because the commandLoop() does not > make a progress. > > The vmDeathLock critical section in the cbVMDeath() event callback > seems to be an overkill (unnecessary). > A less intrusive synchronization is required here which is to wait > until the current command is completed > before returning to the JvmtiExport::post_vm_death(). > > The new approach (see new webrev) is to extend the resumeLock > synchronization pattern > to all VirtualMachine set of commands, not only the resume command. > The resumeLock name is replaced with the vmDeathLock to reflect new > semantics. > > In general, we could consider to do the same for the rest of the JDWP > command sets. > But it is better to be careful and see how this change goes first. > > > Thanks, > Serguei > > > On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for the concerns! >> Testing showed several tests failing with deadlocks. >> Scenarios are similar to that you describe. >> >> Trying to understand the details. >> >> Thanks, >> Serguei >> >> On 11/4/14 4:09 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> Thank you for good finding. This approach looks much better for me. >>>>>> >>>>>> The fix looks good. >>>>>> >>>>>> Is it necessary to release vmDeathLock locks at >>>>>> eventHandler.c:1244 before call >>>>>> >>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>> >>>>> I agree this looks necessary, or at least more clean (if things are >>>>> failing we really don't know what is happening). >>>> >>>> Agreed (replied to Dmitry). >>>> >>>>> >>>>> More generally I'm concerned about whether any of the code paths >>>>> taken >>>>> while holding the new lock can result in deadlock - in particular >>>>> with >>>>> regard to the resumeLock ? >>>> >>>> The cbVMDeath() function never holds both vmDeathLock and >>>> resumeLock at >>>> the same time, >>>> so there is no chance for a deadlock that involves both these locks. >>>> >>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>> callbackLock. >>>> These two locks look completely unrelated to the debugLoop_run(). >>>> >>>> The debugLoop_run() function also uses the cmdQueueLock. >>>> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock >>>> at the >>>> same time. >>>> >>>> So that I do not see any potential to introduce new deadlock with the >>>> vmDeathLock. >>>> >>>> However, it is still easy to overlook something here. >>>> Please, let me know if you see any danger. >>> >>> I was mainly concerned about what might happen in the call chain for >>> threadControl_resumeAll() (it certainly sounds like it might need to >>> use a resumeLock :) ). I see direct use of the threadLock and >>> indirectly the eventHandler lock; but there are further call paths I >>> did not explore. Wish there was an easy way to determine the >>> transitive closure of all locks used from a given call. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> >>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> It is 3-rd round of review for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>> >>>>>>> New webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> For failing scenario, please, refer to the 1-st round RFR below. >>>>>>> >>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>> decided to >>>>>>> switch from a workaround to a real fix. >>>>>>> >>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>> gdata->vmDead = 1. >>>>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>>>> >>>>>>> 165 } else if (gdata->vmDead && >>>>>>> 166 ((cmd->cmdSet) != >>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>> 168 * VirtualMachine cmdSet quietly ignores some >>>>>>> cmds >>>>>>> 169 * after VM death, so, it sends it's own >>>>>>> errors. >>>>>>> 170 */ >>>>>>> 171 outStream_setError(&out, >>>>>>> JDWP_ERROR(VM_DEAD)); >>>>>>> >>>>>>> >>>>>>> However, the guard above does not help much if the VM_DEATH >>>>>>> event >>>>>>> happens in the middle of a command execution. >>>>>>> There is a lack of synchronization here. >>>>>>> >>>>>>> The fix introduces new lock (vmDeathLock) which does not >>>>>>> allow to >>>>>>> execute the commands >>>>>>> and the VM_DEATH event callback concurrently. >>>>>>> It should work well for any function that is used in >>>>>>> implementation of >>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>> tests >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> The updated webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The changes are: >>>>>>>> - added a comment recommended by Staffan >>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>> classSignature() >>>>>>>> >>>>>>>> The classSignature() function is called in 16 places. >>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>> signature >>>>>>>> and will crash. >>>>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>>>> return to this >>>>>>>> issue after gaining experience with more failure cases that are >>>>>>>> still >>>>>>>> expected. >>>>>>>> The failure with the classSignature() involved was observed >>>>>>>> only once >>>>>>>> in the nightly >>>>>>>> and should be extremely rare reproducible. >>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>> >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> The failing scenario: >>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>> shutdown has >>>>>>>>> been started in the target process. >>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>> commands >>>>>>>>> to the JDWP agent. >>>>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>>>> (debuggee side) >>>>>>>>> are not in sync with the consumer layers. >>>>>>>>> >>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>> the JDI >>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>> processes >>>>>>>>> are uneasy to sync in general. >>>>>>>>> >>>>>>>>> As a result the following steps are possible: >>>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>>> debuggee >>>>>>>>> - The debuggee is normally exiting >>>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>>> anonymous class unload event >>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>> ClassUnloadEvent event >>>>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>>>> reference type. >>>>>>>>> If there is more than one class with the same host >>>>>>>>> class >>>>>>>>> signature, it can't distinguish them, >>>>>>>>> and so, deletes all references and re-retrieves them >>>>>>>>> again >>>>>>>>> (see tracing below): >>>>>>>>> MY_TRACE: JDI: >>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>> from JDI >>>>>>>>> and calls the functions >>>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>> GetClassStatus() >>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>>>> to the >>>>>>>>> JDI, and so, the test fails >>>>>>>>> >>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>> dup of >>>>>>>>> the bug 6988950: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>> >>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>> (6988950 >>>>>>>>> and 8024865) describing this issue. >>>>>>>>> >>>>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>>>> error >>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>> approach >>>>>>>>> for the raw monitor functions. >>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>> tests >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Nov 7 05:18:24 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Nov 2014 15:18:24 +1000 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545BF5CD.6010008@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> Message-ID: <545C5620.7080300@oracle.com> Hi Serguei, I think I get the gist of this approach but I'm not an expert on the JVM TI or JDWP event model. My main concern would be how the delay to the completion of cbVMDeath() might impact things - specifically if it might be a lengthy delay? Thanks, David On 7/11/2014 8:27 AM, serguei.spitsyn at oracle.com wrote: > Hi reviewers, > > I'm suggesting to review a modified fix: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ > > > The 3-rd round fix is not right as it caused deadlocks in several tests > (in nsk.jdi.testlist and jtreg com/sun/jdi). > > Here is a deadlock example: > > ----------------- lwp# 2 / thread# 2 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, > d4400, 0, ffffffff7e357440, 100138730) + 100 > ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, > 100137000, 0, 1004405d0, 6e750, 0) + a4 > ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, > 100137000, 0, 0, 1, 20000000) + 358 > ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, > 100137000, 1, deab, 60000000, 100137000) + c8 > ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) > (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 > ffffffff7da2284c jvmtiError > JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, > ffffffffffffffff, 4, 9aeb0, 100137000) + 8c > ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, > ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c > ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, ffffffffffefd118, > ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c > ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, 1, 2) > + 10c > ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + 138 > ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, > ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 > ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, > ffffffff7ab3ad18, 1018, 1000) + 1d8 > ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, > ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 > ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, > ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, > ffffffff7e3e6b70) + 30c > ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, > ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 > ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, ffffffff7e3e8b30, > ffffffff7e357440, 0, 10013700) + 1bc > ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, > 10035de68, 0, ffffffff7e4143b0) + 860 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > ----------------- lwp# 12 / thread# 12 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, > d4400, 0, ffffffff7e357440, 100349930) + 100 > ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, > 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 > ffffffff7da22450 jvmtiError > JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, > 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 > ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, > ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 > ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, > ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c > ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, > ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 > ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, > ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 > ffffffff7da56b18 void JvmtiAgentThread::call_start_function() > (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + 128 > ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, 3d8, > 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 > ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, > fffffffea5f3e048, 3d8, 1003497f8) + 3ac > ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, > ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > ----------------- lwp# 13 / thread# 13 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, > d4400, 0, ffffffff7e357440, 10034d330) + 100 > ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) > (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 > ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) > (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, 10034c000) > + e0 > ffffffff7da2284c jvmtiError > JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, > ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c > ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, > ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c > ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, > 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 > ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, > 0, 10000000) + ac > ffffffff7da56b18 void JvmtiAgentThread::call_start_function() > (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + 128 > ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, 3d8, > 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 > ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, > fffffffea5f3e290, 3d8, 10034cfe8) + 3ac > ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, > ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > > The details: > - Thread #2: The cbVMDeath() event handler is waiting on the > commandCompleteLock in the enqueueCommand(). > The call chain is: > cbVMDeath() -> event_callback() -> reportEvents() -> > eventHelper_reportEvents() -> enqueueCommand(). > The enqueueCommand() depends on the commandLoop() that has to call > completeCommand(command) for the command being enqueued. > This has not been set yet: gdata->vmDead = JNI_TRUE > > - Thread #12: The debugLoop_run blocked on the vmDeathLock enter > > - Thread #13: The commandLoop is waiting on the blockCommandLoopLock > in the doBlockCommandLoop(). > It is because blockCommandLoop == JNI_TRUE which is set in the > needBlockCommandLoop() > if the following condition is true: > (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && > cmd->u.reportEventComposite.suspendPolicy == > JDWP_SUSPEND_POLICY(ALL)) > > > It seems, the debugLoop_run() block on the vmDeathLock causes the > commandLoop() to wait indefinitely. > The cbVMDeath() can not proceed because the commandLoop() does not make > a progress. > > The vmDeathLock critical section in the cbVMDeath() event callback seems > to be an overkill (unnecessary). > A less intrusive synchronization is required here which is to wait until > the current command is completed > before returning to the JvmtiExport::post_vm_death(). > > The new approach (see new webrev) is to extend the resumeLock > synchronization pattern > to all VirtualMachine set of commands, not only the resume command. > The resumeLock name is replaced with the vmDeathLock to reflect new > semantics. > > In general, we could consider to do the same for the rest of the JDWP > command sets. > But it is better to be careful and see how this change goes first. > > > Thanks, > Serguei > > > On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for the concerns! >> Testing showed several tests failing with deadlocks. >> Scenarios are similar to that you describe. >> >> Trying to understand the details. >> >> Thanks, >> Serguei >> >> On 11/4/14 4:09 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> Thank you for good finding. This approach looks much better for me. >>>>>> >>>>>> The fix looks good. >>>>>> >>>>>> Is it necessary to release vmDeathLock locks at >>>>>> eventHandler.c:1244 before call >>>>>> >>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>> >>>>> I agree this looks necessary, or at least more clean (if things are >>>>> failing we really don't know what is happening). >>>> >>>> Agreed (replied to Dmitry). >>>> >>>>> >>>>> More generally I'm concerned about whether any of the code paths taken >>>>> while holding the new lock can result in deadlock - in particular with >>>>> regard to the resumeLock ? >>>> >>>> The cbVMDeath() function never holds both vmDeathLock and resumeLock at >>>> the same time, >>>> so there is no chance for a deadlock that involves both these locks. >>>> >>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>> callbackLock. >>>> These two locks look completely unrelated to the debugLoop_run(). >>>> >>>> The debugLoop_run() function also uses the cmdQueueLock. >>>> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at >>>> the >>>> same time. >>>> >>>> So that I do not see any potential to introduce new deadlock with the >>>> vmDeathLock. >>>> >>>> However, it is still easy to overlook something here. >>>> Please, let me know if you see any danger. >>> >>> I was mainly concerned about what might happen in the call chain for >>> threadControl_resumeAll() (it certainly sounds like it might need to >>> use a resumeLock :) ). I see direct use of the threadLock and >>> indirectly the eventHandler lock; but there are further call paths I >>> did not explore. Wish there was an easy way to determine the >>> transitive closure of all locks used from a given call. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> >>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> It is 3-rd round of review for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>> >>>>>>> New webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> For failing scenario, please, refer to the 1-st round RFR below. >>>>>>> >>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>> decided to >>>>>>> switch from a workaround to a real fix. >>>>>>> >>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>> gdata->vmDead = 1. >>>>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>>>> >>>>>>> 165 } else if (gdata->vmDead && >>>>>>> 166 ((cmd->cmdSet) != >>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>> 168 * VirtualMachine cmdSet quietly ignores some >>>>>>> cmds >>>>>>> 169 * after VM death, so, it sends it's own >>>>>>> errors. >>>>>>> 170 */ >>>>>>> 171 outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >>>>>>> >>>>>>> >>>>>>> However, the guard above does not help much if the VM_DEATH event >>>>>>> happens in the middle of a command execution. >>>>>>> There is a lack of synchronization here. >>>>>>> >>>>>>> The fix introduces new lock (vmDeathLock) which does not allow to >>>>>>> execute the commands >>>>>>> and the VM_DEATH event callback concurrently. >>>>>>> It should work well for any function that is used in >>>>>>> implementation of >>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>> tests >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> The updated webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The changes are: >>>>>>>> - added a comment recommended by Staffan >>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>> classSignature() >>>>>>>> >>>>>>>> The classSignature() function is called in 16 places. >>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>> signature >>>>>>>> and will crash. >>>>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>>>> return to this >>>>>>>> issue after gaining experience with more failure cases that are >>>>>>>> still >>>>>>>> expected. >>>>>>>> The failure with the classSignature() involved was observed only >>>>>>>> once >>>>>>>> in the nightly >>>>>>>> and should be extremely rare reproducible. >>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>> >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> The failing scenario: >>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>> shutdown has >>>>>>>>> been started in the target process. >>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>> commands >>>>>>>>> to the JDWP agent. >>>>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>>>> (debuggee side) >>>>>>>>> are not in sync with the consumer layers. >>>>>>>>> >>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>> the JDI >>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>> processes >>>>>>>>> are uneasy to sync in general. >>>>>>>>> >>>>>>>>> As a result the following steps are possible: >>>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>>> debuggee >>>>>>>>> - The debuggee is normally exiting >>>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>>> anonymous class unload event >>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>> ClassUnloadEvent event >>>>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>>>> reference type. >>>>>>>>> If there is more than one class with the same host class >>>>>>>>> signature, it can't distinguish them, >>>>>>>>> and so, deletes all references and re-retrieves them >>>>>>>>> again >>>>>>>>> (see tracing below): >>>>>>>>> MY_TRACE: JDI: >>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>> from JDI >>>>>>>>> and calls the functions >>>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>> GetClassStatus() >>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>>>> to the >>>>>>>>> JDI, and so, the test fails >>>>>>>>> >>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>> dup of >>>>>>>>> the bug 6988950: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>> >>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>> (6988950 >>>>>>>>> and 8024865) describing this issue. >>>>>>>>> >>>>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>>>> error >>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>> approach >>>>>>>>> for the raw monitor functions. >>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>> tests >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >> > From david.holmes at oracle.com Fri Nov 7 05:37:58 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Nov 2014 15:37:58 +1000 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B8777.6080403@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> Message-ID: <545C5AB6.6030103@oracle.com> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: > New webrev: > http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ In: test/java/lang/management/RuntimeMXBean/TestInputArgument.sh the use of the gc options seems incidental - it's just picking two innocuous options to use - similar to the JpsHelper case. You could replace +UseParallelGC with something like +UseFastJNIAccessors (platform independent and normally true). David ----- > Thanks, > Evgeniya Stepanova > On 06.11.2014 17:35, Yekaterina Kantserova wrote: >> Thanks a lot! >> >> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>> Hi Katja, >>> >>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>> diff accordingly. >>> >>> >>> Thanks, >>> Evgeniya Stepanova >>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>> Hi Dima, >>>> >>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>> Hi Katja, >>>>> >>>>> You are right, there will be no conflict, because test ignores any >>>>> external VM flags. >>>>> So, adding @requires seems unnecessary here, but... >>>>> >>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>> not applicable for other areas, like GC, compiler, RT. >>>> >>>> This particular case is to test the defined flags are shown up as >>>> expected. >>>> >>>> Evgeniya, >>>> >>>> would you mind to change JpsHelper.java instead? >>>> >>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>> @@ -93,7 +93,7 @@ >>>> /** >>>> * VM arguments to start test application with >>>> */ >>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>> "-XX:+UseParallelGC"}; >>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>> "-XX:+PrintGCDetails"}; >>>> /** >>>> * VM flag to start test application with >>>> */ >>>> >>>> Best regards, >>>> Katja >>>> >>>> >>>> >>>>> >>>>> @requires will allow to modify tests to include external vm >>>>> options without any risk of bumping into conflict and extend area >>>>> of test applicability. >>>>> >>>>> But if you still believe, that @requires is not necessary - it's >>>>> not a problem, tests could be kept as is. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>> >>>>>> Hi Evgeniya, >>>>>> >>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>> should not be any conflicts either since these tests are running >>>>>> in driver mode: >>>>>> >>>>>> ... >>>>>> * @run driver TestJpsJar >>>>>> ... >>>>>> >>>>>> which means no flags from above are accepted. >>>>>> >>>>>> Thanks, >>>>>> Katja >>>>>> >>>>>> >>>>>> >>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> tag added because tests contain string >>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>> >>>>>>> and JpsHelper defines >>>>>>> ... >>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>> "-XX:+UseParallelGC"}; >>>>>>> ... >>>>>>> public static List getVmArgs() throws IOException { >>>>>>> if (testVmArgs == null) { >>>>>>> testVmArgs = new ArrayList<>(); >>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>> } >>>>>>> return testVmArgs; >>>>>>> } >>>>>>> >>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>> cleanup-if we use for example SerialGC we must be sure that tests >>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>> (with different GC, since it use only Parallel) >>>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>> Hi Evgeniya, >>>>>>>> >>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>>> JDK-8019361 >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>> >>>>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>>>> is set >>>>>>>>> outside >>>>>>>> >>>>>>>> I don't see why you have done this for the >>>>>>>> >>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>> >>>>>>>> tests. They don't set any GC flags. >>>>>>>> >>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>> skip test >>>>>>>>> if there is a conflict >>>>>>>> >>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>> was skipped; or does it only appear in the higher-level jtreg log? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>>>>> without >>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>> failed >>>>>>>>> because of the conflict. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Evgeniya Stepanova >>>>>>>>> >>>>>>>>> // >>>>>>> >>>>>>> -- >>>>>>> /Evgeniya Stepanova/ >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> -- >>> /Evgeniya Stepanova/ >> > > -- > /Evgeniya Stepanova/ From evgeniya.stepanova at oracle.com Fri Nov 7 07:49:44 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 07 Nov 2014 11:49:44 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545C5AB6.6030103@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> Message-ID: <545C7998.10900@oracle.com> Hi David! Ok, I'll change the diff. Thank you On 07.11.2014 9:37, David Holmes wrote: > On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >> New webrev: >> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ > > In: > > test/java/lang/management/RuntimeMXBean/TestInputArgument.sh > > the use of the gc options seems incidental - it's just picking two > innocuous options to use - similar to the JpsHelper case. You could > replace +UseParallelGC with something like +UseFastJNIAccessors > (platform independent and normally true). > > David > ----- > >> Thanks, >> Evgeniya Stepanova >> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>> Thanks a lot! >>> >>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>> Hi Katja, >>>> >>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>> diff accordingly. >>>> >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>> Hi Dima, >>>>> >>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>> Hi Katja, >>>>>> >>>>>> You are right, there will be no conflict, because test ignores any >>>>>> external VM flags. >>>>>> So, adding @requires seems unnecessary here, but... >>>>>> >>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>> not applicable for other areas, like GC, compiler, RT. >>>>> >>>>> This particular case is to test the defined flags are shown up as >>>>> expected. >>>>> >>>>> Evgeniya, >>>>> >>>>> would you mind to change JpsHelper.java instead? >>>>> >>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>> @@ -93,7 +93,7 @@ >>>>> /** >>>>> * VM arguments to start test application with >>>>> */ >>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>> "-XX:+UseParallelGC"}; >>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>> "-XX:+PrintGCDetails"}; >>>>> /** >>>>> * VM flag to start test application with >>>>> */ >>>>> >>>>> Best regards, >>>>> Katja >>>>> >>>>> >>>>> >>>>>> >>>>>> @requires will allow to modify tests to include external vm >>>>>> options without any risk of bumping into conflict and extend area >>>>>> of test applicability. >>>>>> >>>>>> But if you still believe, that @requires is not necessary - it's >>>>>> not a problem, tests could be kept as is. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> >>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>> >>>>>>> Hi Evgeniya, >>>>>>> >>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>> should not be any conflicts either since these tests are running >>>>>>> in driver mode: >>>>>>> >>>>>>> ... >>>>>>> * @run driver TestJpsJar >>>>>>> ... >>>>>>> >>>>>>> which means no flags from above are accepted. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> tag added because tests contain string >>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>> >>>>>>>> and JpsHelper defines >>>>>>>> ... >>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>> ... >>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>> if (testVmArgs == null) { >>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>> } >>>>>>>> return testVmArgs; >>>>>>>> } >>>>>>>> >>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>> cleanup-if we use for example SerialGC we must be sure that tests >>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>>> (with different GC, since it use only Parallel) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>> Hi Evgeniya, >>>>>>>>> >>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>>>> JDK-8019361 >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>> >>>>>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>>>>> is set >>>>>>>>>> outside >>>>>>>>> >>>>>>>>> I don't see why you have done this for the >>>>>>>>> >>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>> >>>>>>>>> tests. They don't set any GC flags. >>>>>>>>> >>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>> skip test >>>>>>>>>> if there is a conflict >>>>>>>>> >>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>> was skipped; or does it only appear in the higher-level jtreg >>>>>>>>> log? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>>>>>> without >>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>> failed >>>>>>>>>> because of the conflict. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Evgeniya Stepanova >>>>>>>>>> >>>>>>>>>> // >>>>>>>> >>>>>>>> -- >>>>>>>> /Evgeniya Stepanova/ >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >> >> -- >> /Evgeniya Stepanova/ -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Fri Nov 7 08:21:15 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 07 Nov 2014 12:21:15 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545B7F7A.7070406@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545B7F7A.7070406@oracle.com> Message-ID: <545C80FB.3050300@oracle.com> Hi Filipp, Ok, then I'll just remove option :) Thanks On 06.11.2014 18:02, Filipp Zhinkin wrote: > Hi Evgeniya, > > it seems like there is no need to use Serial GC in > java/lang/ref/EnqueuePollRace.java [1], > so it does make sense to remove that option instead of adding the > @requires tag. > > Thanks, > Filipp. > > [1] https://bugs.openjdk.java.net/browse/JDK-8051723 > > On 11/06/2014 06:36 PM, Evgeniya Stepanova wrote: >> New webrev: >> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >> >> Thanks, >> Evgeniya Stepanova >> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>> Thanks a lot! >>> >>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>> Hi Katja, >>>> >>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>> diff accordingly. >>>> >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>> Hi Dima, >>>>> >>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>> Hi Katja, >>>>>> >>>>>> You are right, there will be no conflict, because test ignores >>>>>> any external VM flags. >>>>>> So, adding @requires seems unnecessary here, but... >>>>>> >>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>> not applicable for other areas, like GC, compiler, RT. >>>>> >>>>> This particular case is to test the defined flags are shown up as >>>>> expected. >>>>> >>>>> Evgeniya, >>>>> >>>>> would you mind to change JpsHelper.java instead? >>>>> >>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>> @@ -93,7 +93,7 @@ >>>>> /** >>>>> * VM arguments to start test application with >>>>> */ >>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>> "-XX:+UseParallelGC"}; >>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>> "-XX:+PrintGCDetails"}; >>>>> /** >>>>> * VM flag to start test application with >>>>> */ >>>>> >>>>> Best regards, >>>>> Katja >>>>> >>>>> >>>>> >>>>>> >>>>>> @requires will allow to modify tests to include external vm >>>>>> options without any risk of bumping into conflict and extend area >>>>>> of test applicability. >>>>>> >>>>>> But if you still believe, that @requires is not necessary - it's >>>>>> not a problem, tests could be kept as is. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> >>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>> >>>>>>> Hi Evgeniya, >>>>>>> >>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>> should not be any conflicts either since these tests are running >>>>>>> in driver mode: >>>>>>> >>>>>>> ... >>>>>>> * @run driver TestJpsJar >>>>>>> ... >>>>>>> >>>>>>> which means no flags from above are accepted. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> tag added because tests contain string >>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>> >>>>>>>> and JpsHelper defines >>>>>>>> ... >>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>> ... >>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>> if (testVmArgs == null) { >>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>> } >>>>>>>> return testVmArgs; >>>>>>>> } >>>>>>>> >>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>> tests passed with this GC, not with another one. Now you will >>>>>>>> assume that concrete test passed with Serial GC, but it run >>>>>>>> only with Parallel GC. Plus there is no any sense to run test >>>>>>>> twice in TC (with different GC, since it use only Parallel) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>> Hi Evgeniya, >>>>>>>>> >>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of >>>>>>>>>> the JDK-8019361 >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>> >>>>>>>>>> Problem: Some tests explicitly set GC and fail when another >>>>>>>>>> GC is set >>>>>>>>>> outside >>>>>>>>> >>>>>>>>> I don't see why you have done this for the >>>>>>>>> >>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>> >>>>>>>>> tests. They don't set any GC flags. >>>>>>>>> >>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>> skip test >>>>>>>>>> if there is a conflict >>>>>>>>> >>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>> was skipped; or does it only appear in the higher-level jtreg >>>>>>>>> log? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep >>>>>>>>>> and without >>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>> failed >>>>>>>>>> because of the conflict. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Evgeniya Stepanova >>>>>>>>>> >>>>>>>>>> // >>>>>>>> >>>>>>>> -- >>>>>>>> /Evgeniya Stepanova/ >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >> >> -- >> /Evgeniya Stepanova/ > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Nov 7 09:48:11 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Nov 2014 01:48:11 -0800 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545C5620.7080300@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> <545C5620.7080300@oracle.com> Message-ID: <545C955B.3070209@oracle.com> Hi David, On 11/6/14 9:18 PM, David Holmes wrote: > Hi Serguei, > > I think I get the gist of this approach but I'm not an expert on the > JVM TI or JDWP event model. My main concern would be how the delay to > the completion of cbVMDeath() might impact things - specifically if it > might be a lengthy delay? 1. At the beginning the VirtualMachine comands check if gdata->vmDead is true and in such case just return with the JDWP_ERROR(VM_DEAD) error or quietly. Normally, the cbVMDeath event callback needs to wait for just one command. Please, see the VirtualMachine.c and the following comment in debugLoop_run(): } else if (gdata->vmDead && ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { /* Protect the VM from calls while dead. * VirtualMachine cmdSet quietly ignores some cmds * after VM death, so, it sends it's own errors. */ outStream_setError(&out, JDWP_ERROR(VM_DEAD)); } else { 2. We do not have many choices. Without a sync on a command completeness we will continue getting WRONG_PHASE errors intermittently. Another choice is to use already reviewed ignore_wrong_phase workaround. Note, the workaround works Ok not for all the commands. I understand, we need to make sure nothing is broken if we choose this approach. :) 3. What delay would you consider lengthy: 1 sec, 10 sec, 1 min.? For instance, I can add 10 sec sleep to provoke the command execution delay and see what can be broken. With 1 min sleep I see some timeouts in the jtreg com/sun/jdi tests though which is probably Ok. Thanks, Serguei > > Thanks, > David > > On 7/11/2014 8:27 AM, serguei.spitsyn at oracle.com wrote: >> Hi reviewers, >> >> I'm suggesting to review a modified fix: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ >> >> >> >> The 3-rd round fix is not right as it caused deadlocks in several tests >> (in nsk.jdi.testlist and jtreg com/sun/jdi). >> >> Here is a deadlock example: >> >> ----------------- lwp# 2 / thread# 2 -------------------- >> ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) >> ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, >> d4400, 0, ffffffff7e357440, 100138730) + 100 >> ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, >> 100137000, 0, 1004405d0, 6e750, 0) + a4 >> ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, >> 100137000, 0, 0, 1, 20000000) + 358 >> ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, >> 100137000, 1, deab, 60000000, 100137000) + c8 >> ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >> (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 >> ffffffff7da2284c jvmtiError >> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, >> ffffffffffffffff, 4, 9aeb0, 100137000) + 8c >> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >> ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c >> ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, ffffffffffefd118, >> ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c >> ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, 1, 2) >> + 10c >> ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + >> 138 >> ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, >> ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 >> ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, >> ffffffff7ab3ad18, 1018, 1000) + 1d8 >> ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, >> ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 >> ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, >> ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, >> ffffffff7e3e6b70) + 30c >> ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, >> ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 >> ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, ffffffff7e3e8b30, >> ffffffff7e357440, 0, 10013700) + 1bc >> ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, >> 10035de68, 0, ffffffff7e4143b0) + 860 >> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >> >> ----------------- lwp# 12 / thread# 12 -------------------- >> ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) >> ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, >> d4400, 0, ffffffff7e357440, 100349930) + 100 >> ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, >> 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 >> ffffffff7da22450 jvmtiError >> JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, >> 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 >> ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, >> ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 >> ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, >> ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c >> ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, >> ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 >> ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, >> ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 >> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >> (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + >> 128 >> ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, 3d8, >> 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 >> ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, >> fffffffea5f3e048, 3d8, 1003497f8) + 3ac >> ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, >> ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 >> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >> >> ----------------- lwp# 13 / thread# 13 -------------------- >> ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) >> ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, >> d4400, 0, ffffffff7e357440, 10034d330) + 100 >> ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) >> (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 >> ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >> (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, 10034c000) >> + e0 >> ffffffff7da2284c jvmtiError >> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, >> ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c >> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >> ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c >> ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, >> 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 >> ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, >> 0, 10000000) + ac >> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >> (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + >> 128 >> ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, 3d8, >> 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 >> ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, >> fffffffea5f3e290, 3d8, 10034cfe8) + 3ac >> ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, >> ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 >> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >> >> >> The details: >> - Thread #2: The cbVMDeath() event handler is waiting on the >> commandCompleteLock in the enqueueCommand(). >> The call chain is: >> cbVMDeath() -> event_callback() -> reportEvents() -> >> eventHelper_reportEvents() -> enqueueCommand(). >> The enqueueCommand() depends on the commandLoop() that has to call >> completeCommand(command) for the command being enqueued. >> This has not been set yet: gdata->vmDead = JNI_TRUE >> >> - Thread #12: The debugLoop_run blocked on the vmDeathLock enter >> >> - Thread #13: The commandLoop is waiting on the blockCommandLoopLock >> in the doBlockCommandLoop(). >> It is because blockCommandLoop == JNI_TRUE which is set in the >> needBlockCommandLoop() >> if the following condition is true: >> (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && >> cmd->u.reportEventComposite.suspendPolicy == >> JDWP_SUSPEND_POLICY(ALL)) >> >> >> It seems, the debugLoop_run() block on the vmDeathLock causes the >> commandLoop() to wait indefinitely. >> The cbVMDeath() can not proceed because the commandLoop() does not make >> a progress. >> >> The vmDeathLock critical section in the cbVMDeath() event callback seems >> to be an overkill (unnecessary). >> A less intrusive synchronization is required here which is to wait until >> the current command is completed >> before returning to the JvmtiExport::post_vm_death(). >> >> The new approach (see new webrev) is to extend the resumeLock >> synchronization pattern >> to all VirtualMachine set of commands, not only the resume command. >> The resumeLock name is replaced with the vmDeathLock to reflect new >> semantics. >> >> In general, we could consider to do the same for the rest of the JDWP >> command sets. >> But it is better to be careful and see how this change goes first. >> >> >> Thanks, >> Serguei >> >> >> On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for the concerns! >>> Testing showed several tests failing with deadlocks. >>> Scenarios are similar to that you describe. >>> >>> Trying to understand the details. >>> >>> Thanks, >>> Serguei >>> >>> On 11/4/14 4:09 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>>> Serguei, >>>>>>> >>>>>>> Thank you for good finding. This approach looks much better for me. >>>>>>> >>>>>>> The fix looks good. >>>>>>> >>>>>>> Is it necessary to release vmDeathLock locks at >>>>>>> eventHandler.c:1244 before call >>>>>>> >>>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>>> >>>>>> I agree this looks necessary, or at least more clean (if things are >>>>>> failing we really don't know what is happening). >>>>> >>>>> Agreed (replied to Dmitry). >>>>> >>>>>> >>>>>> More generally I'm concerned about whether any of the code paths >>>>>> taken >>>>>> while holding the new lock can result in deadlock - in particular >>>>>> with >>>>>> regard to the resumeLock ? >>>>> >>>>> The cbVMDeath() function never holds both vmDeathLock and >>>>> resumeLock at >>>>> the same time, >>>>> so there is no chance for a deadlock that involves both these locks. >>>>> >>>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>>> callbackLock. >>>>> These two locks look completely unrelated to the debugLoop_run(). >>>>> >>>>> The debugLoop_run() function also uses the cmdQueueLock. >>>>> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at >>>>> the >>>>> same time. >>>>> >>>>> So that I do not see any potential to introduce new deadlock with the >>>>> vmDeathLock. >>>>> >>>>> However, it is still easy to overlook something here. >>>>> Please, let me know if you see any danger. >>>> >>>> I was mainly concerned about what might happen in the call chain for >>>> threadControl_resumeAll() (it certainly sounds like it might need to >>>> use a resumeLock :) ). I see direct use of the threadLock and >>>> indirectly the eventHandler lock; but there are further call paths I >>>> did not explore. Wish there was an easy way to determine the >>>> transitive closure of all locks used from a given call. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>>> >>>>>>>> It is 3-rd round of review for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>> >>>>>>>> New webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> For failing scenario, please, refer to the 1-st round RFR >>>>>>>> below. >>>>>>>> >>>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>>> decided to >>>>>>>> switch from a workaround to a real fix. >>>>>>>> >>>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>>> gdata->vmDead = 1. >>>>>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>>>>> >>>>>>>> 165 } else if (gdata->vmDead && >>>>>>>> 166 ((cmd->cmdSet) != >>>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>>> 168 * VirtualMachine cmdSet quietly ignores >>>>>>>> some >>>>>>>> cmds >>>>>>>> 169 * after VM death, so, it sends it's own >>>>>>>> errors. >>>>>>>> 170 */ >>>>>>>> 171 outStream_setError(&out, >>>>>>>> JDWP_ERROR(VM_DEAD)); >>>>>>>> >>>>>>>> >>>>>>>> However, the guard above does not help much if the VM_DEATH >>>>>>>> event >>>>>>>> happens in the middle of a command execution. >>>>>>>> There is a lack of synchronization here. >>>>>>>> >>>>>>>> The fix introduces new lock (vmDeathLock) which does not >>>>>>>> allow to >>>>>>>> execute the commands >>>>>>>> and the VM_DEATH event callback concurrently. >>>>>>>> It should work well for any function that is used in >>>>>>>> implementation of >>>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>> tests >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> The updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The changes are: >>>>>>>>> - added a comment recommended by Staffan >>>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>>> classSignature() >>>>>>>>> >>>>>>>>> The classSignature() function is called in 16 places. >>>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>>> signature >>>>>>>>> and will crash. >>>>>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>>>>> return to this >>>>>>>>> issue after gaining experience with more failure cases that are >>>>>>>>> still >>>>>>>>> expected. >>>>>>>>> The failure with the classSignature() involved was observed only >>>>>>>>> once >>>>>>>>> in the nightly >>>>>>>>> and should be extremely rare reproducible. >>>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the fix for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Open webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> The failing scenario: >>>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>>> shutdown has >>>>>>>>>> been started in the target process. >>>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>>> commands >>>>>>>>>> to the JDWP agent. >>>>>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>>>>> (debuggee side) >>>>>>>>>> are not in sync with the consumer layers. >>>>>>>>>> >>>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>>> the JDI >>>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>>> processes >>>>>>>>>> are uneasy to sync in general. >>>>>>>>>> >>>>>>>>>> As a result the following steps are possible: >>>>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>>>> debuggee >>>>>>>>>> - The debuggee is normally exiting >>>>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>>>> anonymous class unload event >>>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>>> ClassUnloadEvent event >>>>>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>>>>> reference type. >>>>>>>>>> If there is more than one class with the same host >>>>>>>>>> class >>>>>>>>>> signature, it can't distinguish them, >>>>>>>>>> and so, deletes all references and re-retrieves them >>>>>>>>>> again >>>>>>>>>> (see tracing below): >>>>>>>>>> MY_TRACE: JDI: >>>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>>> from JDI >>>>>>>>>> and calls the functions >>>>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>>> GetClassStatus() >>>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>>>>> to the >>>>>>>>>> JDI, and so, the test fails >>>>>>>>>> >>>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>>> dup of >>>>>>>>>> the bug 6988950: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>>> >>>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>>> (6988950 >>>>>>>>>> and 8024865) describing this issue. >>>>>>>>>> >>>>>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>> error >>>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>>> approach >>>>>>>>>> for the raw monitor functions. >>>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>>> tests >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>> >> From david.holmes at oracle.com Fri Nov 7 09:59:53 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Nov 2014 19:59:53 +1000 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545C955B.3070209@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> <545C5620.7080300@oracle.com> <545C955B.3070209@oracle.com> Message-ID: <545C9819.5050806@oracle.com> On 7/11/2014 7:48 PM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 11/6/14 9:18 PM, David Holmes wrote: >> Hi Serguei, >> >> I think I get the gist of this approach but I'm not an expert on the >> JVM TI or JDWP event model. My main concern would be how the delay to >> the completion of cbVMDeath() might impact things - specifically if it >> might be a lengthy delay? > > 1. At the beginning the VirtualMachine comands check if gdata->vmDead is > true > and in such case just return with the JDWP_ERROR(VM_DEAD) error or > quietly. > Normally, the cbVMDeath event callback needs to wait for just one > command. > > Please, see the VirtualMachine.c and the following comment in > debugLoop_run(): > > } else if (gdata->vmDead && > ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { > /* Protect the VM from calls while dead. > * VirtualMachine cmdSet quietly ignores some cmds > * after VM death, so, it sends it's own errors. > */ > outStream_setError(&out, JDWP_ERROR(VM_DEAD)); > } else { > > > 2. We do not have many choices. > Without a sync on a command completeness we will continue getting > WRONG_PHASE errors intermittently. > Another choice is to use already reviewed ignore_wrong_phase > workaround. > Note, the workaround works Ok not for all the commands. > I understand, we need to make sure nothing is broken if we choose > this approach. :) > > 3. What delay would you consider lengthy: 1 sec, 10 sec, 1 min.? Anything that causes something unexpected to happen :) I'm just looking at the code and thinking what might go wrong. Really all we can do is try this and see. Thanks, David > For instance, I can add 10 sec sleep to provoke the command > execution delay and see what can be broken. > With 1 min sleep I see some timeouts in the jtreg com/sun/jdi tests > though which is probably Ok. > > Thanks, > Serguei > >> >> Thanks, >> David >> >> On 7/11/2014 8:27 AM, serguei.spitsyn at oracle.com wrote: >>> Hi reviewers, >>> >>> I'm suggesting to review a modified fix: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ >>> >>> >>> >>> The 3-rd round fix is not right as it caused deadlocks in several tests >>> (in nsk.jdi.testlist and jtreg com/sun/jdi). >>> >>> Here is a deadlock example: >>> >>> ----------------- lwp# 2 / thread# 2 -------------------- >>> ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) >>> ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, >>> d4400, 0, ffffffff7e357440, 100138730) + 100 >>> ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, >>> 100137000, 0, 1004405d0, 6e750, 0) + a4 >>> ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, >>> 100137000, 0, 0, 1, 20000000) + 358 >>> ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, >>> 100137000, 1, deab, 60000000, 100137000) + c8 >>> ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >>> (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 >>> ffffffff7da2284c jvmtiError >>> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, >>> ffffffffffffffff, 4, 9aeb0, 100137000) + 8c >>> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >>> ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c >>> ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, ffffffffffefd118, >>> ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c >>> ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, 1, 2) >>> + 10c >>> ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + >>> 138 >>> ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, >>> ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 >>> ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, >>> ffffffff7ab3ad18, 1018, 1000) + 1d8 >>> ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, >>> ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 >>> ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, >>> ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, >>> ffffffff7e3e6b70) + 30c >>> ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, >>> ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 >>> ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, ffffffff7e3e8b30, >>> ffffffff7e357440, 0, 10013700) + 1bc >>> ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, >>> 10035de68, 0, ffffffff7e4143b0) + 860 >>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>> >>> ----------------- lwp# 12 / thread# 12 -------------------- >>> ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) >>> ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, >>> d4400, 0, ffffffff7e357440, 100349930) + 100 >>> ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, >>> 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 >>> ffffffff7da22450 jvmtiError >>> JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, >>> 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 >>> ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, >>> ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 >>> ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, >>> ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c >>> ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, >>> ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 >>> ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, >>> ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 >>> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >>> (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + >>> 128 >>> ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, 3d8, >>> 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 >>> ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, >>> fffffffea5f3e048, 3d8, 1003497f8) + 3ac >>> ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, >>> ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 >>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>> >>> ----------------- lwp# 13 / thread# 13 -------------------- >>> ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) >>> ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, >>> d4400, 0, ffffffff7e357440, 10034d330) + 100 >>> ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) >>> (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 >>> ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >>> (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, 10034c000) >>> + e0 >>> ffffffff7da2284c jvmtiError >>> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, >>> ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c >>> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >>> ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c >>> ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, >>> 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 >>> ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, >>> 0, 10000000) + ac >>> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >>> (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + >>> 128 >>> ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, 3d8, >>> 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 >>> ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, >>> fffffffea5f3e290, 3d8, 10034cfe8) + 3ac >>> ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, >>> ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 >>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>> >>> >>> The details: >>> - Thread #2: The cbVMDeath() event handler is waiting on the >>> commandCompleteLock in the enqueueCommand(). >>> The call chain is: >>> cbVMDeath() -> event_callback() -> reportEvents() -> >>> eventHelper_reportEvents() -> enqueueCommand(). >>> The enqueueCommand() depends on the commandLoop() that has to call >>> completeCommand(command) for the command being enqueued. >>> This has not been set yet: gdata->vmDead = JNI_TRUE >>> >>> - Thread #12: The debugLoop_run blocked on the vmDeathLock enter >>> >>> - Thread #13: The commandLoop is waiting on the blockCommandLoopLock >>> in the doBlockCommandLoop(). >>> It is because blockCommandLoop == JNI_TRUE which is set in the >>> needBlockCommandLoop() >>> if the following condition is true: >>> (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && >>> cmd->u.reportEventComposite.suspendPolicy == >>> JDWP_SUSPEND_POLICY(ALL)) >>> >>> >>> It seems, the debugLoop_run() block on the vmDeathLock causes the >>> commandLoop() to wait indefinitely. >>> The cbVMDeath() can not proceed because the commandLoop() does not make >>> a progress. >>> >>> The vmDeathLock critical section in the cbVMDeath() event callback seems >>> to be an overkill (unnecessary). >>> A less intrusive synchronization is required here which is to wait until >>> the current command is completed >>> before returning to the JvmtiExport::post_vm_death(). >>> >>> The new approach (see new webrev) is to extend the resumeLock >>> synchronization pattern >>> to all VirtualMachine set of commands, not only the resume command. >>> The resumeLock name is replaced with the vmDeathLock to reflect new >>> semantics. >>> >>> In general, we could consider to do the same for the rest of the JDWP >>> command sets. >>> But it is better to be careful and see how this change goes first. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for the concerns! >>>> Testing showed several tests failing with deadlocks. >>>> Scenarios are similar to that you describe. >>>> >>>> Trying to understand the details. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 11/4/14 4:09 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>>>> Serguei, >>>>>>>> >>>>>>>> Thank you for good finding. This approach looks much better for me. >>>>>>>> >>>>>>>> The fix looks good. >>>>>>>> >>>>>>>> Is it necessary to release vmDeathLock locks at >>>>>>>> eventHandler.c:1244 before call >>>>>>>> >>>>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>>>> >>>>>>> I agree this looks necessary, or at least more clean (if things are >>>>>>> failing we really don't know what is happening). >>>>>> >>>>>> Agreed (replied to Dmitry). >>>>>> >>>>>>> >>>>>>> More generally I'm concerned about whether any of the code paths >>>>>>> taken >>>>>>> while holding the new lock can result in deadlock - in particular >>>>>>> with >>>>>>> regard to the resumeLock ? >>>>>> >>>>>> The cbVMDeath() function never holds both vmDeathLock and >>>>>> resumeLock at >>>>>> the same time, >>>>>> so there is no chance for a deadlock that involves both these locks. >>>>>> >>>>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>>>> callbackLock. >>>>>> These two locks look completely unrelated to the debugLoop_run(). >>>>>> >>>>>> The debugLoop_run() function also uses the cmdQueueLock. >>>>>> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock at >>>>>> the >>>>>> same time. >>>>>> >>>>>> So that I do not see any potential to introduce new deadlock with the >>>>>> vmDeathLock. >>>>>> >>>>>> However, it is still easy to overlook something here. >>>>>> Please, let me know if you see any danger. >>>>> >>>>> I was mainly concerned about what might happen in the call chain for >>>>> threadControl_resumeAll() (it certainly sounds like it might need to >>>>> use a resumeLock :) ). I see direct use of the threadLock and >>>>> indirectly the eventHandler lock; but there are further call paths I >>>>> did not explore. Wish there was an easy way to determine the >>>>> transitive closure of all locks used from a given call. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>>>> >>>>>>>>> It is 3-rd round of review for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>> >>>>>>>>> New webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> For failing scenario, please, refer to the 1-st round RFR >>>>>>>>> below. >>>>>>>>> >>>>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>>>> decided to >>>>>>>>> switch from a workaround to a real fix. >>>>>>>>> >>>>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>>>> gdata->vmDead = 1. >>>>>>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>>>>>> >>>>>>>>> 165 } else if (gdata->vmDead && >>>>>>>>> 166 ((cmd->cmdSet) != >>>>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>>>> 168 * VirtualMachine cmdSet quietly ignores >>>>>>>>> some >>>>>>>>> cmds >>>>>>>>> 169 * after VM death, so, it sends it's own >>>>>>>>> errors. >>>>>>>>> 170 */ >>>>>>>>> 171 outStream_setError(&out, >>>>>>>>> JDWP_ERROR(VM_DEAD)); >>>>>>>>> >>>>>>>>> >>>>>>>>> However, the guard above does not help much if the VM_DEATH >>>>>>>>> event >>>>>>>>> happens in the middle of a command execution. >>>>>>>>> There is a lack of synchronization here. >>>>>>>>> >>>>>>>>> The fix introduces new lock (vmDeathLock) which does not >>>>>>>>> allow to >>>>>>>>> execute the commands >>>>>>>>> and the VM_DEATH event callback concurrently. >>>>>>>>> It should work well for any function that is used in >>>>>>>>> implementation of >>>>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>> tests >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> The updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The changes are: >>>>>>>>>> - added a comment recommended by Staffan >>>>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>>>> classSignature() >>>>>>>>>> >>>>>>>>>> The classSignature() function is called in 16 places. >>>>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>>>> signature >>>>>>>>>> and will crash. >>>>>>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>>>>>> return to this >>>>>>>>>> issue after gaining experience with more failure cases that are >>>>>>>>>> still >>>>>>>>>> expected. >>>>>>>>>> The failure with the classSignature() involved was observed only >>>>>>>>>> once >>>>>>>>>> in the nightly >>>>>>>>>> and should be extremely rare reproducible. >>>>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review the fix for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Open webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> >>>>>>>>>>> The failing scenario: >>>>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>>>> shutdown has >>>>>>>>>>> been started in the target process. >>>>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>>>> commands >>>>>>>>>>> to the JDWP agent. >>>>>>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>>>>>> (debuggee side) >>>>>>>>>>> are not in sync with the consumer layers. >>>>>>>>>>> >>>>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>>>> the JDI >>>>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>>>> processes >>>>>>>>>>> are uneasy to sync in general. >>>>>>>>>>> >>>>>>>>>>> As a result the following steps are possible: >>>>>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>>>>> debuggee >>>>>>>>>>> - The debuggee is normally exiting >>>>>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>>>>> anonymous class unload event >>>>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>>>> ClassUnloadEvent event >>>>>>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>>>>>> reference type. >>>>>>>>>>> If there is more than one class with the same host >>>>>>>>>>> class >>>>>>>>>>> signature, it can't distinguish them, >>>>>>>>>>> and so, deletes all references and re-retrieves them >>>>>>>>>>> again >>>>>>>>>>> (see tracing below): >>>>>>>>>>> MY_TRACE: JDI: >>>>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>>>> from JDI >>>>>>>>>>> and calls the functions >>>>>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>>>> GetClassStatus() >>>>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>>>>>> to the >>>>>>>>>>> JDI, and so, the test fails >>>>>>>>>>> >>>>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>>>> dup of >>>>>>>>>>> the bug 6988950: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>>>> >>>>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>>>> (6988950 >>>>>>>>>>> and 8024865) describing this issue. >>>>>>>>>>> >>>>>>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>>> error >>>>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>>>> approach >>>>>>>>>>> for the raw monitor functions. >>>>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>>>> tests >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From serguei.spitsyn at oracle.com Fri Nov 7 10:13:11 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Nov 2014 02:13:11 -0800 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545C9819.5050806@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> <545C5620.7080300@oracle.com> <545C955B.3070209@oracle.com> <545C9819.5050806@oracle.com> Message-ID: <545C9B37.5020205@oracle.com> On 11/7/14 1:59 AM, David Holmes wrote: > On 7/11/2014 7:48 PM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 11/6/14 9:18 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> I think I get the gist of this approach but I'm not an expert on the >>> JVM TI or JDWP event model. My main concern would be how the delay to >>> the completion of cbVMDeath() might impact things - specifically if it >>> might be a lengthy delay? >> >> 1. At the beginning the VirtualMachine comands check if gdata->vmDead is >> true >> and in such case just return with the JDWP_ERROR(VM_DEAD) error or >> quietly. >> Normally, the cbVMDeath event callback needs to wait for just one >> command. >> >> Please, see the VirtualMachine.c and the following comment in >> debugLoop_run(): >> >> } else if (gdata->vmDead && >> ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { >> /* Protect the VM from calls while dead. >> * VirtualMachine cmdSet quietly ignores some cmds >> * after VM death, so, it sends it's own errors. >> */ >> outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >> } else { >> >> >> 2. We do not have many choices. >> Without a sync on a command completeness we will continue getting >> WRONG_PHASE errors intermittently. >> Another choice is to use already reviewed ignore_wrong_phase >> workaround. >> Note, the workaround works Ok not for all the commands. >> I understand, we need to make sure nothing is broken if we choose >> this approach. :) >> >> 3. What delay would you consider lengthy: 1 sec, 10 sec, 1 min.? > > Anything that causes something unexpected to happen :) I'm just > looking at the code and thinking what might go wrong. Really all we > can do is try this and see. 1 min sleep looks too big as it causes timeout failures of some tests. Launched the nsk.jdi and jtreg com/sun/jdi with 10 sec sleep. Will see the results tomorrow. Thanks! Serguei > > Thanks, > David > >> For instance, I can add 10 sec sleep to provoke the command >> execution delay and see what can be broken. >> With 1 min sleep I see some timeouts in the jtreg com/sun/jdi tests >> though which is probably Ok. >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> >>> On 7/11/2014 8:27 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi reviewers, >>>> >>>> I'm suggesting to review a modified fix: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ >>>> >>>> >>>> >>>> >>>> The 3-rd round fix is not right as it caused deadlocks in several >>>> tests >>>> (in nsk.jdi.testlist and jtreg com/sun/jdi). >>>> >>>> Here is a deadlock example: >>>> >>>> ----------------- lwp# 2 / thread# 2 -------------------- >>>> ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) >>>> ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, >>>> d4400, 0, ffffffff7e357440, 100138730) + 100 >>>> ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, >>>> 100137000, 0, 1004405d0, 6e750, 0) + a4 >>>> ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, >>>> 100137000, 0, 0, 1, 20000000) + 358 >>>> ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, >>>> 100137000, 1, deab, 60000000, 100137000) + c8 >>>> ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >>>> (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 >>>> ffffffff7da2284c jvmtiError >>>> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, >>>> ffffffffffffffff, 4, 9aeb0, 100137000) + 8c >>>> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >>>> ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c >>>> ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, >>>> ffffffffffefd118, >>>> ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c >>>> ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, >>>> 1, 2) >>>> + 10c >>>> ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + >>>> 138 >>>> ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, >>>> ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 >>>> ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, >>>> ffffffff7ab3ad18, 1018, 1000) + 1d8 >>>> ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, >>>> ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 >>>> ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, >>>> ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, >>>> ffffffff7e3e6b70) + 30c >>>> ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, >>>> ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 >>>> ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, >>>> ffffffff7e3e8b30, >>>> ffffffff7e357440, 0, 10013700) + 1bc >>>> ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, >>>> 10035de68, 0, ffffffff7e4143b0) + 860 >>>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>>> >>>> ----------------- lwp# 12 / thread# 12 -------------------- >>>> ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) >>>> ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, >>>> d4400, 0, ffffffff7e357440, 100349930) + 100 >>>> ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, >>>> 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 >>>> ffffffff7da22450 jvmtiError >>>> JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, >>>> 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 >>>> ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, >>>> ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 >>>> ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, >>>> ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c >>>> ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, >>>> ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 >>>> ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, >>>> ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 >>>> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >>>> (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + >>>> 128 >>>> ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, >>>> 3d8, >>>> 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 >>>> ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, >>>> fffffffea5f3e048, 3d8, 1003497f8) + 3ac >>>> ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, >>>> ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 >>>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>>> >>>> ----------------- lwp# 13 / thread# 13 -------------------- >>>> ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) >>>> ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, >>>> d4400, 0, ffffffff7e357440, 10034d330) + 100 >>>> ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) >>>> (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 >>>> ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >>>> (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, >>>> 10034c000) >>>> + e0 >>>> ffffffff7da2284c jvmtiError >>>> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, >>>> ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c >>>> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >>>> ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c >>>> ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, >>>> 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 >>>> ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, >>>> 0, 10000000) + ac >>>> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >>>> (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + >>>> 128 >>>> ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, >>>> 3d8, >>>> 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 >>>> ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, >>>> fffffffea5f3e290, 3d8, 10034cfe8) + 3ac >>>> ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, >>>> ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 >>>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>>> >>>> >>>> The details: >>>> - Thread #2: The cbVMDeath() event handler is waiting on the >>>> commandCompleteLock in the enqueueCommand(). >>>> The call chain is: >>>> cbVMDeath() -> event_callback() -> reportEvents() -> >>>> eventHelper_reportEvents() -> enqueueCommand(). >>>> The enqueueCommand() depends on the commandLoop() that has to >>>> call >>>> completeCommand(command) for the command being enqueued. >>>> This has not been set yet: gdata->vmDead = JNI_TRUE >>>> >>>> - Thread #12: The debugLoop_run blocked on the vmDeathLock enter >>>> >>>> - Thread #13: The commandLoop is waiting on the >>>> blockCommandLoopLock >>>> in the doBlockCommandLoop(). >>>> It is because blockCommandLoop == JNI_TRUE which is set in the >>>> needBlockCommandLoop() >>>> if the following condition is true: >>>> (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && >>>> cmd->u.reportEventComposite.suspendPolicy == >>>> JDWP_SUSPEND_POLICY(ALL)) >>>> >>>> >>>> It seems, the debugLoop_run() block on the vmDeathLock causes the >>>> commandLoop() to wait indefinitely. >>>> The cbVMDeath() can not proceed because the commandLoop() does not >>>> make >>>> a progress. >>>> >>>> The vmDeathLock critical section in the cbVMDeath() event callback >>>> seems >>>> to be an overkill (unnecessary). >>>> A less intrusive synchronization is required here which is to wait >>>> until >>>> the current command is completed >>>> before returning to the JvmtiExport::post_vm_death(). >>>> >>>> The new approach (see new webrev) is to extend the resumeLock >>>> synchronization pattern >>>> to all VirtualMachine set of commands, not only the resume command. >>>> The resumeLock name is replaced with the vmDeathLock to reflect new >>>> semantics. >>>> >>>> In general, we could consider to do the same for the rest of the JDWP >>>> command sets. >>>> But it is better to be careful and see how this change goes first. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> Thank you for the concerns! >>>>> Testing showed several tests failing with deadlocks. >>>>> Scenarios are similar to that you describe. >>>>> >>>>> Trying to understand the details. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 11/4/14 4:09 PM, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>>>>> Serguei, >>>>>>>>> >>>>>>>>> Thank you for good finding. This approach looks much better >>>>>>>>> for me. >>>>>>>>> >>>>>>>>> The fix looks good. >>>>>>>>> >>>>>>>>> Is it necessary to release vmDeathLock locks at >>>>>>>>> eventHandler.c:1244 before call >>>>>>>>> >>>>>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>>>>> >>>>>>>> I agree this looks necessary, or at least more clean (if things >>>>>>>> are >>>>>>>> failing we really don't know what is happening). >>>>>>> >>>>>>> Agreed (replied to Dmitry). >>>>>>> >>>>>>>> >>>>>>>> More generally I'm concerned about whether any of the code paths >>>>>>>> taken >>>>>>>> while holding the new lock can result in deadlock - in particular >>>>>>>> with >>>>>>>> regard to the resumeLock ? >>>>>>> >>>>>>> The cbVMDeath() function never holds both vmDeathLock and >>>>>>> resumeLock at >>>>>>> the same time, >>>>>>> so there is no chance for a deadlock that involves both these >>>>>>> locks. >>>>>>> >>>>>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>>>>> callbackLock. >>>>>>> These two locks look completely unrelated to the debugLoop_run(). >>>>>>> >>>>>>> The debugLoop_run() function also uses the cmdQueueLock. >>>>>>> The debugLoop_run() never holds both vmDeathLock and >>>>>>> cmdQueueLock at >>>>>>> the >>>>>>> same time. >>>>>>> >>>>>>> So that I do not see any potential to introduce new deadlock >>>>>>> with the >>>>>>> vmDeathLock. >>>>>>> >>>>>>> However, it is still easy to overlook something here. >>>>>>> Please, let me know if you see any danger. >>>>>> >>>>>> I was mainly concerned about what might happen in the call chain for >>>>>> threadControl_resumeAll() (it certainly sounds like it might need to >>>>>> use a resumeLock :) ). I see direct use of the threadLock and >>>>>> indirectly the eventHandler lock; but there are further call paths I >>>>>> did not explore. Wish there was an easy way to determine the >>>>>> transitive closure of all locks used from a given call. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> >>>>>>>>>> It is 3-rd round of review for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>>> >>>>>>>>>> New webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary >>>>>>>>>> >>>>>>>>>> For failing scenario, please, refer to the 1-st round RFR >>>>>>>>>> below. >>>>>>>>>> >>>>>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>>>>> decided to >>>>>>>>>> switch from a workaround to a real fix. >>>>>>>>>> >>>>>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>>>>> gdata->vmDead = 1. >>>>>>>>>> The agent debugLoop_run() has a guard against the VM >>>>>>>>>> shutdown: >>>>>>>>>> >>>>>>>>>> 165 } else if (gdata->vmDead && >>>>>>>>>> 166 ((cmd->cmdSet) != >>>>>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>>>>> 168 * VirtualMachine cmdSet quietly ignores >>>>>>>>>> some >>>>>>>>>> cmds >>>>>>>>>> 169 * after VM death, so, it sends it's own >>>>>>>>>> errors. >>>>>>>>>> 170 */ >>>>>>>>>> 171 outStream_setError(&out, >>>>>>>>>> JDWP_ERROR(VM_DEAD)); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, the guard above does not help much if the VM_DEATH >>>>>>>>>> event >>>>>>>>>> happens in the middle of a command execution. >>>>>>>>>> There is a lack of synchronization here. >>>>>>>>>> >>>>>>>>>> The fix introduces new lock (vmDeathLock) which does not >>>>>>>>>> allow to >>>>>>>>>> execute the commands >>>>>>>>>> and the VM_DEATH event callback concurrently. >>>>>>>>>> It should work well for any function that is used in >>>>>>>>>> implementation of >>>>>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>>> tests >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> The updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The changes are: >>>>>>>>>>> - added a comment recommended by Staffan >>>>>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>>>>> classSignature() >>>>>>>>>>> >>>>>>>>>>> The classSignature() function is called in 16 places. >>>>>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>>>>> signature >>>>>>>>>>> and will crash. >>>>>>>>>>> I'm not comfortable to fix all the occurrences now and >>>>>>>>>>> suggest to >>>>>>>>>>> return to this >>>>>>>>>>> issue after gaining experience with more failure cases that are >>>>>>>>>>> still >>>>>>>>>>> expected. >>>>>>>>>>> The failure with the classSignature() involved was observed >>>>>>>>>>> only >>>>>>>>>>> once >>>>>>>>>>> in the nightly >>>>>>>>>>> and should be extremely rare reproducible. >>>>>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Please, review the fix for: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Open webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Summary: >>>>>>>>>>>> >>>>>>>>>>>> The failing scenario: >>>>>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>>>>> shutdown has >>>>>>>>>>>> been started in the target process. >>>>>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>>>>> commands >>>>>>>>>>>> to the JDWP agent. >>>>>>>>>>>> However, the JDI layer (debugger side) and the jdwp >>>>>>>>>>>> agent >>>>>>>>>>>> (debuggee side) >>>>>>>>>>>> are not in sync with the consumer layers. >>>>>>>>>>>> >>>>>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>>>>> the JDI >>>>>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>>>>> processes >>>>>>>>>>>> are uneasy to sync in general. >>>>>>>>>>>> >>>>>>>>>>>> As a result the following steps are possible: >>>>>>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>>>>>> debuggee >>>>>>>>>>>> - The debuggee is normally exiting >>>>>>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>>>>>> anonymous class unload event >>>>>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>>>>> ClassUnloadEvent event >>>>>>>>>>>> - The InternalEventHandler wants to uncache the >>>>>>>>>>>> matching >>>>>>>>>>>> reference type. >>>>>>>>>>>> If there is more than one class with the same host >>>>>>>>>>>> class >>>>>>>>>>>> signature, it can't distinguish them, >>>>>>>>>>>> and so, deletes all references and re-retrieves them >>>>>>>>>>>> again >>>>>>>>>>>> (see tracing below): >>>>>>>>>>>> MY_TRACE: JDI: >>>>>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>>>>> from JDI >>>>>>>>>>>> and calls the functions >>>>>>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>>>>> GetClassStatus() >>>>>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>>>>>>> to the >>>>>>>>>>>> JDI, and so, the test fails >>>>>>>>>>>> >>>>>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>>>>> dup of >>>>>>>>>>>> the bug 6988950: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>>>>> >>>>>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>>>>> (6988950 >>>>>>>>>>>> and 8024865) describing this issue. >>>>>>>>>>>> >>>>>>>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>>>> error >>>>>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>>>>> approach >>>>>>>>>>>> for the raw monitor functions. >>>>>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>>>>> For reference, please, see the file: >>>>>>>>>>>> src/share/back/util.c >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Testing: >>>>>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG >>>>>>>>>>>> com/sun/jdi >>>>>>>>>>>> tests >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> From evgeniya.stepanova at oracle.com Fri Nov 7 11:34:08 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 07 Nov 2014 15:34:08 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545C5AB6.6030103@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> Message-ID: <545CAE30.9010708@oracle.com> David, Filipp, Katja Diff have been updated one more time: java/lang/management/RuntimeMXBean/TestInputArgument.sh and test/java/lang/ref/EnqueuePollRace.java have been changed http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ Thanks On 07.11.2014 9:37, David Holmes wrote: > On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >> New webrev: >> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ > > In: > > test/java/lang/management/RuntimeMXBean/TestInputArgument.sh > > the use of the gc options seems incidental - it's just picking two > innocuous options to use - similar to the JpsHelper case. You could > replace +UseParallelGC with something like +UseFastJNIAccessors > (platform independent and normally true). > > David > ----- > >> Thanks, >> Evgeniya Stepanova >> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>> Thanks a lot! >>> >>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>> Hi Katja, >>>> >>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>> diff accordingly. >>>> >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>> Hi Dima, >>>>> >>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>> Hi Katja, >>>>>> >>>>>> You are right, there will be no conflict, because test ignores any >>>>>> external VM flags. >>>>>> So, adding @requires seems unnecessary here, but... >>>>>> >>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>> not applicable for other areas, like GC, compiler, RT. >>>>> >>>>> This particular case is to test the defined flags are shown up as >>>>> expected. >>>>> >>>>> Evgeniya, >>>>> >>>>> would you mind to change JpsHelper.java instead? >>>>> >>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>> @@ -93,7 +93,7 @@ >>>>> /** >>>>> * VM arguments to start test application with >>>>> */ >>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>> "-XX:+UseParallelGC"}; >>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>> "-XX:+PrintGCDetails"}; >>>>> /** >>>>> * VM flag to start test application with >>>>> */ >>>>> >>>>> Best regards, >>>>> Katja >>>>> >>>>> >>>>> >>>>>> >>>>>> @requires will allow to modify tests to include external vm >>>>>> options without any risk of bumping into conflict and extend area >>>>>> of test applicability. >>>>>> >>>>>> But if you still believe, that @requires is not necessary - it's >>>>>> not a problem, tests could be kept as is. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> >>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>> >>>>>>> Hi Evgeniya, >>>>>>> >>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>> should not be any conflicts either since these tests are running >>>>>>> in driver mode: >>>>>>> >>>>>>> ... >>>>>>> * @run driver TestJpsJar >>>>>>> ... >>>>>>> >>>>>>> which means no flags from above are accepted. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> tag added because tests contain string >>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>> >>>>>>>> and JpsHelper defines >>>>>>>> ... >>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>> ... >>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>> if (testVmArgs == null) { >>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>> } >>>>>>>> return testVmArgs; >>>>>>>> } >>>>>>>> >>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>> cleanup-if we use for example SerialGC we must be sure that tests >>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>>> (with different GC, since it use only Parallel) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>> Hi Evgeniya, >>>>>>>>> >>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>>>> JDK-8019361 >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>> >>>>>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>>>>> is set >>>>>>>>>> outside >>>>>>>>> >>>>>>>>> I don't see why you have done this for the >>>>>>>>> >>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>> >>>>>>>>> tests. They don't set any GC flags. >>>>>>>>> >>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>> skip test >>>>>>>>>> if there is a conflict >>>>>>>>> >>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>> was skipped; or does it only appear in the higher-level jtreg >>>>>>>>> log? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>>>>>> without >>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>> failed >>>>>>>>>> because of the conflict. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Evgeniya Stepanova >>>>>>>>>> >>>>>>>>>> // >>>>>>>> >>>>>>>> -- >>>>>>>> /Evgeniya Stepanova/ >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >> >> -- >> /Evgeniya Stepanova/ -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Fri Nov 7 10:35:17 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 07 Nov 2014 14:35:17 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545CAE30.9010708@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> Message-ID: <545CA065.5030900@oracle.com> Thank you for taking care of it, the fix looks good to me (not a R-reviewer). Thanks, Filipp. On 11/07/2014 03:34 PM, Evgeniya Stepanova wrote: > David, Filipp, Katja > > Diff have been updated one more time: > java/lang/management/RuntimeMXBean/TestInputArgument.sh and > test/java/lang/ref/EnqueuePollRace.java have been changed > http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ > > Thanks > > On 07.11.2014 9:37, David Holmes wrote: >> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>> New webrev: >>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >> >> In: >> >> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >> >> the use of the gc options seems incidental - it's just picking two innocuous >> options to use - similar to the JpsHelper case. You could replace >> +UseParallelGC with something like +UseFastJNIAccessors (platform independent >> and normally true). >> >> David >> ----- >> >>> Thanks, >>> Evgeniya Stepanova >>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>> Thanks a lot! >>>> >>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>> Hi Katja, >>>>> >>>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>>> diff accordingly. >>>>> >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>> Hi Dima, >>>>>> >>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>> Hi Katja, >>>>>>> >>>>>>> You are right, there will be no conflict, because test ignores any >>>>>>> external VM flags. >>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>> >>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>> >>>>>> This particular case is to test the defined flags are shown up as >>>>>> expected. >>>>>> >>>>>> Evgeniya, >>>>>> >>>>>> would you mind to change JpsHelper.java instead? >>>>>> >>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>> @@ -93,7 +93,7 @@ >>>>>> /** >>>>>> * VM arguments to start test application with >>>>>> */ >>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>> "-XX:+UseParallelGC"}; >>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>> "-XX:+PrintGCDetails"}; >>>>>> /** >>>>>> * VM flag to start test application with >>>>>> */ >>>>>> >>>>>> Best regards, >>>>>> Katja >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> @requires will allow to modify tests to include external vm >>>>>>> options without any risk of bumping into conflict and extend area >>>>>>> of test applicability. >>>>>>> >>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>> not a problem, tests could be kept as is. >>>>>>> >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>>>> >>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>> >>>>>>>> Hi Evgeniya, >>>>>>>> >>>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>> should not be any conflicts either since these tests are running >>>>>>>> in driver mode: >>>>>>>> >>>>>>>> ... >>>>>>>> * @run driver TestJpsJar >>>>>>>> ... >>>>>>>> >>>>>>>> which means no flags from above are accepted. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Katja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> tag added because tests contain string >>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>> >>>>>>>>> and JpsHelper defines >>>>>>>>> ... >>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>> ... >>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>> if (testVmArgs == null) { >>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>> } >>>>>>>>> return testVmArgs; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>> cleanup-if we use for example SerialGC we must be sure that tests >>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Evgeniya Stepanova >>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>> Hi Evgeniya, >>>>>>>>>> >>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>>>>> JDK-8019361 >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>>>>>> is set >>>>>>>>>>> outside >>>>>>>>>> >>>>>>>>>> I don't see why you have done this for the >>>>>>>>>> >>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>> >>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>> >>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>> skip test >>>>>>>>>>> if there is a conflict >>>>>>>>>> >>>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>>> was skipped; or does it only appear in the higher-level jtreg log? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>>>>>>> without >>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>> failed >>>>>>>>>>> because of the conflict. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>> >>>>>>>>>>> // >>>>>>>>> >>>>>>>>> -- >>>>>>>>> /Evgeniya Stepanova/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>>> >>> >>> -- >>> /Evgeniya Stepanova/ > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Fri Nov 7 15:32:29 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 07 Nov 2014 16:32:29 +0100 Subject: RFR (XXS): 8064348: Add TraceEvent::is_enabled() for embedded/minimal builds Message-ID: <545CE60D.8070200@oracle.com> Hi, Can I please have reviews for the following small patch to enable usage of TraceEvent::is_enabled() even when INCLUDE_TRACE is not defined? Webrev: http://cr.openjdk.java.net/~mlarsson/8064348/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8064348 Thanks, Marcus From erik.helin at oracle.com Fri Nov 7 15:40:31 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 07 Nov 2014 16:40:31 +0100 Subject: RFR (XXS): 8064348: Add TraceEvent::is_enabled() for embedded/minimal builds In-Reply-To: <545CE60D.8070200@oracle.com> References: <545CE60D.8070200@oracle.com> Message-ID: <545CE7EF.7090303@oracle.com> Hi Markus, looks good, Reviewed. I can sponsor this change. If it is ok for the svc team, I would like to push this via the jdk9/hs-gc/hotspot repo (not via jdk9/hs-rt/hotspot) since we have other upcoming patches depending on this one. Thanks, Erik On 2014-11-07 16:32, Marcus Larsson wrote: > Hi, > > Can I please have reviews for the following small patch to enable usage > of TraceEvent::is_enabled() even when INCLUDE_TRACE is not defined? > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8064348/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8064348 > > Thanks, > Marcus From daniel.daugherty at oracle.com Fri Nov 7 18:10:45 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 07 Nov 2014 11:10:45 -0700 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545BF5CD.6010008@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> Message-ID: <545D0B25.4070602@oracle.com> On 11/6/14 3:27 PM, serguei.spitsyn at oracle.com wrote: > Hi reviewers, > > I'm suggesting to review a modified fix: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ > src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line 130: * that a command after VM_DEATH will be allowed to complete Perhaps "VM command" instead of "command" just to be clear. Thumbs up! And we'll want to push this changeset after a push to Main_Baseline so that it has (at least) a week to bake... Dan > > > The 3-rd round fix is not right as it caused deadlocks in several > tests (in nsk.jdi.testlist and jtreg com/sun/jdi). > > Here is a deadlock example: > > ----------------- lwp# 2 / thread# 2 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, > d4400, 0, ffffffff7e357440, 100138730) + 100 > ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, > 100137000, 0, 1004405d0, 6e750, 0) + a4 > ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, > 100137000, 0, 0, 1, 20000000) + 358 > ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, > 100137000, 1, deab, 60000000, 100137000) + c8 > ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) > (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 > ffffffff7da2284c jvmtiError > JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, > ffffffffffffffff, 4, 9aeb0, 100137000) + 8c > ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, > ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c > ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, ffffffffffefd118, > ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c > ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, 1, 2) > + 10c > ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + 138 > ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, > ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 > ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, > ffffffff7ab3ad18, 1018, 1000) + 1d8 > ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, > ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 > ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, > ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, > ffffffff7e3e6b70) + 30c > ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, > ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 > ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, > ffffffff7e3e8b30, ffffffff7e357440, 0, 10013700) + 1bc > ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, > 10035de68, 0, ffffffff7e4143b0) + 860 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > ----------------- lwp# 12 / thread# 12 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, > d4400, 0, ffffffff7e357440, 100349930) + 100 > ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, > 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 > ffffffff7da22450 jvmtiError > JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, > 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 > ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, > ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 > ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, > ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c > ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, > ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 > ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, > ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 > ffffffff7da56b18 void JvmtiAgentThread::call_start_function() > (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + 128 > ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, > 3d8, 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 > ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, > fffffffea5f3e048, 3d8, 1003497f8) + 3ac > ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, > ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > ----------------- lwp# 13 / thread# 13 -------------------- > ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) > ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, > d4400, 0, ffffffff7e357440, 10034d330) + 100 > ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) > (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 > ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) > (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, > 10034c000) + e0 > ffffffff7da2284c jvmtiError > JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, > ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c > ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, > ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c > ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, > 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 > ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, > 0, 10000000) + ac > ffffffff7da56b18 void JvmtiAgentThread::call_start_function() > (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + 128 > ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, > 3d8, 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 > ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, > fffffffea5f3e290, 3d8, 10034cfe8) + 3ac > ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, > ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 > ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) > > > The details: > - Thread #2: The cbVMDeath() event handler is waiting on the > commandCompleteLock in the enqueueCommand(). > The call chain is: > cbVMDeath() -> event_callback() -> reportEvents() -> > eventHelper_reportEvents() -> enqueueCommand(). > The enqueueCommand() depends on the commandLoop() that has to call > completeCommand(command) for the command being enqueued. > This has not been set yet: gdata->vmDead = JNI_TRUE > > - Thread #12: The debugLoop_run blocked on the vmDeathLock enter > > - Thread #13: The commandLoop is waiting on the blockCommandLoopLock > in the doBlockCommandLoop(). > It is because blockCommandLoop == JNI_TRUE which is set in the > needBlockCommandLoop() > if the following condition is true: > (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && > cmd->u.reportEventComposite.suspendPolicy == > JDWP_SUSPEND_POLICY(ALL)) > > > It seems, the debugLoop_run() block on the vmDeathLock causes the > commandLoop() to wait indefinitely. > The cbVMDeath() can not proceed because the commandLoop() does not > make a progress. > > The vmDeathLock critical section in the cbVMDeath() event callback > seems to be an overkill (unnecessary). > A less intrusive synchronization is required here which is to wait > until the current command is completed > before returning to the JvmtiExport::post_vm_death(). > > The new approach (see new webrev) is to extend the resumeLock > synchronization pattern > to all VirtualMachine set of commands, not only the resume command. > The resumeLock name is replaced with the vmDeathLock to reflect new > semantics. > > In general, we could consider to do the same for the rest of the JDWP > command sets. > But it is better to be careful and see how this change goes first. > > > Thanks, > Serguei > > > On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for the concerns! >> Testing showed several tests failing with deadlocks. >> Scenarios are similar to that you describe. >> >> Trying to understand the details. >> >> Thanks, >> Serguei >> >> On 11/4/14 4:09 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>> Serguei, >>>>>> >>>>>> Thank you for good finding. This approach looks much better for me. >>>>>> >>>>>> The fix looks good. >>>>>> >>>>>> Is it necessary to release vmDeathLock locks at >>>>>> eventHandler.c:1244 before call >>>>>> >>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>> >>>>> I agree this looks necessary, or at least more clean (if things are >>>>> failing we really don't know what is happening). >>>> >>>> Agreed (replied to Dmitry). >>>> >>>>> >>>>> More generally I'm concerned about whether any of the code paths >>>>> taken >>>>> while holding the new lock can result in deadlock - in particular >>>>> with >>>>> regard to the resumeLock ? >>>> >>>> The cbVMDeath() function never holds both vmDeathLock and >>>> resumeLock at >>>> the same time, >>>> so there is no chance for a deadlock that involves both these locks. >>>> >>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>> callbackLock. >>>> These two locks look completely unrelated to the debugLoop_run(). >>>> >>>> The debugLoop_run() function also uses the cmdQueueLock. >>>> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock >>>> at the >>>> same time. >>>> >>>> So that I do not see any potential to introduce new deadlock with the >>>> vmDeathLock. >>>> >>>> However, it is still easy to overlook something here. >>>> Please, let me know if you see any danger. >>> >>> I was mainly concerned about what might happen in the call chain for >>> threadControl_resumeAll() (it certainly sounds like it might need to >>> use a resumeLock :) ). I see direct use of the threadLock and >>> indirectly the eventHandler lock; but there are further call paths I >>> did not explore. Wish there was an easy way to determine the >>> transitive closure of all locks used from a given call. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> >>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> It is 3-rd round of review for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>> >>>>>>> New webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> For failing scenario, please, refer to the 1-st round RFR below. >>>>>>> >>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>> decided to >>>>>>> switch from a workaround to a real fix. >>>>>>> >>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>> gdata->vmDead = 1. >>>>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>>>> >>>>>>> 165 } else if (gdata->vmDead && >>>>>>> 166 ((cmd->cmdSet) != >>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>> 168 * VirtualMachine cmdSet quietly ignores some >>>>>>> cmds >>>>>>> 169 * after VM death, so, it sends it's own >>>>>>> errors. >>>>>>> 170 */ >>>>>>> 171 outStream_setError(&out, >>>>>>> JDWP_ERROR(VM_DEAD)); >>>>>>> >>>>>>> >>>>>>> However, the guard above does not help much if the VM_DEATH >>>>>>> event >>>>>>> happens in the middle of a command execution. >>>>>>> There is a lack of synchronization here. >>>>>>> >>>>>>> The fix introduces new lock (vmDeathLock) which does not >>>>>>> allow to >>>>>>> execute the commands >>>>>>> and the VM_DEATH event callback concurrently. >>>>>>> It should work well for any function that is used in >>>>>>> implementation of >>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>> tests >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> The updated webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The changes are: >>>>>>>> - added a comment recommended by Staffan >>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>> classSignature() >>>>>>>> >>>>>>>> The classSignature() function is called in 16 places. >>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>> signature >>>>>>>> and will crash. >>>>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>>>> return to this >>>>>>>> issue after gaining experience with more failure cases that are >>>>>>>> still >>>>>>>> expected. >>>>>>>> The failure with the classSignature() involved was observed >>>>>>>> only once >>>>>>>> in the nightly >>>>>>>> and should be extremely rare reproducible. >>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>> >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> The failing scenario: >>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>> shutdown has >>>>>>>>> been started in the target process. >>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>> commands >>>>>>>>> to the JDWP agent. >>>>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>>>> (debuggee side) >>>>>>>>> are not in sync with the consumer layers. >>>>>>>>> >>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>> the JDI >>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>> processes >>>>>>>>> are uneasy to sync in general. >>>>>>>>> >>>>>>>>> As a result the following steps are possible: >>>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>>> debuggee >>>>>>>>> - The debuggee is normally exiting >>>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>>> anonymous class unload event >>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>> ClassUnloadEvent event >>>>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>>>> reference type. >>>>>>>>> If there is more than one class with the same host >>>>>>>>> class >>>>>>>>> signature, it can't distinguish them, >>>>>>>>> and so, deletes all references and re-retrieves them >>>>>>>>> again >>>>>>>>> (see tracing below): >>>>>>>>> MY_TRACE: JDI: >>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>> from JDI >>>>>>>>> and calls the functions >>>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>> GetClassStatus() >>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>> - As a result the jdwp backend reports the JVMTI error >>>>>>>>> to the >>>>>>>>> JDI, and so, the test fails >>>>>>>>> >>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>> dup of >>>>>>>>> the bug 6988950: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>> >>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>> (6988950 >>>>>>>>> and 8024865) describing this issue. >>>>>>>>> >>>>>>>>> The fix is to skip reporting the JVMTI_ERROR_WRONG_PHASE >>>>>>>>> error >>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>> approach >>>>>>>>> for the raw monitor functions. >>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>> tests >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >> > From serguei.spitsyn at oracle.com Fri Nov 7 19:26:16 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Nov 2014 11:26:16 -0800 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545D0B25.4070602@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> <545D0B25.4070602@oracle.com> Message-ID: <545D1CD8.3020304@oracle.com> On 11/7/14 10:10 AM, Daniel D. Daugherty wrote: > On 11/6/14 3:27 PM, serguei.spitsyn at oracle.com wrote: >> Hi reviewers, >> >> I'm suggesting to review a modified fix: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ >> > > src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c > line 130: * that a command after VM_DEATH will be allowed to complete > Perhaps "VM command" instead of "command" just to be clear. Agreed - done > > Thumbs up! And we'll want to push this changeset after a push > to Main_Baseline so that it has (at least) a week to bake... Ok. Thanks a lot! Serguei > > Dan > > >> >> >> The 3-rd round fix is not right as it caused deadlocks in several >> tests (in nsk.jdi.testlist and jtreg com/sun/jdi). >> >> Here is a deadlock example: >> >> ----------------- lwp# 2 / thread# 2 -------------------- >> ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) >> ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, >> d4400, 0, ffffffff7e357440, 100138730) + 100 >> ffffffff7dc3151c int Monitor::IWait(Thread*,long) (ffffffff7e3c5b98, >> 100137000, 0, 1004405d0, 6e750, 0) + a4 >> ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, >> 100137000, 0, 0, 1, 20000000) + 358 >> ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, >> 100137000, 1, deab, 60000000, 100137000) + c8 >> ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >> (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + 258 >> ffffffff7da2284c jvmtiError >> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, >> ffffffffffffffff, 4, 9aeb0, 100137000) + 8c >> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >> ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c >> ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, >> ffffffffffefd118, ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c >> ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, 1, >> 2) + 10c >> ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + 138 >> ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, >> ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + 360 >> ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, >> ffffffff7ab3ad18, 1018, 1000) + 1d8 >> ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, 100137000, >> ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 >> ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, >> ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, >> ffffffff7e3e6b70) + 30c >> ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, >> ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 >> ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, >> ffffffff7e3e8b30, ffffffff7e357440, 0, 10013700) + 1bc >> ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, >> 10035de68, 0, ffffffff7e4143b0) + 860 >> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >> >> ----------------- lwp# 12 / thread# 12 -------------------- >> ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) >> ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, >> d4400, 0, ffffffff7e357440, 100349930) + 100 >> ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) (10034a070, >> 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 >> ffffffff7da22450 jvmtiError >> JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, >> 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 >> ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, >> ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 >> ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, >> ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c >> ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, >> ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 >> ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, >> ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 >> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >> (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + >> 128 >> ffffffff7de6a678 void JavaThread::thread_main_inner() (100348800, >> 3d8, 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 >> ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, >> fffffffea5f3e048, 3d8, 1003497f8) + 3ac >> ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, >> ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 >> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >> >> ----------------- lwp# 13 / thread# 13 -------------------- >> ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) >> ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, >> d4400, 0, ffffffff7e357440, 10034d330) + 100 >> ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) >> (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 >> ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >> (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, >> 10034c000) + e0 >> ffffffff7da2284c jvmtiError >> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, >> ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c >> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >> ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c >> ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, >> 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 >> ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, ffffffff7ab3ad18, >> 0, 10000000) + ac >> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >> (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + >> 128 >> ffffffff7de6a678 void JavaThread::thread_main_inner() (10034c000, >> 3d8, 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 >> ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, >> fffffffea5f3e290, 3d8, 10034cfe8) + 3ac >> ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, >> ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 >> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >> >> >> The details: >> - Thread #2: The cbVMDeath() event handler is waiting on the >> commandCompleteLock in the enqueueCommand(). >> The call chain is: >> cbVMDeath() -> event_callback() -> reportEvents() -> >> eventHelper_reportEvents() -> enqueueCommand(). >> The enqueueCommand() depends on the commandLoop() that has to call >> completeCommand(command) for the command being enqueued. >> This has not been set yet: gdata->vmDead = JNI_TRUE >> >> - Thread #12: The debugLoop_run blocked on the vmDeathLock enter >> >> - Thread #13: The commandLoop is waiting on the >> blockCommandLoopLock in the doBlockCommandLoop(). >> It is because blockCommandLoop == JNI_TRUE which is set in the >> needBlockCommandLoop() >> if the following condition is true: >> (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && >> cmd->u.reportEventComposite.suspendPolicy == >> JDWP_SUSPEND_POLICY(ALL)) >> >> >> It seems, the debugLoop_run() block on the vmDeathLock causes the >> commandLoop() to wait indefinitely. >> The cbVMDeath() can not proceed because the commandLoop() does not >> make a progress. >> >> The vmDeathLock critical section in the cbVMDeath() event callback >> seems to be an overkill (unnecessary). >> A less intrusive synchronization is required here which is to wait >> until the current command is completed >> before returning to the JvmtiExport::post_vm_death(). >> >> The new approach (see new webrev) is to extend the resumeLock >> synchronization pattern >> to all VirtualMachine set of commands, not only the resume command. >> The resumeLock name is replaced with the vmDeathLock to reflect new >> semantics. >> >> In general, we could consider to do the same for the rest of the JDWP >> command sets. >> But it is better to be careful and see how this change goes first. >> >> >> Thanks, >> Serguei >> >> >> On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for the concerns! >>> Testing showed several tests failing with deadlocks. >>> Scenarios are similar to that you describe. >>> >>> Trying to understand the details. >>> >>> Thanks, >>> Serguei >>> >>> On 11/4/14 4:09 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>>> Serguei, >>>>>>> >>>>>>> Thank you for good finding. This approach looks much better for me. >>>>>>> >>>>>>> The fix looks good. >>>>>>> >>>>>>> Is it necessary to release vmDeathLock locks at >>>>>>> eventHandler.c:1244 before call >>>>>>> >>>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>>> >>>>>> I agree this looks necessary, or at least more clean (if things are >>>>>> failing we really don't know what is happening). >>>>> >>>>> Agreed (replied to Dmitry). >>>>> >>>>>> >>>>>> More generally I'm concerned about whether any of the code paths >>>>>> taken >>>>>> while holding the new lock can result in deadlock - in particular >>>>>> with >>>>>> regard to the resumeLock ? >>>>> >>>>> The cbVMDeath() function never holds both vmDeathLock and >>>>> resumeLock at >>>>> the same time, >>>>> so there is no chance for a deadlock that involves both these locks. >>>>> >>>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>>> callbackLock. >>>>> These two locks look completely unrelated to the debugLoop_run(). >>>>> >>>>> The debugLoop_run() function also uses the cmdQueueLock. >>>>> The debugLoop_run() never holds both vmDeathLock and cmdQueueLock >>>>> at the >>>>> same time. >>>>> >>>>> So that I do not see any potential to introduce new deadlock with the >>>>> vmDeathLock. >>>>> >>>>> However, it is still easy to overlook something here. >>>>> Please, let me know if you see any danger. >>>> >>>> I was mainly concerned about what might happen in the call chain >>>> for threadControl_resumeAll() (it certainly sounds like it might >>>> need to use a resumeLock :) ). I see direct use of the threadLock >>>> and indirectly the eventHandler lock; but there are further call >>>> paths I did not explore. Wish there was an easy way to determine >>>> the transitive closure of all locks used from a given call. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>>> >>>>>>>> It is 3-rd round of review for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>> >>>>>>>> New webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> For failing scenario, please, refer to the 1-st round RFR >>>>>>>> below. >>>>>>>> >>>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>>> decided to >>>>>>>> switch from a workaround to a real fix. >>>>>>>> >>>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>>> gdata->vmDead = 1. >>>>>>>> The agent debugLoop_run() has a guard against the VM shutdown: >>>>>>>> >>>>>>>> 165 } else if (gdata->vmDead && >>>>>>>> 166 ((cmd->cmdSet) != >>>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>>> 168 * VirtualMachine cmdSet quietly ignores >>>>>>>> some >>>>>>>> cmds >>>>>>>> 169 * after VM death, so, it sends it's own >>>>>>>> errors. >>>>>>>> 170 */ >>>>>>>> 171 outStream_setError(&out, >>>>>>>> JDWP_ERROR(VM_DEAD)); >>>>>>>> >>>>>>>> >>>>>>>> However, the guard above does not help much if the VM_DEATH >>>>>>>> event >>>>>>>> happens in the middle of a command execution. >>>>>>>> There is a lack of synchronization here. >>>>>>>> >>>>>>>> The fix introduces new lock (vmDeathLock) which does not >>>>>>>> allow to >>>>>>>> execute the commands >>>>>>>> and the VM_DEATH event callback concurrently. >>>>>>>> It should work well for any function that is used in >>>>>>>> implementation of >>>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG >>>>>>>> com/sun/jdi tests >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> The updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The changes are: >>>>>>>>> - added a comment recommended by Staffan >>>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>>> classSignature() >>>>>>>>> >>>>>>>>> The classSignature() function is called in 16 places. >>>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>>> signature >>>>>>>>> and will crash. >>>>>>>>> I'm not comfortable to fix all the occurrences now and suggest to >>>>>>>>> return to this >>>>>>>>> issue after gaining experience with more failure cases that >>>>>>>>> are still >>>>>>>>> expected. >>>>>>>>> The failure with the classSignature() involved was observed >>>>>>>>> only once >>>>>>>>> in the nightly >>>>>>>>> and should be extremely rare reproducible. >>>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the fix for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Open webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> The failing scenario: >>>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>>> shutdown has >>>>>>>>>> been started in the target process. >>>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>>> commands >>>>>>>>>> to the JDWP agent. >>>>>>>>>> However, the JDI layer (debugger side) and the jdwp agent >>>>>>>>>> (debuggee side) >>>>>>>>>> are not in sync with the consumer layers. >>>>>>>>>> >>>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>>> the JDI >>>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>>> processes >>>>>>>>>> are uneasy to sync in general. >>>>>>>>>> >>>>>>>>>> As a result the following steps are possible: >>>>>>>>>> - The test debugger sends a 'quit' command to the test >>>>>>>>>> debuggee >>>>>>>>>> - The debuggee is normally exiting >>>>>>>>>> - The jdwp backend reports (over the jdwp protocol) an >>>>>>>>>> anonymous class unload event >>>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>>> ClassUnloadEvent event >>>>>>>>>> - The InternalEventHandler wants to uncache the matching >>>>>>>>>> reference type. >>>>>>>>>> If there is more than one class with the same host >>>>>>>>>> class >>>>>>>>>> signature, it can't distinguish them, >>>>>>>>>> and so, deletes all references and re-retrieves >>>>>>>>>> them again >>>>>>>>>> (see tracing below): >>>>>>>>>> MY_TRACE: JDI: >>>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>>> from JDI >>>>>>>>>> and calls the functions >>>>>>>>>> classesForSignature() and classStatus() recursively. >>>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>>> GetClassStatus() >>>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>> - As a result the jdwp backend reports the JVMTI >>>>>>>>>> error to the >>>>>>>>>> JDI, and so, the test fails >>>>>>>>>> >>>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>>> dup of >>>>>>>>>> the bug 6988950: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>>> >>>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>>> (6988950 >>>>>>>>>> and 8024865) describing this issue. >>>>>>>>>> >>>>>>>>>> The fix is to skip reporting the >>>>>>>>>> JVMTI_ERROR_WRONG_PHASE error >>>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>>> approach >>>>>>>>>> for the raw monitor functions. >>>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>>> For reference, please, see the file: src/share/back/util.c >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG com/sun/jdi >>>>>>>>>> tests >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>> >> > From serguei.spitsyn at oracle.com Fri Nov 7 19:41:01 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Nov 2014 11:41:01 -0800 Subject: 4-nd round RFR (XS) 6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) In-Reply-To: <545C9B37.5020205@oracle.com> References: <54503EC2.6070601@oracle.com> <54518EE1.9040208@oracle.com> <5453F9F4.20309@oracle.com> <5454B258.1080104@oracle.com> <54570B68.3060806@oracle.com> <545729A3.7090301@oracle.com> <54596AC2.6050502@oracle.com> <5459FB96.9020404@oracle.com> <545BF5CD.6010008@oracle.com> <545C5620.7080300@oracle.com> <545C955B.3070209@oracle.com> <545C9819.5050806@oracle.com> <545C9B37.5020205@oracle.com> Message-ID: <545D204D.3060805@oracle.com> On 11/7/14 2:13 AM, serguei.spitsyn at oracle.com wrote: > On 11/7/14 1:59 AM, David Holmes wrote: >> On 7/11/2014 7:48 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 11/6/14 9:18 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> I think I get the gist of this approach but I'm not an expert on the >>>> JVM TI or JDWP event model. My main concern would be how the delay to >>>> the completion of cbVMDeath() might impact things - specifically if it >>>> might be a lengthy delay? >>> >>> 1. At the beginning the VirtualMachine comands check if >>> gdata->vmDead is >>> true >>> and in such case just return with the JDWP_ERROR(VM_DEAD) error or >>> quietly. >>> Normally, the cbVMDeath event callback needs to wait for just one >>> command. >>> >>> Please, see the VirtualMachine.c and the following comment in >>> debugLoop_run(): >>> >>> } else if (gdata->vmDead && >>> ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { >>> /* Protect the VM from calls while dead. >>> * VirtualMachine cmdSet quietly ignores some cmds >>> * after VM death, so, it sends it's own errors. >>> */ >>> outStream_setError(&out, JDWP_ERROR(VM_DEAD)); >>> } else { >>> >>> >>> 2. We do not have many choices. >>> Without a sync on a command completeness we will continue getting >>> WRONG_PHASE errors intermittently. >>> Another choice is to use already reviewed ignore_wrong_phase >>> workaround. >>> Note, the workaround works Ok not for all the commands. >>> I understand, we need to make sure nothing is broken if we choose >>> this approach. :) >>> >>> 3. What delay would you consider lengthy: 1 sec, 10 sec, 1 min.? >> >> Anything that causes something unexpected to happen :) I'm just >> looking at the code and thinking what might go wrong. Really all we >> can do is try this and see. > > 1 min sleep looks too big as it causes timeout failures of some tests. > Launched the nsk.jdi and jtreg com/sun/jdi with 10 sec sleep. > Will see the results tomorrow. The nsk.jdi and the jtreg com/sun/jdi tests are passed with the 10 sec sleep. Thanks, Serguei > > Thanks! > Serguei > >> >> Thanks, >> David >> >>> For instance, I can add 10 sec sleep to provoke the command >>> execution delay and see what can be broken. >>> With 1 min sleep I see some timeouts in the jtreg com/sun/jdi >>> tests >>> though which is probably Ok. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 7/11/2014 8:27 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi reviewers, >>>>> >>>>> I'm suggesting to review a modified fix: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.4/ >>>>> >>>>> >>>>> >>>>> >>>>> The 3-rd round fix is not right as it caused deadlocks in several >>>>> tests >>>>> (in nsk.jdi.testlist and jtreg com/sun/jdi). >>>>> >>>>> Here is a deadlock example: >>>>> >>>>> ----------------- lwp# 2 / thread# 2 -------------------- >>>>> ffffffff7e8dc6a4 lwp_cond_wait (100138748, 100138730, 0, 0) >>>>> ffffffff7dcad148 void os::PlatformEvent::park() (100138700, d4788, >>>>> d4400, 0, ffffffff7e357440, 100138730) + 100 >>>>> ffffffff7dc3151c int Monitor::IWait(Thread*,long) >>>>> (ffffffff7e3c5b98, >>>>> 100137000, 0, 1004405d0, 6e750, 0) + a4 >>>>> ffffffff7dc324d0 bool Monitor::wait(bool,long,bool) (1004405d0, >>>>> 100137000, 0, 0, 1, 20000000) + 358 >>>>> ffffffff7de6c530 int JavaThread::java_suspend_self() (1004405d0, >>>>> 100137000, 1, deab, 60000000, 100137000) + c8 >>>>> ffffffff7da5f478 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >>>>> (10034bdc0, ffffffffffffffff, ffffffff7e3e6bd0, 100137000, 1, 2) + >>>>> 258 >>>>> ffffffff7da2284c jvmtiError >>>>> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bdc0, >>>>> ffffffffffffffff, 4, 9aeb0, 100137000) + 8c >>>>> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >>>>> ffffffff7ab3ad18, ffffffff7ab3ad18, 0) + 3c >>>>> ffffffff7aa1c804 enqueueCommand (10034bb90, 102c00, >>>>> ffffffffffefd118, >>>>> ffffffff7ab3ad18, 102c00, ffffffff7ab3bd60) + 14c >>>>> ffffffff7aa1e23c eventHelper_reportEvents (d8, 100135d70, 2, 1, >>>>> 1, 2) >>>>> + 10c >>>>> ffffffff7aa181f8 reportEvents (1001371f8, 0, 0, 14, 100135d70, 0) + >>>>> 138 >>>>> ffffffff7aa187b8 event_callback (1001371f8, ffffffff7b0ffa88, >>>>> ffffffff7aa23150, ffffffff7aa376a0, ffffffff7ab3ad18, 100441ad0) + >>>>> 360 >>>>> ffffffff7aa1b870 cbVMDeath (800, 1001371f8, ffffffff7aa37c48, >>>>> ffffffff7ab3ad18, 1018, 1000) + 1d8 >>>>> ffffffff7da3635c void JvmtiExport::post_vm_death() (1ffc, >>>>> 100137000, >>>>> ffffffff7e3e8b30, ffffffff7e357440, 1, 10010cf30) + 534 >>>>> ffffffff7d7bb104 void before_exit(JavaThread*) (100137000, >>>>> ffffffff7e392350, ffffffff7e3fb938, 6ed99, ffffffff7e357440, >>>>> ffffffff7e3e6b70) + 30c >>>>> ffffffff7de72128 bool Threads::destroy_vm() (100137000, 100110a40, >>>>> ffffffff7e3f22f4, ffffffff7e3e6ab0, ffffffff7e357440, 30000000) + 100 >>>>> ffffffff7d8d0664 jni_DestroyJavaVM (100137000, 1ffc, >>>>> ffffffff7e3e8b30, >>>>> ffffffff7e357440, 0, 10013700) + 1bc >>>>> ffffffff7ee08680 JavaMain (ffffffff7e3da790, 0, ffffffff7e3da790, >>>>> 10035de68, 0, ffffffff7e4143b0) + 860 >>>>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>>>> >>>>> ----------------- lwp# 12 / thread# 12 -------------------- >>>>> ffffffff7e8dc6a4 lwp_cond_wait (100349948, 100349930, 0, 0) >>>>> ffffffff7dcad148 void os::PlatformEvent::park() (100349900, d4788, >>>>> d4400, 0, ffffffff7e357440, 100349930) + 100 >>>>> ffffffff7da5f010 int JvmtiRawMonitor::raw_enter(Thread*) >>>>> (10034a070, >>>>> 100348800, a, ffffffff7e3de340, 1, ffffffff7e115ff4) + 258 >>>>> ffffffff7da22450 jvmtiError >>>>> JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (ffffffff7ea05a00, >>>>> 10034a070, 1c7, 100348800, ffffffff7e357440, 4) + a0 >>>>> ffffffff7aa2f288 debugMonitorEnter (10034a070, c18, c00, >>>>> ffffffff7ab3ad28, ffffffff7ab3b940, 0) + 38 >>>>> ffffffff7aa14134 debugLoop_run (ffffffff7ab3b940, 1000, >>>>> ffffffff7ab3ad28, ffffffff7aa360d0, ffffffff5b2ff718, c18) + 11c >>>>> ffffffff7aa2a4f8 connectionInitiated (ffffffff5b504010, 1358, 1000, >>>>> ffffffff7ab3ad28, 1, ffffffff7ab3c080) + e0 >>>>> ffffffff7aa2a7d4 attachThread (ffffffffffefee48, 101000, >>>>> ffffffff5b504010, ffffffff7ab3ad28, 0, 10000000) + 54 >>>>> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >>>>> (100348800, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034880, 1) + >>>>> 128 >>>>> ffffffff7de6a678 void JavaThread::thread_main_inner() >>>>> (100348800, 3d8, >>>>> 1003497f8, 100349420, ffffffff5b2ff9f8, 0) + 90 >>>>> ffffffff7de6a5b4 void JavaThread::run() (100348800, 100349442, c, >>>>> fffffffea5f3e048, 3d8, 1003497f8) + 3ac >>>>> ffffffff7dc9f2e4 java_start (ca800, 100348800, ca904, >>>>> ffffffff7e16ff31, ffffffff7e357440, 4797) + 2e4 >>>>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>>>> >>>>> ----------------- lwp# 13 / thread# 13 -------------------- >>>>> ffffffff7e8dc6a4 lwp_cond_wait (10034d348, 10034d330, 0, 0) >>>>> ffffffff7dcad148 void os::PlatformEvent::park() (10034d300, d4788, >>>>> d4400, 0, ffffffff7e357440, 10034d330) + 100 >>>>> ffffffff7da5eac8 int JvmtiRawMonitor::SimpleWait(Thread*,long) >>>>> (10034bed0, 10034c000, ffffffffffffffff, 241000, 0, 10034c000) + 100 >>>>> ffffffff7da5f300 int JvmtiRawMonitor::raw_wait(long,bool,Thread*) >>>>> (10034bed0, ffffffffffffffff, 1, 10034c000, ffffffff7e357440, >>>>> 10034c000) >>>>> + e0 >>>>> ffffffff7da2284c jvmtiError >>>>> JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*,long) (92800, 10034bed0, >>>>> ffffffffffffffff, 4, 9aeb0, 10034c000) + 8c >>>>> ffffffff7aa2f47c debugMonitorWait (ffffffff7ab3ba10, c28, c00, >>>>> ffffffff7ab3ad18, ffffffff7ab3b940, 0) + 3c >>>>> ffffffff7aa1d838 doBlockCommandLoop (800, 1038, ffffffff7ab3ad18, >>>>> 1000, ffffffff7ab3ad18, ffffffff7ab3bd60) + 48 >>>>> ffffffff7aa1da3c commandLoop (c28, 10034c1f8, c00, >>>>> ffffffff7ab3ad18, >>>>> 0, 10000000) + ac >>>>> ffffffff7da56b18 void JvmtiAgentThread::call_start_function() >>>>> (10034c000, ffffffff7e3e8b38, 916f0, ffffffff7e357440, 10034c00, 1) + >>>>> 128 >>>>> ffffffff7de6a678 void JavaThread::thread_main_inner() >>>>> (10034c000, 3d8, >>>>> 10034cfe8, 10034cc10, ffffffff5b0ffbf8, 0) + 90 >>>>> ffffffff7de6a5b4 void JavaThread::run() (10034c000, 10034cc28, d, >>>>> fffffffea5f3e290, 3d8, 10034cfe8) + 3ac >>>>> ffffffff7dc9f2e4 java_start (ca800, 10034c000, ca904, >>>>> ffffffff7e16ff31, ffffffff7e357440, 181a) + 2e4 >>>>> ffffffff7e8d8558 _lwp_start (0, 0, 0, 0, 0, 0) >>>>> >>>>> >>>>> The details: >>>>> - Thread #2: The cbVMDeath() event handler is waiting on the >>>>> commandCompleteLock in the enqueueCommand(). >>>>> The call chain is: >>>>> cbVMDeath() -> event_callback() -> reportEvents() -> >>>>> eventHelper_reportEvents() -> enqueueCommand(). >>>>> The enqueueCommand() depends on the commandLoop() that has >>>>> to call >>>>> completeCommand(command) for the command being enqueued. >>>>> This has not been set yet: gdata->vmDead = JNI_TRUE >>>>> >>>>> - Thread #12: The debugLoop_run blocked on the vmDeathLock enter >>>>> >>>>> - Thread #13: The commandLoop is waiting on the >>>>> blockCommandLoopLock >>>>> in the doBlockCommandLoop(). >>>>> It is because blockCommandLoop == JNI_TRUE which is set in the >>>>> needBlockCommandLoop() >>>>> if the following condition is true: >>>>> (cmd->commandKind == COMMAND_REPORT_EVENT_COMPOSITE && >>>>> cmd->u.reportEventComposite.suspendPolicy == >>>>> JDWP_SUSPEND_POLICY(ALL)) >>>>> >>>>> >>>>> It seems, the debugLoop_run() block on the vmDeathLock causes the >>>>> commandLoop() to wait indefinitely. >>>>> The cbVMDeath() can not proceed because the commandLoop() does not >>>>> make >>>>> a progress. >>>>> >>>>> The vmDeathLock critical section in the cbVMDeath() event callback >>>>> seems >>>>> to be an overkill (unnecessary). >>>>> A less intrusive synchronization is required here which is to wait >>>>> until >>>>> the current command is completed >>>>> before returning to the JvmtiExport::post_vm_death(). >>>>> >>>>> The new approach (see new webrev) is to extend the resumeLock >>>>> synchronization pattern >>>>> to all VirtualMachine set of commands, not only the resume command. >>>>> The resumeLock name is replaced with the vmDeathLock to reflect new >>>>> semantics. >>>>> >>>>> In general, we could consider to do the same for the rest of the JDWP >>>>> command sets. >>>>> But it is better to be careful and see how this change goes first. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 11/5/14 2:27 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for the concerns! >>>>>> Testing showed several tests failing with deadlocks. >>>>>> Scenarios are similar to that you describe. >>>>>> >>>>>> Trying to understand the details. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 11/4/14 4:09 PM, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> On 3/11/2014 5:07 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 11/2/14 8:58 PM, David Holmes wrote: >>>>>>>>> On 1/11/2014 8:13 PM, Dmitry Samersoff wrote: >>>>>>>>>> Serguei, >>>>>>>>>> >>>>>>>>>> Thank you for good finding. This approach looks much better >>>>>>>>>> for me. >>>>>>>>>> >>>>>>>>>> The fix looks good. >>>>>>>>>> >>>>>>>>>> Is it necessary to release vmDeathLock locks at >>>>>>>>>> eventHandler.c:1244 before call >>>>>>>>>> >>>>>>>>>> EXIT_ERROR(error,"Can't clear event callbacks on vm death"); ? >>>>>>>>> >>>>>>>>> I agree this looks necessary, or at least more clean (if >>>>>>>>> things are >>>>>>>>> failing we really don't know what is happening). >>>>>>>> >>>>>>>> Agreed (replied to Dmitry). >>>>>>>> >>>>>>>>> >>>>>>>>> More generally I'm concerned about whether any of the code paths >>>>>>>>> taken >>>>>>>>> while holding the new lock can result in deadlock - in particular >>>>>>>>> with >>>>>>>>> regard to the resumeLock ? >>>>>>>> >>>>>>>> The cbVMDeath() function never holds both vmDeathLock and >>>>>>>> resumeLock at >>>>>>>> the same time, >>>>>>>> so there is no chance for a deadlock that involves both these >>>>>>>> locks. >>>>>>>> >>>>>>>> Two more locks used in the cbVMDeath() are the callbackBlock and >>>>>>>> callbackLock. >>>>>>>> These two locks look completely unrelated to the debugLoop_run(). >>>>>>>> >>>>>>>> The debugLoop_run() function also uses the cmdQueueLock. >>>>>>>> The debugLoop_run() never holds both vmDeathLock and >>>>>>>> cmdQueueLock at >>>>>>>> the >>>>>>>> same time. >>>>>>>> >>>>>>>> So that I do not see any potential to introduce new deadlock >>>>>>>> with the >>>>>>>> vmDeathLock. >>>>>>>> >>>>>>>> However, it is still easy to overlook something here. >>>>>>>> Please, let me know if you see any danger. >>>>>>> >>>>>>> I was mainly concerned about what might happen in the call chain >>>>>>> for >>>>>>> threadControl_resumeAll() (it certainly sounds like it might >>>>>>> need to >>>>>>> use a resumeLock :) ). I see direct use of the threadLock and >>>>>>> indirectly the eventHandler lock; but there are further call >>>>>>> paths I >>>>>>> did not explore. Wish there was an easy way to determine the >>>>>>> transitive closure of all locks used from a given call. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2014-11-01 00:07, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> >>>>>>>>>>> It is 3-rd round of review for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>>>> >>>>>>>>>>> New webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.3/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> For failing scenario, please, refer to the 1-st round RFR >>>>>>>>>>> below. >>>>>>>>>>> >>>>>>>>>>> I've found what is missed in the jdwp agent shutdown and >>>>>>>>>>> decided to >>>>>>>>>>> switch from a workaround to a real fix. >>>>>>>>>>> >>>>>>>>>>> The agent VM_DEATH callback sets the gdata field: >>>>>>>>>>> gdata->vmDead = 1. >>>>>>>>>>> The agent debugLoop_run() has a guard against the VM >>>>>>>>>>> shutdown: >>>>>>>>>>> >>>>>>>>>>> 165 } else if (gdata->vmDead && >>>>>>>>>>> 166 ((cmd->cmdSet) != >>>>>>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>>>>>> 167 /* Protect the VM from calls while dead. >>>>>>>>>>> 168 * VirtualMachine cmdSet quietly ignores >>>>>>>>>>> some >>>>>>>>>>> cmds >>>>>>>>>>> 169 * after VM death, so, it sends it's own >>>>>>>>>>> errors. >>>>>>>>>>> 170 */ >>>>>>>>>>> 171 outStream_setError(&out, >>>>>>>>>>> JDWP_ERROR(VM_DEAD)); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> However, the guard above does not help much if the VM_DEATH >>>>>>>>>>> event >>>>>>>>>>> happens in the middle of a command execution. >>>>>>>>>>> There is a lack of synchronization here. >>>>>>>>>>> >>>>>>>>>>> The fix introduces new lock (vmDeathLock) which does not >>>>>>>>>>> allow to >>>>>>>>>>> execute the commands >>>>>>>>>>> and the VM_DEATH event callback concurrently. >>>>>>>>>>> It should work well for any function that is used in >>>>>>>>>>> implementation of >>>>>>>>>>> the JDWP_COMMAND_SET(VirtualMachine) . >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG >>>>>>>>>>> com/sun/jdi >>>>>>>>>>> tests >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/29/14 6:05 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> The updated webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.2/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The changes are: >>>>>>>>>>>> - added a comment recommended by Staffan >>>>>>>>>>>> - removed the ignore_wrong_phase() call from function >>>>>>>>>>>> classSignature() >>>>>>>>>>>> >>>>>>>>>>>> The classSignature() function is called in 16 places. >>>>>>>>>>>> Most of them do not tolerate the NULL in place of returned >>>>>>>>>>>> signature >>>>>>>>>>>> and will crash. >>>>>>>>>>>> I'm not comfortable to fix all the occurrences now and >>>>>>>>>>>> suggest to >>>>>>>>>>>> return to this >>>>>>>>>>>> issue after gaining experience with more failure cases that >>>>>>>>>>>> are >>>>>>>>>>>> still >>>>>>>>>>>> expected. >>>>>>>>>>>> The failure with the classSignature() involved was observed >>>>>>>>>>>> only >>>>>>>>>>>> once >>>>>>>>>>>> in the nightly >>>>>>>>>>>> and should be extremely rare reproducible. >>>>>>>>>>>> I'll file a placeholder bug if necessary. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> On 10/28/14 6:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Please, review the fix for: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6988950 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Open webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/jdk/6988950-JDWP-wrong-phase.1/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Summary: >>>>>>>>>>>>> >>>>>>>>>>>>> The failing scenario: >>>>>>>>>>>>> The debugger and the debuggee are well aware a VM >>>>>>>>>>>>> shutdown has >>>>>>>>>>>>> been started in the target process. >>>>>>>>>>>>> The debugger at this point is not expected to send any >>>>>>>>>>>>> commands >>>>>>>>>>>>> to the JDWP agent. >>>>>>>>>>>>> However, the JDI layer (debugger side) and the jdwp >>>>>>>>>>>>> agent >>>>>>>>>>>>> (debuggee side) >>>>>>>>>>>>> are not in sync with the consumer layers. >>>>>>>>>>>>> >>>>>>>>>>>>> One reason is because the test debugger does not invoke >>>>>>>>>>>>> the JDI >>>>>>>>>>>>> method VirtualMachine.dispose(). >>>>>>>>>>>>> Another reason is that the Debugger and the debuggee >>>>>>>>>>>>> processes >>>>>>>>>>>>> are uneasy to sync in general. >>>>>>>>>>>>> >>>>>>>>>>>>> As a result the following steps are possible: >>>>>>>>>>>>> - The test debugger sends a 'quit' command to the >>>>>>>>>>>>> test >>>>>>>>>>>>> debuggee >>>>>>>>>>>>> - The debuggee is normally exiting >>>>>>>>>>>>> - The jdwp backend reports (over the jdwp >>>>>>>>>>>>> protocol) an >>>>>>>>>>>>> anonymous class unload event >>>>>>>>>>>>> - The JDI InternalEventHandler thread handles the >>>>>>>>>>>>> ClassUnloadEvent event >>>>>>>>>>>>> - The InternalEventHandler wants to uncache the >>>>>>>>>>>>> matching >>>>>>>>>>>>> reference type. >>>>>>>>>>>>> If there is more than one class with the same host >>>>>>>>>>>>> class >>>>>>>>>>>>> signature, it can't distinguish them, >>>>>>>>>>>>> and so, deletes all references and re-retrieves >>>>>>>>>>>>> them >>>>>>>>>>>>> again >>>>>>>>>>>>> (see tracing below): >>>>>>>>>>>>> MY_TRACE: JDI: >>>>>>>>>>>>> VirtualMachineImpl.retrieveClassesBySignature: >>>>>>>>>>>>> sig=Ljava/lang/invoke/LambdaForm$DMH; >>>>>>>>>>>>> - The jdwp backend debugLoop_run() gets the command >>>>>>>>>>>>> from JDI >>>>>>>>>>>>> and calls the functions >>>>>>>>>>>>> classesForSignature() and classStatus() >>>>>>>>>>>>> recursively. >>>>>>>>>>>>> - The classStatus() makes a call to the JVMTI >>>>>>>>>>>>> GetClassStatus() >>>>>>>>>>>>> and gets the JVMTI_ERROR_WRONG_PHASE >>>>>>>>>>>>> - As a result the jdwp backend reports the JVMTI >>>>>>>>>>>>> error >>>>>>>>>>>>> to the >>>>>>>>>>>>> JDI, and so, the test fails >>>>>>>>>>>>> >>>>>>>>>>>>> For details, see the analysis in bug report closed as a >>>>>>>>>>>>> dup of >>>>>>>>>>>>> the bug 6988950: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024865 >>>>>>>>>>>>> >>>>>>>>>>>>> Some similar cases can be found in the two bug reports >>>>>>>>>>>>> (6988950 >>>>>>>>>>>>> and 8024865) describing this issue. >>>>>>>>>>>>> >>>>>>>>>>>>> The fix is to skip reporting the >>>>>>>>>>>>> JVMTI_ERROR_WRONG_PHASE >>>>>>>>>>>>> error >>>>>>>>>>>>> as it is normal at the VM shutdown. >>>>>>>>>>>>> The original jdwp backend implementation had a similar >>>>>>>>>>>>> approach >>>>>>>>>>>>> for the raw monitor functions. >>>>>>>>>>>>> Threy use the ignore_vm_death() to workaround the >>>>>>>>>>>>> JVMTI_ERROR_WRONG_PHASE errors. >>>>>>>>>>>>> For reference, please, see the file: >>>>>>>>>>>>> src/share/back/util.c >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: >>>>>>>>>>>>> Run nsk.jdi.testlist, nsk.jdwp.testlist and JTREG >>>>>>>>>>>>> com/sun/jdi >>>>>>>>>>>>> tests >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > From staffan.larsen at oracle.com Fri Nov 7 19:49:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 7 Nov 2014 20:49:58 +0100 Subject: RFR (XXS): 8064348: Add TraceEvent::is_enabled() for embedded/minimal builds In-Reply-To: <545CE7EF.7090303@oracle.com> References: <545CE60D.8070200@oracle.com> <545CE7EF.7090303@oracle.com> Message-ID: > On 7 nov 2014, at 16:40, Erik Helin wrote: > > Hi Markus, > > looks good, Reviewed. I can sponsor this change. > > If it is ok for the svc team, I would like to push this via the jdk9/hs-gc/hotspot repo (not via jdk9/hs-rt/hotspot) since we have other upcoming patches depending on this one. That is ok with me if you do a jprt run with the jdk_jfr tests. /Staffan > > Thanks, > Erik > > On 2014-11-07 16:32, Marcus Larsson wrote: >> Hi, >> >> Can I please have reviews for the following small patch to enable usage >> of TraceEvent::is_enabled() even when INCLUDE_TRACE is not defined? >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8064348/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8064348 >> >> Thanks, >> Marcus From mandy.chung at oracle.com Fri Nov 7 23:41:50 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 07 Nov 2014 15:41:50 -0800 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545CAE30.9010708@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> Message-ID: <545D58BE.3030404@oracle.com> On 11/7/14 3:34 AM, Evgeniya Stepanova wrote: > > http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ What are the valid values ofvm.gc? It's a bit awk for null as a valid value and I would imagine "*" wildcard may be a better value? Since you are touching test/java/lang/management/** tests, we can remove these shell tests and add multiple @run in the java test instead. It'd be great if you can take this opportunity to remove these shell tests as they are not really necessary. thanks Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dmitry.Fazunenko at oracle.com Sat Nov 8 08:11:36 2014 From: Dmitry.Fazunenko at oracle.com (Dmitry Fazunenko) Date: Sat, 08 Nov 2014 11:11:36 +0300 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545D58BE.3030404@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <545D58BE.3030404@oracle.com> Message-ID: <545DD038.7030108@oracle.com> Hi Mandy, On 08.11.2014 02:41, Mandy Chung wrote: > On 11/7/14 3:34 AM, Evgeniya Stepanova wrote: >> >> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ > > What are the valid values ofvm.gc? It's a bit awk for null as a valid > value and I would imagine "*" wildcard may be a better value? vm.gc variable is set by jtreg based on passed -XX:+Use???GC command line vm flag. If such flag is not given vm.gc will be set to null (or "null" which is same). So, vm.gc could be set to any value. In reality the following strings are expected: null, "Parallel", "Serial", "G1", "ConcMarkSweep". null means "not set", it doesn't mean "any". If a test is applicable for all GC - you don't need @requires vm.gc == "*" > > Since you are touching test/java/lang/management/** tests, we can > remove these shell tests and add multiple @run in the java test > instead. It'd be great if you can take this opportunity to remove > these shell tests as they are not really necessary. Yes, agree, shell is not necessary here. But such refactoring is better to be done as part of another RFE. Thanks, Dima > > thanks > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Sun Nov 9 07:28:57 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 09 Nov 2014 10:28:57 +0300 Subject: RFR(XS): JDK-8059131 sawindbg.dll is not compiled with /SAFESEH Message-ID: <545F17B9.8010809@oracle.com> Hi Everybody, Please review an one-line fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8059131/webrev.01/ Make variable $(SAFESEH_FLAG) is never set and is not used outside of this line, so replaced with /SAFESEH link option. -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. From markus.gronlund at oracle.com Sun Nov 9 09:24:19 2014 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Sun, 9 Nov 2014 01:24:19 -0800 (PST) Subject: RFR(XS): JDK-8059131 sawindbg.dll is not compiled with /SAFESEH In-Reply-To: <545F17B9.8010809@oracle.com> References: <545F17B9.8010809@oracle.com> Message-ID: Hi Dmitry, Looks good, thanks for fixing. /Markus -----Original Message----- From: Dmitry Samersoff Sent: den 9 november 2014 08:29 To: serviceability-dev at openjdk.java.net Subject: RFR(XS): JDK-8059131 sawindbg.dll is not compiled with /SAFESEH Hi Everybody, Please review an one-line fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8059131/webrev.01/ Make variable $(SAFESEH_FLAG) is never set and is not used outside of this line, so replaced with /SAFESEH link option. -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. From staffan.larsen at oracle.com Mon Nov 10 08:16:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 10 Nov 2014 09:16:33 +0100 Subject: RFR(XS): JDK-8059131 sawindbg.dll is not compiled with /SAFESEH In-Reply-To: <545F17B9.8010809@oracle.com> References: <545F17B9.8010809@oracle.com> Message-ID: <3B2CC461-87D9-4E5D-B540-6DC1CC52C818@oracle.com> Looks good! Thanks, /Staffan > On 9 nov 2014, at 08:28, Dmitry Samersoff wrote: > > Hi Everybody, > > Please review an one-line fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8059131/webrev.01/ > > Make variable $(SAFESEH_FLAG) is never set and is not used outside of > this line, so replaced with /SAFESEH link option. > > -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. From marcus.larsson at oracle.com Mon Nov 10 08:37:51 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 10 Nov 2014 09:37:51 +0100 Subject: RFR (XXS): 8064348: Add TraceEvent::is_enabled() for embedded/minimal builds In-Reply-To: References: <545CE60D.8070200@oracle.com> <545CE7EF.7090303@oracle.com> Message-ID: <5460795F.8090106@oracle.com> Hi, I somehow managed to add the const qualifier to this method although it shouldn't be there. Updated webrev (without the const): http://cr.openjdk.java.net/~mlarsson/8064348/webrev.01/ Thanks, Marcus On 07/11/14 20:49, Staffan Larsen wrote: >> On 7 nov 2014, at 16:40, Erik Helin wrote: >> >> Hi Markus, >> >> looks good, Reviewed. I can sponsor this change. >> >> If it is ok for the svc team, I would like to push this via the jdk9/hs-gc/hotspot repo (not via jdk9/hs-rt/hotspot) since we have other upcoming patches depending on this one. > That is ok with me if you do a jprt run with the jdk_jfr tests. > > /Staffan > >> Thanks, >> Erik >> >> On 2014-11-07 16:32, Marcus Larsson wrote: >>> Hi, >>> >>> Can I please have reviews for the following small patch to enable usage >>> of TraceEvent::is_enabled() even when INCLUDE_TRACE is not defined? >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8064348/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8064348 >>> >>> Thanks, >>> Marcus From bengt.rutisson at oracle.com Mon Nov 10 17:28:56 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 10 Nov 2014 18:28:56 +0100 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545DD038.7030108@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <545D58BE.3030404@oracle.com> <545DD038.7030108@oracle.com> Message-ID: <5460F5D8.1070609@oracle.com> On 2014-11-08 09:11, Dmitry Fazunenko wrote: > Hi Mandy, > > On 08.11.2014 02:41, Mandy Chung wrote: >> On 11/7/14 3:34 AM, Evgeniya Stepanova wrote: >>> >>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >> >> What are the valid values ofvm.gc? It's a bit awk for null as a >> valid value and I would imagine "*" wildcard may be a better value? > > vm.gc variable is set by jtreg based on passed -XX:+Use???GC command > line vm flag. > If such flag is not given vm.gc will be set to null (or "null" which > is same). > > So, vm.gc could be set to any value. In reality the following strings > are expected: null, "Parallel", "Serial", "G1", "ConcMarkSweep". > > null means "not set", it doesn't mean "any". > If a test is applicable for all GC - you don't need @requires vm.gc == "*" Note that the vm.gc abstraction is not really flexible enough for our purposes. The way to specify a GC is constantly evolving and it is not suitable to have this logic in the JTreg harness. I've filed this bug about the issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7901091 Bengt > >> >> Since you are touching test/java/lang/management/** tests, we can >> remove these shell tests and add multiple @run in the java test >> instead. It'd be great if you can take this opportunity to remove >> these shell tests as they are not really necessary. > > Yes, agree, shell is not necessary here. But such refactoring is > better to be done as part of another RFE. > > Thanks, > Dima > > >> >> thanks >> Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Sat Nov 8 00:03:07 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 7 Nov 2014 19:03:07 -0500 Subject: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545D58BE.3030404@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <545D58BE.3030404@oracle.com> Message-ID: <87912E2F-25C4-43F2-995E-C38A14B1B864@oracle.com> On Nov 7, 2014, at 6:41 PM, Mandy Chung wrote: > > On 11/7/14 3:34 AM, Evgeniya Stepanova wrote: >> >> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ > > What are the valid values of vm.gc? It's a bit awk for null as a valid value and I would imagine "*" wildcard may be a better value? > > Since you are touching test/java/lang/management/** tests, we can remove these shell tests and add multiple @run in the java test instead. It'd be great if you can take this opportunity to remove these shell tests as they are not really necessary. Note that @requires can?t cope with multiple @run lines with differing requirements. I just ran into this with a test that needs to be run against either G1 or CMS. Rather than one test with multiple @run lines, I needed to use multiple tests, each with a single @run line and corresponding @requires constraint. See https://bugs.openjdk.java.net/browse/CODETOOLS-7901090. From Dmitry.Fazunenko at oracle.com Mon Nov 10 21:14:59 2014 From: Dmitry.Fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 11 Nov 2014 00:14:59 +0300 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <5460F5D8.1070609@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <545D58BE.3030404@oracle.com> <545DD038.7030108@oracle.com> <5460F5D8.1070609@oracle.com> Message-ID: <54612AD3.7040904@oracle.com> On 10.11.2014 20:28, Bengt Rutisson wrote: > > On 2014-11-08 09:11, Dmitry Fazunenko wrote: >> Hi Mandy, >> >> On 08.11.2014 02:41, Mandy Chung wrote: >>> On 11/7/14 3:34 AM, Evgeniya Stepanova wrote: >>>> >>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>> >>> What are the valid values ofvm.gc? It's a bit awk for null as a >>> valid value and I would imagine "*" wildcard may be a better value? >> >> vm.gc variable is set by jtreg based on passed -XX:+Use???GC command >> line vm flag. >> If such flag is not given vm.gc will be set to null (or "null" which >> is same). >> >> So, vm.gc could be set to any value. In reality the following strings >> are expected: null, "Parallel", "Serial", "G1", "ConcMarkSweep". >> >> null means "not set", it doesn't mean "any". >> If a test is applicable for all GC - you don't need @requires vm.gc >> == "*" > > Note that the vm.gc abstraction is not really flexible enough for our > purposes. The way to specify a GC is constantly evolving and it is not > suitable to have this logic in the JTreg harness. I've filed this bug > about the issue: > > https://bugs.openjdk.java.net/browse/CODETOOLS-7901091 You're absolutely right! @requires vm.gc has limited use. Using VM specific class to decide if a test applicable or not will be much more flexible for us. I'm not sure that this approach is applicable for jtreg... But let's see -- Thanks, Dima > > Bengt > >> >>> >>> Since you are touching test/java/lang/management/** tests, we can >>> remove these shell tests and add multiple @run in the java test >>> instead. It'd be great if you can take this opportunity to remove >>> these shell tests as they are not really necessary. >> >> Yes, agree, shell is not necessary here. But such refactoring is >> better to be done as part of another RFE. >> >> Thanks, >> Dima >> >> >>> >>> thanks >>> Mandy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Mon Nov 10 21:16:22 2014 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 10 Nov 2014 13:16:22 -0800 Subject: RFR (8u40) 8064288 : sun.management.Flag should loadLibrary() Message-ID: <54612B26.6010105@oracle.com> Please review my change for: 8064288 - sun.management.Flag should loadLibrary() JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8064288 Webrev: http://cr.openjdk.java.net/~bchristi/8064288/webrev.0/ Thanks, -Brent From mandy.chung at oracle.com Mon Nov 10 21:38:55 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Nov 2014 13:38:55 -0800 Subject: RFR (8u40) 8064288 : sun.management.Flag should loadLibrary() In-Reply-To: <54612B26.6010105@oracle.com> References: <54612B26.6010105@oracle.com> Message-ID: <5461306F.9000303@oracle.com> On 11/10/2014 1:16 PM, Brent Christian wrote: > Please review my change for: > > 8064288 - sun.management.Flag should loadLibrary() > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8064288 > > Webrev: > http://cr.openjdk.java.net/~bchristi/8064288/webrev.0/ Looks fine to me. Mandy From daniel.daugherty at oracle.com Tue Nov 11 00:00:41 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 10 Nov 2014 17:00:41 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 Message-ID: <546151A9.1080100@oracle.com> Greetings, I have a Solaris Full Debug Symbols (FDS) fix ready for review. Yes, it is a small fix, but it is in Makefiles so feel free to run screaming from the room... :-) On the plus side the fix does delete two work around source files (Coleen would say that's a Good Thing (TM)!) The fix is to detect the version of GNU objcopy that is being used on the machine and only enable Full Debug Symbols when that version is 2.21.1 or newer. If you don't have the right version, then the build drops back to pre-FDS build configs with a message like this: WARNING: /usr/sfw/bin/gobjcopy --version info: WARNING: GNU objcopy 2.15 WARNING: an objcopy version of 2.21.1 or newer is needed to create valid .debuginfo files. WARNING: ignoring above objcopy command. WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC version. WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 version. WARNING: Solaris 11 Update 1 contains the correct version. INFO: no objcopy cmd found so cannot create .debuginfo files. INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 This work is being tracked by the following bug IDs: JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC https://bugs.openjdk.java.net/browse/JDK-8033602 JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on Solaris X86 https://bugs.openjdk.java.net/browse/JDK-8034005 Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ Testing: - JPRT test jobs to verify that the current JPRT Solaris hosts are happy - local builds on my Solaris 10 X86 machine to verify that the wrong version of GNU objcopy is caught Thanks, in advance, for any comments, questions or suggestions. Dan From dmitry.samersoff at oracle.com Tue Nov 11 08:35:40 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Nov 2014 11:35:40 +0300 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <5461CA5C.30409@oracle.com> Dan, 1. defs.make: It might be better to join obcopy version check and condition at ll.190 otherwise the user will have a wrong version warning and then misleading message "no objcopy cmd found" 2. Did you consider moving objcopy detection to configure? -Dmitry On 2014-11-11 03:00, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create valid > .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC > version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From daniel.daugherty at oracle.com Tue Nov 11 15:40:32 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Nov 2014 08:40:32 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5461CA5C.30409@oracle.com> References: <546151A9.1080100@oracle.com> <5461CA5C.30409@oracle.com> Message-ID: <54622DF0.5010800@oracle.com> Dmitry, Thanks for the quick review! Replies embedded below... On 11/11/14 1:35 AM, Dmitry Samersoff wrote: > Dan, > > 1. defs.make: > > It might be better to join obcopy version check and condition at ll.190 I looked at that... The seemingly natural place to put the version check is actually in the else branch on line 194... However, if the version check is bad, then you have to make a second check for a reset OBJCOPY value (along with indenting all the code another level or two). It just looked ugly... it seemed better to keep the version check separate from the other logic. > otherwise the user will have a wrong version warning and then misleading > message "no objcopy cmd found" However, part of that wrong version warning is this line: WARNING: ignoring above objcopy command. so in reality that "no objcopy cmd found" is just confirming that we are indeed ignoring the objcopy cmd that we found... > 2. Did you consider moving objcopy detection to configure? No because this fix has to be backported to JDK8u and JDK7 since we support FDS in those releases... Of course, the build-infra team is always welcome to use a new bug to evolve this code for JDK9 and newer. Again, thanks for the review! Dan > > > -Dmitry > > > On 2014-11-11 03:00, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >> .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >> version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From dmitry.samersoff at oracle.com Tue Nov 11 16:21:36 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Nov 2014 19:21:36 +0300 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <54622DF0.5010800@oracle.com> References: <546151A9.1080100@oracle.com> <5461CA5C.30409@oracle.com> <54622DF0.5010800@oracle.com> Message-ID: <54623790.4080103@oracle.com> Dan, Thank you for the explanation. The fix looks good for me. -Dmitry On 2014-11-11 18:40, Daniel D. Daugherty wrote: > Dmitry, > > Thanks for the quick review! > > Replies embedded below... > > > On 11/11/14 1:35 AM, Dmitry Samersoff wrote: >> Dan, >> >> 1. defs.make: >> >> It might be better to join obcopy version check and condition at ll.190 > > I looked at that... The seemingly natural place to put the version check > is actually in the else branch on line 194... However, if the version > check is bad, then you have to make a second check for a reset OBJCOPY > value (along with indenting all the code another level or two). > > It just looked ugly... it seemed better to keep the version check > separate from the other logic. > > >> otherwise the user will have a wrong version warning and then misleading >> message "no objcopy cmd found" > > However, part of that wrong version warning is this line: > > WARNING: ignoring above objcopy command. > > so in reality that "no objcopy cmd found" is just confirming > that we are indeed ignoring the objcopy cmd that we found... > > >> 2. Did you consider moving objcopy detection to configure? > > No because this fix has to be backported to JDK8u and JDK7 since > we support FDS in those releases... > > Of course, the build-infra team is always welcome to use a new > bug to evolve this code for JDK9 and newer. > > Again, thanks for the review! > > Dan > > >> >> >> -Dmitry >> >> >> On 2014-11-11 03:00, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >>> >>> The fix is to detect the version of GNU objcopy that is being >>> used on the machine and only enable Full Debug Symbols when that >>> version is 2.21.1 or newer. If you don't have the right version, >>> then the build drops back to pre-FDS build configs with a message >>> like this: >>> >>> WARNING: /usr/sfw/bin/gobjcopy --version info: >>> WARNING: GNU objcopy 2.15 >>> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >>> .debuginfo files. >>> WARNING: ignoring above objcopy command. >>> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >>> version. >>> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >>> version. >>> WARNING: Solaris 11 Update 1 contains the correct version. >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >>> >>> This work is being tracked by the following bug IDs: >>> >>> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >>> https://bugs.openjdk.java.net/browse/JDK-8033602 >>> >>> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >>> Solaris X86 >>> https://bugs.openjdk.java.net/browse/JDK-8034005 >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >>> >>> Testing: >>> >>> - JPRT test jobs to verify that the current JPRT Solaris hosts >>> are happy >>> - local builds on my Solaris 10 X86 machine to verify that the >>> wrong version of GNU objcopy is caught >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Tue Nov 11 17:25:42 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Nov 2014 10:25:42 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <54623790.4080103@oracle.com> References: <546151A9.1080100@oracle.com> <5461CA5C.30409@oracle.com> <54622DF0.5010800@oracle.com> <54623790.4080103@oracle.com> Message-ID: <54624696.2090201@oracle.com> Thanks for closing the loop on this! Dan On 11/11/14 9:21 AM, Dmitry Samersoff wrote: > Dan, > > Thank you for the explanation. > > The fix looks good for me. > > -Dmitry > > On 2014-11-11 18:40, Daniel D. Daugherty wrote: >> Dmitry, >> >> Thanks for the quick review! >> >> Replies embedded below... >> >> >> On 11/11/14 1:35 AM, Dmitry Samersoff wrote: >>> Dan, >>> >>> 1. defs.make: >>> >>> It might be better to join obcopy version check and condition at ll.190 >> I looked at that... The seemingly natural place to put the version check >> is actually in the else branch on line 194... However, if the version >> check is bad, then you have to make a second check for a reset OBJCOPY >> value (along with indenting all the code another level or two). >> >> It just looked ugly... it seemed better to keep the version check >> separate from the other logic. >> >> >>> otherwise the user will have a wrong version warning and then misleading >>> message "no objcopy cmd found" >> However, part of that wrong version warning is this line: >> >> WARNING: ignoring above objcopy command. >> >> so in reality that "no objcopy cmd found" is just confirming >> that we are indeed ignoring the objcopy cmd that we found... >> >> >>> 2. Did you consider moving objcopy detection to configure? >> No because this fix has to be backported to JDK8u and JDK7 since >> we support FDS in those releases... >> >> Of course, the build-infra team is always welcome to use a new >> bug to evolve this code for JDK9 and newer. >> >> Again, thanks for the review! >> >> Dan >> >> >>> >>> -Dmitry >>> >>> >>> On 2014-11-11 03:00, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>>> Yes, it is a small fix, but it is in Makefiles so feel free to >>>> run screaming from the room... :-) On the plus side the fix does >>>> delete two work around source files (Coleen would say that's a >>>> Good Thing (TM)!) >>>> >>>> The fix is to detect the version of GNU objcopy that is being >>>> used on the machine and only enable Full Debug Symbols when that >>>> version is 2.21.1 or newer. If you don't have the right version, >>>> then the build drops back to pre-FDS build configs with a message >>>> like this: >>>> >>>> WARNING: /usr/sfw/bin/gobjcopy --version info: >>>> WARNING: GNU objcopy 2.15 >>>> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >>>> .debuginfo files. >>>> WARNING: ignoring above objcopy command. >>>> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >>>> version. >>>> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >>>> version. >>>> WARNING: Solaris 11 Update 1 contains the correct version. >>>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >>>> >>>> This work is being tracked by the following bug IDs: >>>> >>>> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >>>> https://bugs.openjdk.java.net/browse/JDK-8033602 >>>> >>>> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >>>> Solaris X86 >>>> https://bugs.openjdk.java.net/browse/JDK-8034005 >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >>>> >>>> Testing: >>>> >>>> - JPRT test jobs to verify that the current JPRT Solaris hosts >>>> are happy >>>> - local builds on my Solaris 10 X86 machine to verify that the >>>> wrong version of GNU objcopy is caught >>>> >>>> Thanks, in advance, for any comments, questions or suggestions. >>>> >>>> Dan > From serguei.spitsyn at oracle.com Tue Nov 11 22:04:29 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Nov 2014 14:04:29 -0800 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <546287ED.9050708@oracle.com> Dan, The fix looks good. Nice cleanup from workarounds: Good Thing (TM)! :) Thanks, Serguei On 11/10/14 4:00 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create > valid .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 > SPARC version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Tue Nov 11 23:31:42 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 11 Nov 2014 16:31:42 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546287ED.9050708@oracle.com> References: <546151A9.1080100@oracle.com> <546287ED.9050708@oracle.com> Message-ID: <54629C5E.8080305@oracle.com> Thanks for the review! On 11/11/14 3:04 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > The fix looks good. Thanks! > Nice cleanup from workarounds: Good Thing (TM)! :) Yes, this has been in the queue for quite a while... :-) Dan > > Thanks, > Serguei > > On 11/10/14 4:00 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create >> valid .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 >> SPARC version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From evgeniya.stepanova at oracle.com Wed Nov 12 15:21:25 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Wed, 12 Nov 2014 19:21:25 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <545CAE30.9010708@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> Message-ID: <54637AF5.9080600@oracle.com> Hi everyone! Since the decision was made to change only tests which fail because of conflict for now (skip "selfish" tests), I post new webrev for jdk part of the JDK-8019361 : http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ Thanks, Evgeniya Stepanova On 07.11.2014 15:34, Evgeniya Stepanova wrote: > David, Filipp, Katja > > Diff have been updated one more time: > java/lang/management/RuntimeMXBean/TestInputArgument.sh and > test/java/lang/ref/EnqueuePollRace.java have been changed > http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ > > Thanks > > On 07.11.2014 9:37, David Holmes wrote: >> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>> New webrev: >>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >> >> In: >> >> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >> >> the use of the gc options seems incidental - it's just picking two >> innocuous options to use - similar to the JpsHelper case. You could >> replace +UseParallelGC with something like +UseFastJNIAccessors >> (platform independent and normally true). >> >> David >> ----- >> >>> Thanks, >>> Evgeniya Stepanova >>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>> Thanks a lot! >>>> >>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>> Hi Katja, >>>>> >>>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>>> diff accordingly. >>>>> >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>> Hi Dima, >>>>>> >>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>> Hi Katja, >>>>>>> >>>>>>> You are right, there will be no conflict, because test ignores any >>>>>>> external VM flags. >>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>> >>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>> >>>>>> This particular case is to test the defined flags are shown up as >>>>>> expected. >>>>>> >>>>>> Evgeniya, >>>>>> >>>>>> would you mind to change JpsHelper.java instead? >>>>>> >>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>> @@ -93,7 +93,7 @@ >>>>>> /** >>>>>> * VM arguments to start test application with >>>>>> */ >>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>> "-XX:+UseParallelGC"}; >>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>> "-XX:+PrintGCDetails"}; >>>>>> /** >>>>>> * VM flag to start test application with >>>>>> */ >>>>>> >>>>>> Best regards, >>>>>> Katja >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> @requires will allow to modify tests to include external vm >>>>>>> options without any risk of bumping into conflict and extend area >>>>>>> of test applicability. >>>>>>> >>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>> not a problem, tests could be kept as is. >>>>>>> >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>>>> >>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>> >>>>>>>> Hi Evgeniya, >>>>>>>> >>>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>> should not be any conflicts either since these tests are running >>>>>>>> in driver mode: >>>>>>>> >>>>>>>> ... >>>>>>>> * @run driver TestJpsJar >>>>>>>> ... >>>>>>>> >>>>>>>> which means no flags from above are accepted. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Katja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> tag added because tests contain string >>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>> >>>>>>>>> and JpsHelper defines >>>>>>>>> ... >>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>> ... >>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>> if (testVmArgs == null) { >>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>> } >>>>>>>>> return testVmArgs; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>> cleanup-if we use for example SerialGC we must be sure that tests >>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Evgeniya Stepanova >>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>> Hi Evgeniya, >>>>>>>>>> >>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>>>>> JDK-8019361 >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>>>>>> is set >>>>>>>>>>> outside >>>>>>>>>> >>>>>>>>>> I don't see why you have done this for the >>>>>>>>>> >>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>> >>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>> >>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>> skip test >>>>>>>>>>> if there is a conflict >>>>>>>>>> >>>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>>> was skipped; or does it only appear in the higher-level jtreg >>>>>>>>>> log? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >>>>>>>>>>> without >>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>> failed >>>>>>>>>>> because of the conflict. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>> >>>>>>>>>>> // >>>>>>>>> >>>>>>>>> -- >>>>>>>>> /Evgeniya Stepanova/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>>> >>> >>> -- >>> /Evgeniya Stepanova/ > > -- > /Evgeniya Stepanova/ -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed Nov 12 15:43:14 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 12 Nov 2014 16:43:14 +0100 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <54637AF5.9080600@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> Message-ID: <54638012.3010202@oracle.com> On 2014-11-12 16:21, Evgeniya Stepanova wrote: > Hi everyone! > > Since the decision was made to change only tests which fail because of > conflict for now (skip "selfish" tests), I post new webrev for jdk > part of the JDK-8019361 > : > http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ Thanks for updating the webrev! A couple of comments: MemoryTestAllGC.sh The test is run three times, once with no params, once with ParallelGC and once with CMS. So, I think the @requires should just be vm.gc == "null". Similarly to what was done for PendingAllGC.sh. TestInputArgument.sh The changes here seem unrelated to @requires. EnqueuePollRace.java Can you explain why it is safe to remove -XX:+UseSerialGC for this test? JpsHelper.java Can you explain why it is safe to remvoe -XX:+UseParallelGC for this test? When I use Aurora to check what tests that currently are considered known because of JDK-8019361 I get a pretty long list: http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 Are the tests in webrev.03 the only tests that still fail? Have the others been fixed in other ways? Thanks, Bengt > > Thanks, > Evgeniya Stepanova > On 07.11.2014 15:34, Evgeniya Stepanova wrote: >> David, Filipp, Katja >> >> Diff have been updated one more time: >> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >> test/java/lang/ref/EnqueuePollRace.java have been changed >> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >> >> Thanks >> >> On 07.11.2014 9:37, David Holmes wrote: >>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>> New webrev: >>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>> >>> In: >>> >>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>> >>> the use of the gc options seems incidental - it's just picking two >>> innocuous options to use - similar to the JpsHelper case. You could >>> replace +UseParallelGC with something like +UseFastJNIAccessors >>> (platform independent and normally true). >>> >>> David >>> ----- >>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>> Thanks a lot! >>>>> >>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>> Hi Katja, >>>>>> >>>>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>>>> diff accordingly. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Evgeniya Stepanova >>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>> Hi Dima, >>>>>>> >>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>> Hi Katja, >>>>>>>> >>>>>>>> You are right, there will be no conflict, because test ignores any >>>>>>>> external VM flags. >>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>> >>>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>> >>>>>>> This particular case is to test the defined flags are shown up as >>>>>>> expected. >>>>>>> >>>>>>> Evgeniya, >>>>>>> >>>>>>> would you mind to change JpsHelper.java instead? >>>>>>> >>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>> @@ -93,7 +93,7 @@ >>>>>>> /** >>>>>>> * VM arguments to start test application with >>>>>>> */ >>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>> "-XX:+UseParallelGC"}; >>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>> "-XX:+PrintGCDetails"}; >>>>>>> /** >>>>>>> * VM flag to start test application with >>>>>>> */ >>>>>>> >>>>>>> Best regards, >>>>>>> Katja >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>> options without any risk of bumping into conflict and extend area >>>>>>>> of test applicability. >>>>>>>> >>>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>>> not a problem, tests could be kept as is. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dima >>>>>>>> >>>>>>>> >>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>> >>>>>>>>> Hi Evgeniya, >>>>>>>>> >>>>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>>> should not be any conflicts either since these tests are running >>>>>>>>> in driver mode: >>>>>>>>> >>>>>>>>> ... >>>>>>>>> * @run driver TestJpsJar >>>>>>>>> ... >>>>>>>>> >>>>>>>>> which means no flags from above are accepted. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Katja >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> tag added because tests contain string >>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>> >>>>>>>>>> and JpsHelper defines >>>>>>>>>> ... >>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>> ... >>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>> } >>>>>>>>>> return testVmArgs; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>>>> tests >>>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Evgeniya Stepanova >>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>> >>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of the >>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when another GC >>>>>>>>>>>> is set >>>>>>>>>>>> outside >>>>>>>>>>> >>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>> >>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>> >>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>> >>>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>>> skip test >>>>>>>>>>>> if there is a conflict >>>>>>>>>>> >>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>> jtreg log? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep >>>>>>>>>>>> and >>>>>>>>>>>> without >>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>>> failed >>>>>>>>>>>> because of the conflict. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>> >>>>>>>>>>>> // >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> /Evgeniya Stepanova/ >>>>> >>>> >>>> -- >>>> /Evgeniya Stepanova/ >> >> -- >> /Evgeniya Stepanova/ > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed Nov 12 15:48:24 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 12 Nov 2014 16:48:24 +0100 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <54638012.3010202@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> <54638012.3010202@oracle.com> Message-ID: <54638148.20903@oracle.com> On 2014-11-12 16:43, Bengt Rutisson wrote: > > On 2014-11-12 16:21, Evgeniya Stepanova wrote: >> Hi everyone! >> >> Since the decision was made to change only tests which fail because >> of conflict for now (skip "selfish" tests), I post new webrev for jdk >> part of the JDK-8019361 >> : >> http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ > > Thanks for updating the webrev! > > A couple of comments: > > MemoryTestAllGC.sh > > The test is run three times, once with no params, once with ParallelGC > and once with CMS. So, I think the @requires should just be vm.gc == > "null". Similarly to what was done for PendingAllGC.sh. > > > TestInputArgument.sh > > The changes here seem unrelated to @requires. > > > EnqueuePollRace.java > > Can you explain why it is safe to remove -XX:+UseSerialGC for this test? > > > JpsHelper.java > > Can you explain why it is safe to remvoe -XX:+UseParallelGC for this test? > > > When I use Aurora to check what tests that currently are considered > known because of JDK-8019361 I get a pretty long list: > > http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 > > Are the tests in webrev.03 the only tests that still fail? Have the > others been fixed in other ways? I just saw the update to the other review thread "RFR: 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests". I assume the rest of the failing tests are there. I'll have a look. Bengt > > Thanks, > Bengt > > > >> >> Thanks, >> Evgeniya Stepanova >> On 07.11.2014 15:34, Evgeniya Stepanova wrote: >>> David, Filipp, Katja >>> >>> Diff have been updated one more time: >>> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >>> test/java/lang/ref/EnqueuePollRace.java have been changed >>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>> >>> Thanks >>> >>> On 07.11.2014 9:37, David Holmes wrote: >>>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>>> >>>> In: >>>> >>>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>>> >>>> the use of the gc options seems incidental - it's just picking two >>>> innocuous options to use - similar to the JpsHelper case. You could >>>> replace +UseParallelGC with something like +UseFastJNIAccessors >>>> (platform independent and normally true). >>>> >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>>> Thanks a lot! >>>>>> >>>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>>> Hi Katja, >>>>>>> >>>>>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>>>>> diff accordingly. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>>> Hi Dima, >>>>>>>> >>>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>>> Hi Katja, >>>>>>>>> >>>>>>>>> You are right, there will be no conflict, because test ignores >>>>>>>>> any >>>>>>>>> external VM flags. >>>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>>> >>>>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>>> >>>>>>>> This particular case is to test the defined flags are shown up as >>>>>>>> expected. >>>>>>>> >>>>>>>> Evgeniya, >>>>>>>> >>>>>>>> would you mind to change JpsHelper.java instead? >>>>>>>> >>>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>>> @@ -93,7 +93,7 @@ >>>>>>>> /** >>>>>>>> * VM arguments to start test application with >>>>>>>> */ >>>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>> "-XX:+PrintGCDetails"}; >>>>>>>> /** >>>>>>>> * VM flag to start test application with >>>>>>>> */ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Katja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>>> options without any risk of bumping into conflict and extend area >>>>>>>>> of test applicability. >>>>>>>>> >>>>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>>>> not a problem, tests could be kept as is. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dima >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>>> >>>>>>>>>> Hi Evgeniya, >>>>>>>>>> >>>>>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>>>> should not be any conflicts either since these tests are running >>>>>>>>>> in driver mode: >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> * @run driver TestJpsJar >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> which means no flags from above are accepted. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Katja >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> tag added because tests contain string >>>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>>> >>>>>>>>>>> and JpsHelper defines >>>>>>>>>>> ... >>>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>> ... >>>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>>> } >>>>>>>>>>> return testVmArgs; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>>>>> tests >>>>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>> >>>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of >>>>>>>>>>>>> the >>>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when >>>>>>>>>>>>> another GC >>>>>>>>>>>>> is set >>>>>>>>>>>>> outside >>>>>>>>>>>> >>>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>>> >>>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>>> >>>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>>> >>>>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>>>> skip test >>>>>>>>>>>>> if there is a conflict >>>>>>>>>>>> >>>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>>> jtreg log? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, >>>>>>>>>>>>> -XX:+UseConcMarkSweep and >>>>>>>>>>>>> without >>>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>>>> failed >>>>>>>>>>>>> because of the conflict. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>> >>>>>>>>>>>>> // >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> /Evgeniya Stepanova/ >>>>>> >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>> >>> -- >>> /Evgeniya Stepanova/ >> >> -- >> /Evgeniya Stepanova/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Wed Nov 12 16:07:23 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Wed, 12 Nov 2014 20:07:23 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <54638012.3010202@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> <54638012.3010202@oracle.com> Message-ID: <546385BB.3080801@oracle.com> Hi Bengt, Please see comments inline On 12.11.2014 19:43, Bengt Rutisson wrote: > > On 2014-11-12 16:21, Evgeniya Stepanova wrote: >> Hi everyone! >> >> Since the decision was made to change only tests which fail because >> of conflict for now (skip "selfish" tests), I post new webrev for jdk >> part of the JDK-8019361 >> : >> http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ > > Thanks for updating the webrev! > > A couple of comments: > > MemoryTestAllGC.sh > > The test is run three times, once with no params, once with ParallelGC > and once with CMS. So, I think the @requires should just be vm.gc == > "null". Similarly to what was done for PendingAllGC.sh. > The third run (with CMS) is commented. Without this run UseParallelGC is valid option #runOne -XX:+UseConcMarkSweepGC MemoryTest 3 (http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html) > > TestInputArgument.sh > > The changes here seem unrelated to @requires. > This test was changed after conversation with David Holmes (see thread below) > > EnqueuePollRace.java > > Can you explain why it is safe to remove -XX:+UseSerialGC for this test? > > This test was modified after conversation with Filipp Zhinkin and Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723) > JpsHelper.java > > Can you explain why it is safe to remvoe -XX:+UseParallelGC for this test? > This test was changed after conversation with Katja Kantserova (see thread below), GC flag is just an arbitrary chosen test flag > > When I use Aurora to check what tests that currently are considered > known because of JDK-8019361 I get a pretty long list: > > http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 > > Are the tests in webrev.03 the only tests that still fail? Have the > others been fixed in other ways? There would be 2 more changes in reviews in closed part :) Thanks, Evgeniya Stepanova > > Thanks, > Bengt > > > >> >> Thanks, >> Evgeniya Stepanova >> On 07.11.2014 15:34, Evgeniya Stepanova wrote: >>> David, Filipp, Katja >>> >>> Diff have been updated one more time: >>> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >>> test/java/lang/ref/EnqueuePollRace.java have been changed >>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>> >>> Thanks >>> >>> On 07.11.2014 9:37, David Holmes wrote: >>>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>>> >>>> In: >>>> >>>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>>> >>>> the use of the gc options seems incidental - it's just picking two >>>> innocuous options to use - similar to the JpsHelper case. You could >>>> replace +UseParallelGC with something like +UseFastJNIAccessors >>>> (platform independent and normally true). >>>> >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>>> Thanks a lot! >>>>>> >>>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>>> Hi Katja, >>>>>>> >>>>>>> Ok, this seems to be a perfect solution. Thank you. I'll change the >>>>>>> diff accordingly. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>>> Hi Dima, >>>>>>>> >>>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>>> Hi Katja, >>>>>>>>> >>>>>>>>> You are right, there will be no conflict, because test ignores >>>>>>>>> any >>>>>>>>> external VM flags. >>>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>>> >>>>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>>> >>>>>>>> This particular case is to test the defined flags are shown up as >>>>>>>> expected. >>>>>>>> >>>>>>>> Evgeniya, >>>>>>>> >>>>>>>> would you mind to change JpsHelper.java instead? >>>>>>>> >>>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>>> @@ -93,7 +93,7 @@ >>>>>>>> /** >>>>>>>> * VM arguments to start test application with >>>>>>>> */ >>>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>> "-XX:+PrintGCDetails"}; >>>>>>>> /** >>>>>>>> * VM flag to start test application with >>>>>>>> */ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Katja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>>> options without any risk of bumping into conflict and extend area >>>>>>>>> of test applicability. >>>>>>>>> >>>>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>>>> not a problem, tests could be kept as is. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dima >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>>> >>>>>>>>>> Hi Evgeniya, >>>>>>>>>> >>>>>>>>>> As David has pointed out these jps tests are not testing gc. The >>>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>>>> should not be any conflicts either since these tests are running >>>>>>>>>> in driver mode: >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> * @run driver TestJpsJar >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> which means no flags from above are accepted. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Katja >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> tag added because tests contain string >>>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>>> >>>>>>>>>>> and JpsHelper defines >>>>>>>>>>> ... >>>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>> ... >>>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>>> } >>>>>>>>>>> return testVmArgs; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>>>>> tests >>>>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice in TC >>>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>> >>>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part of >>>>>>>>>>>>> the >>>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when >>>>>>>>>>>>> another GC >>>>>>>>>>>>> is set >>>>>>>>>>>>> outside >>>>>>>>>>>> >>>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>>> >>>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>>> >>>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>>> >>>>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>>>> skip test >>>>>>>>>>>>> if there is a conflict >>>>>>>>>>>> >>>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file showing it >>>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>>> jtreg log? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, >>>>>>>>>>>>> -XX:+UseConcMarkSweep and >>>>>>>>>>>>> without >>>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>>>> failed >>>>>>>>>>>>> because of the conflict. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>> >>>>>>>>>>>>> // >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> /Evgeniya Stepanova/ >>>>>> >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>> >>> -- >>> /Evgeniya Stepanova/ >> >> -- >> /Evgeniya Stepanova/ > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Wed Nov 12 16:49:41 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Wed, 12 Nov 2014 20:49:41 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <546385BB.3080801@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> <54638012.3010202@oracle.com> <546385BB.3080801@oracle.com> Message-ID: <54638FA5.5000505@oracle.com> Forgotten copyrights were changed http://cr.openjdk.java.net/~eistepan/8062536/webrev.04/ On 12.11.2014 20:07, Evgeniya Stepanova wrote: > Hi Bengt, > > Please see comments inline > On 12.11.2014 19:43, Bengt Rutisson wrote: >> >> On 2014-11-12 16:21, Evgeniya Stepanova wrote: >>> Hi everyone! >>> >>> Since the decision was made to change only tests which fail because >>> of conflict for now (skip "selfish" tests), I post new webrev for >>> jdk part of the JDK-8019361 >>> : >>> http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ >> >> Thanks for updating the webrev! >> >> A couple of comments: >> >> MemoryTestAllGC.sh >> >> The test is run three times, once with no params, once with >> ParallelGC and once with CMS. So, I think the @requires should just >> be vm.gc == "null". Similarly to what was done for PendingAllGC.sh. >> > The third run (with CMS) is commented. Without this run UseParallelGC > is valid option > #runOne -XX:+UseConcMarkSweepGC MemoryTest 3 > (http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html) >> >> TestInputArgument.sh >> >> The changes here seem unrelated to @requires. >> > This test was changed after conversation with David Holmes (see > thread below) >> >> EnqueuePollRace.java >> >> Can you explain why it is safe to remove -XX:+UseSerialGC for this test? >> >> > This test was modified after conversation with Filipp Zhinkin and > Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723) >> JpsHelper.java >> >> Can you explain why it is safe to remvoe -XX:+UseParallelGC for this >> test? >> > This test was changed after conversation with Katja Kantserova (see > thread below), GC flag is just an arbitrary chosen test flag >> >> When I use Aurora to check what tests that currently are considered >> known because of JDK-8019361 I get a pretty long list: >> >> http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 >> >> Are the tests in webrev.03 the only tests that still fail? Have the >> others been fixed in other ways? > There would be 2 more changes in reviews in closed part :) > > Thanks, > Evgeniya Stepanova >> >> Thanks, >> Bengt >> >> >> >>> >>> Thanks, >>> Evgeniya Stepanova >>> On 07.11.2014 15:34, Evgeniya Stepanova wrote: >>>> David, Filipp, Katja >>>> >>>> Diff have been updated one more time: >>>> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >>>> test/java/lang/ref/EnqueuePollRace.java have been changed >>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>>> >>>> Thanks >>>> >>>> On 07.11.2014 9:37, David Holmes wrote: >>>>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>>>> >>>>> In: >>>>> >>>>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>>>> >>>>> the use of the gc options seems incidental - it's just picking two >>>>> innocuous options to use - similar to the JpsHelper case. You >>>>> could replace +UseParallelGC with something like >>>>> +UseFastJNIAccessors (platform independent and normally true). >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> Evgeniya Stepanova >>>>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>>>> Thanks a lot! >>>>>>> >>>>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>>>> Hi Katja, >>>>>>>> >>>>>>>> Ok, this seems to be a perfect solution. Thank you. I'll change >>>>>>>> the >>>>>>>> diff accordingly. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>>>> Hi Dima, >>>>>>>>> >>>>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>>>> Hi Katja, >>>>>>>>>> >>>>>>>>>> You are right, there will be no conflict, because test >>>>>>>>>> ignores any >>>>>>>>>> external VM flags. >>>>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>>>> >>>>>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>>>> >>>>>>>>> This particular case is to test the defined flags are shown up as >>>>>>>>> expected. >>>>>>>>> >>>>>>>>> Evgeniya, >>>>>>>>> >>>>>>>>> would you mind to change JpsHelper.java instead? >>>>>>>>> >>>>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>>>> @@ -93,7 +93,7 @@ >>>>>>>>> /** >>>>>>>>> * VM arguments to start test application with >>>>>>>>> */ >>>>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>> "-XX:+PrintGCDetails"}; >>>>>>>>> /** >>>>>>>>> * VM flag to start test application with >>>>>>>>> */ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Katja >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>>>> options without any risk of bumping into conflict and extend >>>>>>>>>> area >>>>>>>>>> of test applicability. >>>>>>>>>> >>>>>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>>>>> not a problem, tests could be kept as is. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dima >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>> >>>>>>>>>>> As David has pointed out these jps tests are not testing gc. >>>>>>>>>>> The >>>>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>>>>> should not be any conflicts either since these tests are >>>>>>>>>>> running >>>>>>>>>>> in driver mode: >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> * @run driver TestJpsJar >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> which means no flags from above are accepted. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Katja >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> tag added because tests contain string >>>>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>>>> >>>>>>>>>>>> and JpsHelper defines >>>>>>>>>>>> ... >>>>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>>> ... >>>>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>>>> } >>>>>>>>>>>> return testVmArgs; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>>>>>> tests >>>>>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice >>>>>>>>>>>> in TC >>>>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when >>>>>>>>>>>>>> another GC >>>>>>>>>>>>>> is set >>>>>>>>>>>>>> outside >>>>>>>>>>>>> >>>>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>>>> >>>>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>>>> >>>>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>>>>> skip test >>>>>>>>>>>>>> if there is a conflict >>>>>>>>>>>>> >>>>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file >>>>>>>>>>>>> showing it >>>>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>>>> jtreg log? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, >>>>>>>>>>>>>> -XX:+UseConcMarkSweep and >>>>>>>>>>>>>> without >>>>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>>>>> failed >>>>>>>>>>>>>> because of the conflict. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>>> >>>>>>>>>>>>>> // >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> /Evgeniya Stepanova/ >>>>>>> >>>>>> >>>>>> -- >>>>>> /Evgeniya Stepanova/ >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >>> -- >>> /Evgeniya Stepanova/ >> > > -- > /Evgeniya Stepanova/ -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.lagneau at oracle.com Wed Nov 12 18:19:11 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Wed, 12 Nov 2014 19:19:11 +0100 Subject: RFR(XS): JDK-8062037 java/lang/instrument/RetransformBigClass.sh should be quarantined Message-ID: <5463A49F.7030404@oracle.com> Please review this addition to ProblemList.txt Issue: https://bugs.openjdk.java.net/browse/JDK-8062037 Initial Failure: https://bugs.openjdk.java.net/browse/JDK-8061177 Webrev: http://cr.openjdk.java.net/~olagneau/8062037/webrev.00/ Retransform/RedefineBigClass.sh have been showing again random failure(s) with crash and 134 exitcode. These are stress tests and showed they need a safe and not overloaded running context to avoid random errors. They should be moved to a stress suite. Quarantining them is a first step to such move. When further moving them to some stress suite they should also be refactored (back) using memory leak detection through OOM (rather than delta measurement on free memory) , and tuned to the expected running context. Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Nov 12 18:22:56 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Nov 2014 11:22:56 -0700 Subject: RFR(XS): JDK-8062037 java/lang/instrument/RetransformBigClass.sh should be quarantined In-Reply-To: <5463A49F.7030404@oracle.com> References: <5463A49F.7030404@oracle.com> Message-ID: <5463A580.2040302@oracle.com> Thumbs up on the quarantine. However, I think the bug reference in ProblemList.txt should be 8061177 and not the bug used to do the quarantine. Dan On 11/12/14 11:19 AM, olivier.lagneau at oracle.com wrote: > Please review this addition to ProblemList.txt > > Issue: https://bugs.openjdk.java.net/browse/JDK-8062037 > Initial Failure: https://bugs.openjdk.java.net/browse/JDK-8061177 > Webrev: http://cr.openjdk.java.net/~olagneau/8062037/webrev.00/ > > Retransform/RedefineBigClass.sh have been showing again random > failure(s) with crash and 134 exitcode. > These are stress tests and showed they need a safe and not overloaded > running context to avoid random > errors. They should be moved to a stress suite. Quarantining them is a > first step to such move. > > When further moving them to some stress suite they should also be > refactored (back) using memory leak > detection through OOM (rather than delta measurement on free memory) , > and tuned to the expected running > context. > > Thanks, > Olivier. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Nov 12 20:44:45 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Nov 2014 12:44:45 -0800 Subject: RFR(XS): JDK-8062037 java/lang/instrument/RetransformBigClass.sh should be quarantined In-Reply-To: <5463A580.2040302@oracle.com> References: <5463A49F.7030404@oracle.com> <5463A580.2040302@oracle.com> Message-ID: <5463C6BD.4090703@oracle.com> +1 Thanks, Serguei On 11/12/14 10:22 AM, Daniel D. Daugherty wrote: > Thumbs up on the quarantine. > > However, I think the bug reference in ProblemList.txt should be > 8061177 and not the bug used to do the quarantine. > > Dan > > > On 11/12/14 11:19 AM, olivier.lagneau at oracle.com wrote: >> Please review this addition to ProblemList.txt >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8062037 >> Initial Failure: https://bugs.openjdk.java.net/browse/JDK-8061177 >> Webrev: http://cr.openjdk.java.net/~olagneau/8062037/webrev.00/ >> >> Retransform/RedefineBigClass.sh have been showing again random >> failure(s) with crash and 134 exitcode. >> These are stress tests and showed they need a safe and not overloaded >> running context to avoid random >> errors. They should be moved to a stress suite. Quarantining them is >> a first step to such move. >> >> When further moving them to some stress suite they should also be >> refactored (back) using memory leak >> detection through OOM (rather than delta measurement on free memory) >> , and tuned to the expected running >> context. >> >> Thanks, >> Olivier. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Nov 13 00:43:55 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 12 Nov 2014 16:43:55 -0800 (PST) Subject: JEP 228: Add More Diagnostic Commands Message-ID: <20141113004355.3A354420A4@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/228 - Mark From david.holmes at oracle.com Thu Nov 13 02:43:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Nov 2014 12:43:42 +1000 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <5463B896.10801@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> Message-ID: <54641ADE.8030504@oracle.com> Hi Chris, Sorry for the delay. On 13/11/2014 5:44 AM, Chris Plummer wrote: > Hi, > > I'm still looking for reviewers. As the change is to the launcher it needs to be reviewed by the launcher owner - which I think is serviceability (though also cc'd Kumar :) ). Launcher change, and your rationale, seems okay to me. I'd probably put the test in to jdk/test/tools/launcher/ though. Thanks, David > thanks, > > Chris > > On 11/7/14 7:53 PM, Chris Plummer wrote: >> This is an initial review for 6762191. I'm guessing there will be >> recommendations to fix in a different way, but thought this would be a >> good time to start the discussion. >> >> https://bugs.openjdk.java.net/browse/JDK-6762191 >> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >> >> The bug is that if the -Xss size is set to something very small (like >> 16k), on linux there will be a crash due to overwriting the end of the >> stack. This happens before hotspot can compute its stack needs and >> verify that the stack is big enough. >> >> It didn't seem viable to move the hotspot stack size check earlier. It >> depends on too much other work done before that point, and the changes >> would have been disruptive. The stack size check is currently done in >> os::init_2(). >> >> What is needed is a check before the thread is created. That way we >> can create a thread with a big enough stack to handle all needs up to >> the point of the check in os::init_2(). This initial check does not >> need to be the final check. It just needs to confirm that we have >> enough stack to get us to the check in os::init_2(). >> >> I decided to check in java.c if the -Xss size is too small, and set it >> to a larger size if it is. I hard coded this size to 32k (I'll explain >> why 32k later). I suspect this is the part that will result in some >> debate. If you have better suggestions let me know. If it does stay >> here, then probably the 32k needs to be a #define, and maybe even an >> OS porting interface, but I'm not sure where to put it. >> >> The reason I chose 32k is because this is big enough for all platforms >> to get to the stack size check in os::init_2(). It is also smaller >> than the actual minimum stack size allowed on any platform. 32-bit >> windows has the smallest requirement at 64k. I add some printfs to >> print the minimum stack requirement, and then ran a simple JTReg test >> with every JPRT supported platform to get the results. >> >> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >> -Xss32k, and -XXss, where is the size from the >> error message produced by the JVM, such as in the following: >> >> $ java -Xss32k -version >> The stack size specified is too small, Specify at least 100k >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> I ran this test through JPRT on all platforms, and they all pass. >> >> One thing to point out is that Windows behaves a bit different than >> the other platforms. It always rounds the stack size up to a multiple >> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >> 32-bit Windows with C1, 64k is also the minimum requirement, so there >> is no error produced in this case. However, on 32-bit Windows with C2, >> 68k is the minimum, so an error is produced since the stack will only >> be 64k. There is no bug here. It's just a bit confusing. >> >> thanks, >> >> Chris > From david.holmes at oracle.com Thu Nov 13 03:10:34 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Nov 2014 13:10:34 +1000 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <5464212A.6070504@oracle.com> Hi Dan, If you still need a Reviewer, looks okay to me. Thanks, David On 11/11/2014 10:00 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create valid > .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC > version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Thu Nov 13 03:54:31 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Nov 2014 20:54:31 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464212A.6070504@oracle.com> References: <546151A9.1080100@oracle.com> <5464212A.6070504@oracle.com> Message-ID: <54642B77.3030607@oracle.com> Thanks! I was still in need of a (R)eviewer and a Runtime team member so thanks for covering both... Dan On 11/12/14 8:10 PM, David Holmes wrote: > Hi Dan, > > If you still need a Reviewer, looks okay to me. > > Thanks, > David > > On 11/11/2014 10:00 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create valid >> .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC >> version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From bengt.rutisson at oracle.com Thu Nov 13 09:44:02 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Nov 2014 10:44:02 +0100 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <546385BB.3080801@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> <54638012.3010202@oracle.com> <546385BB.3080801@oracle.com> Message-ID: <54647D62.5050202@oracle.com> Hi Evgeniya, On 2014-11-12 17:07, Evgeniya Stepanova wrote: > Hi Bengt, > > Please see comments inline > On 12.11.2014 19:43, Bengt Rutisson wrote: >> >> On 2014-11-12 16:21, Evgeniya Stepanova wrote: >>> Hi everyone! >>> >>> Since the decision was made to change only tests which fail because >>> of conflict for now (skip "selfish" tests), I post new webrev for >>> jdk part of the JDK-8019361 >>> : >>> http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ >> >> Thanks for updating the webrev! >> >> A couple of comments: >> >> MemoryTestAllGC.sh >> >> The test is run three times, once with no params, once with >> ParallelGC and once with CMS. So, I think the @requires should just >> be vm.gc == "null". Similarly to what was done for PendingAllGC.sh. >> > The third run (with CMS) is commented. Without this run UseParallelGC > is valid option > #runOne -XX:+UseConcMarkSweepGC MemoryTest 3 > (http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html) Right. I missed that it was commented out. Thanks for pointing that out. I went back and checked. That line was already commented out when the test was first added in 2001. Do you mind removing the CMS line to avoid more people doing the same mistake that I did? I don't think we need to keep a commented out test around for more than 13 years... ;) >> >> TestInputArgument.sh >> >> The changes here seem unrelated to @requires. >> > This test was changed after conversation with David Holmes (see > thread below) Ok. Good. >> >> EnqueuePollRace.java >> >> Can you explain why it is safe to remove -XX:+UseSerialGC for this test? >> >> > This test was modified after conversation with Filipp Zhinkin and > Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723) Ok. >> JpsHelper.java >> >> Can you explain why it is safe to remvoe -XX:+UseParallelGC for this >> test? >> > This test was changed after conversation with Katja Kantserova (see > thread below), GC flag is just an arbitrary chosen test flag Ok. I should clearly have read the other reviews more. In that case I guess the changes look good from my perspective. Thanks, Bengt >> >> When I use Aurora to check what tests that currently are considered >> known because of JDK-8019361 I get a pretty long list: >> >> http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 >> >> Are the tests in webrev.03 the only tests that still fail? Have the >> others been fixed in other ways? > There would be 2 more changes in reviews in closed part :) > > Thanks, > Evgeniya Stepanova >> >> Thanks, >> Bengt >> >> >> >>> >>> Thanks, >>> Evgeniya Stepanova >>> On 07.11.2014 15:34, Evgeniya Stepanova wrote: >>>> David, Filipp, Katja >>>> >>>> Diff have been updated one more time: >>>> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >>>> test/java/lang/ref/EnqueuePollRace.java have been changed >>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>>> >>>> Thanks >>>> >>>> On 07.11.2014 9:37, David Holmes wrote: >>>>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>>>> >>>>> In: >>>>> >>>>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>>>> >>>>> the use of the gc options seems incidental - it's just picking two >>>>> innocuous options to use - similar to the JpsHelper case. You >>>>> could replace +UseParallelGC with something like >>>>> +UseFastJNIAccessors (platform independent and normally true). >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> Evgeniya Stepanova >>>>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>>>> Thanks a lot! >>>>>>> >>>>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>>>> Hi Katja, >>>>>>>> >>>>>>>> Ok, this seems to be a perfect solution. Thank you. I'll change >>>>>>>> the >>>>>>>> diff accordingly. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>>>> Hi Dima, >>>>>>>>> >>>>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>>>> Hi Katja, >>>>>>>>>> >>>>>>>>>> You are right, there will be no conflict, because test >>>>>>>>>> ignores any >>>>>>>>>> external VM flags. >>>>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>>>> >>>>>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>>>> >>>>>>>>> This particular case is to test the defined flags are shown up as >>>>>>>>> expected. >>>>>>>>> >>>>>>>>> Evgeniya, >>>>>>>>> >>>>>>>>> would you mind to change JpsHelper.java instead? >>>>>>>>> >>>>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>>>> @@ -93,7 +93,7 @@ >>>>>>>>> /** >>>>>>>>> * VM arguments to start test application with >>>>>>>>> */ >>>>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>> "-XX:+PrintGCDetails"}; >>>>>>>>> /** >>>>>>>>> * VM flag to start test application with >>>>>>>>> */ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Katja >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>>>> options without any risk of bumping into conflict and extend >>>>>>>>>> area >>>>>>>>>> of test applicability. >>>>>>>>>> >>>>>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>>>>> not a problem, tests could be kept as is. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dima >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>> >>>>>>>>>>> As David has pointed out these jps tests are not testing gc. >>>>>>>>>>> The >>>>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>>>>> should not be any conflicts either since these tests are >>>>>>>>>>> running >>>>>>>>>>> in driver mode: >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> * @run driver TestJpsJar >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> which means no flags from above are accepted. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Katja >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> tag added because tests contain string >>>>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>>>> >>>>>>>>>>>> and JpsHelper defines >>>>>>>>>>>> ... >>>>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>>> ... >>>>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>>>> } >>>>>>>>>>>> return testVmArgs; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>>>>>> tests >>>>>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice >>>>>>>>>>>> in TC >>>>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when >>>>>>>>>>>>>> another GC >>>>>>>>>>>>>> is set >>>>>>>>>>>>>> outside >>>>>>>>>>>>> >>>>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>>>> >>>>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>>>> >>>>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>>>>> skip test >>>>>>>>>>>>>> if there is a conflict >>>>>>>>>>>>> >>>>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file >>>>>>>>>>>>> showing it >>>>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>>>> jtreg log? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, >>>>>>>>>>>>>> -XX:+UseConcMarkSweep and >>>>>>>>>>>>>> without >>>>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>>>>> failed >>>>>>>>>>>>>> because of the conflict. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>>> >>>>>>>>>>>>>> // >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> /Evgeniya Stepanova/ >>>>>>> >>>>>> >>>>>> -- >>>>>> /Evgeniya Stepanova/ >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >>> -- >>> /Evgeniya Stepanova/ >> > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Thu Nov 13 10:00:48 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Thu, 13 Nov 2014 14:00:48 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <54647D62.5050202@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> <54638012.3010202@oracle.com> <546385BB.3080801@oracle.com> <54647D62.5050202@oracle.com> Message-ID: <54648150.8070607@oracle.com> Hi Bengt! Ok, I'll remove this string. Thank you for reviewing it one more time :) Evgeniya Stepanova On 13.11.2014 13:44, Bengt Rutisson wrote: > > Hi Evgeniya, > > On 2014-11-12 17:07, Evgeniya Stepanova wrote: >> Hi Bengt, >> >> Please see comments inline >> On 12.11.2014 19:43, Bengt Rutisson wrote: >>> >>> On 2014-11-12 16:21, Evgeniya Stepanova wrote: >>>> Hi everyone! >>>> >>>> Since the decision was made to change only tests which fail because >>>> of conflict for now (skip "selfish" tests), I post new webrev for >>>> jdk part of the JDK-8019361 >>>> : >>>> http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ >>> >>> Thanks for updating the webrev! >>> >>> A couple of comments: >>> >>> MemoryTestAllGC.sh >>> >>> The test is run three times, once with no params, once with >>> ParallelGC and once with CMS. So, I think the @requires should just >>> be vm.gc == "null". Similarly to what was done for PendingAllGC.sh. >>> >> The third run (with CMS) is commented. Without this run UseParallelGC >> is valid option >> #runOne -XX:+UseConcMarkSweepGC MemoryTest 3 >> (http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html) > > Right. I missed that it was commented out. Thanks for pointing that out. > > I went back and checked. That line was already commented out when the > test was first added in 2001. Do you mind removing the CMS line to > avoid more people doing the same mistake that I did? I don't think we > need to keep a commented out test around for more than 13 years... ;) > >>> >>> TestInputArgument.sh >>> >>> The changes here seem unrelated to @requires. >>> >> This test was changed after conversation with David Holmes (see >> thread below) > > Ok. Good. > >>> >>> EnqueuePollRace.java >>> >>> Can you explain why it is safe to remove -XX:+UseSerialGC for this test? >>> >>> >> This test was modified after conversation with Filipp Zhinkin and >> Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723) > > Ok. > >>> JpsHelper.java >>> >>> Can you explain why it is safe to remvoe -XX:+UseParallelGC for this >>> test? >>> >> This test was changed after conversation with Katja Kantserova (see >> thread below), GC flag is just an arbitrary chosen test flag > > Ok. > > I should clearly have read the other reviews more. > > In that case I guess the changes look good from my perspective. > > Thanks, > Bengt > >>> >>> When I use Aurora to check what tests that currently are considered >>> known because of JDK-8019361 I get a pretty long list: >>> >>> http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 >>> >>> Are the tests in webrev.03 the only tests that still fail? Have the >>> others been fixed in other ways? >> There would be 2 more changes in reviews in closed part :) >> >> Thanks, >> Evgeniya Stepanova >>> >>> Thanks, >>> Bengt >>> >>> >>> >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> On 07.11.2014 15:34, Evgeniya Stepanova wrote: >>>>> David, Filipp, Katja >>>>> >>>>> Diff have been updated one more time: >>>>> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >>>>> test/java/lang/ref/EnqueuePollRace.java have been changed >>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>>>> >>>>> Thanks >>>>> >>>>> On 07.11.2014 9:37, David Holmes wrote: >>>>>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>>>>> >>>>>> In: >>>>>> >>>>>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>>>>> >>>>>> the use of the gc options seems incidental - it's just picking >>>>>> two innocuous options to use - similar to the JpsHelper case. You >>>>>> could replace +UseParallelGC with something like >>>>>> +UseFastJNIAccessors (platform independent and normally true). >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>>>>> Thanks a lot! >>>>>>>> >>>>>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>>>>> Hi Katja, >>>>>>>>> >>>>>>>>> Ok, this seems to be a perfect solution. Thank you. I'll >>>>>>>>> change the >>>>>>>>> diff accordingly. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Evgeniya Stepanova >>>>>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>>>>> Hi Dima, >>>>>>>>>> >>>>>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>>>>> Hi Katja, >>>>>>>>>>> >>>>>>>>>>> You are right, there will be no conflict, because test >>>>>>>>>>> ignores any >>>>>>>>>>> external VM flags. >>>>>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>>>>> >>>>>>>>>>> Ignoring external options is bad thing, such "selfish" tests >>>>>>>>>>> are >>>>>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>>>>> >>>>>>>>>> This particular case is to test the defined flags are shown >>>>>>>>>> up as >>>>>>>>>> expected. >>>>>>>>>> >>>>>>>>>> Evgeniya, >>>>>>>>>> >>>>>>>>>> would you mind to change JpsHelper.java instead? >>>>>>>>>> >>>>>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>>>>> @@ -93,7 +93,7 @@ >>>>>>>>>> /** >>>>>>>>>> * VM arguments to start test application with >>>>>>>>>> */ >>>>>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>> "-XX:+PrintGCDetails"}; >>>>>>>>>> /** >>>>>>>>>> * VM flag to start test application with >>>>>>>>>> */ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Katja >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>>>>> options without any risk of bumping into conflict and extend >>>>>>>>>>> area >>>>>>>>>>> of test applicability. >>>>>>>>>>> >>>>>>>>>>> But if you still believe, that @requires is not necessary - >>>>>>>>>>> it's >>>>>>>>>>> not a problem, tests could be kept as is. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dima >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>> >>>>>>>>>>>> As David has pointed out these jps tests are not testing >>>>>>>>>>>> gc. The >>>>>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. >>>>>>>>>>>> There >>>>>>>>>>>> should not be any conflicts either since these tests are >>>>>>>>>>>> running >>>>>>>>>>>> in driver mode: >>>>>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> * @run driver TestJpsJar >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> which means no flags from above are accepted. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Katja >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> tag added because tests contain string >>>>>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>>>>> >>>>>>>>>>>>> and JpsHelper defines >>>>>>>>>>>>> ... >>>>>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>>>> ... >>>>>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>>>>> } >>>>>>>>>>>>> return testVmArgs; >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added >>>>>>>>>>>>> for >>>>>>>>>>>>> cleanup-if we use for example SerialGC we must be sure >>>>>>>>>>>>> that tests >>>>>>>>>>>>> passed with this GC, not with another one. Now you will >>>>>>>>>>>>> assume >>>>>>>>>>>>> that concrete test passed with Serial GC, but it run only >>>>>>>>>>>>> with >>>>>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice >>>>>>>>>>>>> in TC >>>>>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part >>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>>>>> fix: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when >>>>>>>>>>>>>>> another GC >>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>> outside >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>>>>> >>>>>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Solution: Such tests marked with the jtreg tag >>>>>>>>>>>>>>> "requires" to >>>>>>>>>>>>>>> skip test >>>>>>>>>>>>>>> if there is a conflict >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file >>>>>>>>>>>>>> showing it >>>>>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>>>>> jtreg log? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, >>>>>>>>>>>>>>> -XX:+UseConcMarkSweep and >>>>>>>>>>>>>>> without >>>>>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No >>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>> failed >>>>>>>>>>>>>>> because of the conflict. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> /Evgeniya Stepanova/ >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> /Evgeniya Stepanova/ >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >> >> -- >> /Evgeniya Stepanova/ > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.auno at oracle.com Thu Nov 13 13:56:04 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Thu, 13 Nov 2014 14:56:04 +0100 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job Message-ID: <5464B874.4060206@oracle.com> Hi, Could I please get a review of this addition of SVC tests to JPRT submit jobs. So far, I'm only adding JDI tests as those are the only ones I have completed code coverage analysis on to determine the best subset to add. The other areas will be added too, but I'm adding these now to get the ball rolling asap. I've run these through JPRT once already without failures and have got two more runs in the pipe. I've also looked through the history for these tests and found that they do not have any known instabilities to worry about. Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ Thanks, Mikael From magnus.ihse.bursie at oracle.com Thu Nov 13 14:44:54 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Nov 2014 15:44:54 +0100 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <546151A9.1080100@oracle.com> References: <546151A9.1080100@oracle.com> Message-ID: <5464C3E6.5000309@oracle.com> On 2014-11-11 01:00, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) ... but you're only deleting the make files? src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c could be deleted as well, right? Good idea for the fix, anyway. I opened https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a similar solution in configure. /Magnus From mikael.auno at oracle.com Thu Nov 13 15:53:22 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Thu, 13 Nov 2014 16:53:22 +0100 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5464B874.4060206@oracle.com> References: <5464B874.4060206@oracle.com> Message-ID: <5464D3F2.9060107@oracle.com> On 2014-11-13 14:56, Mikael Auno wrote: > Hi, > > Could I please get a review of this addition of SVC tests to JPRT submit > jobs. So far, I'm only adding JDI tests as those are the only ones I > have completed code coverage analysis on to determine the best subset to > add. The other areas will be added too, but I'm adding these now to get > the ball rolling asap. > > I've run these through JPRT once already without failures and have got > two more runs in the pipe. I've also looked through the history for > these tests and found that they do not have any known instabilities to > worry about. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 > Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ The additional JPRT runs have completed now and have no failures. Here are also the duration (in seconds) for each test on each platform to in case anyone wonders ("com/sun/jdi" prefix stripped out): > ----------------------------------------------------------------------------------------------------------------------------------------------------------------- > | | lin_i586-c1 | lin_i586-c2 | lin_x64-c2 | osx_x64-c2 | sol_sparcv9-c2 | sol_x64-c2 | win_i586-c1 | win_i586-c2 | win_x64-c2 | > ----------------------------------------------------------------------------------------------------------------------------------------------------------------- > | .../AcceptTimeout | 1.24 | 1.277 | 1.308 | 1.349 | 1.54 | 1.204 | 2.184 | 2.293 | 2.34 | > | .../AccessSpecifierTest | 1.689 | 1.883 | 2.021 | 2.303 | 4.892 | 2.048 | 1.332 | 1.707 | 2.19 | > | .../AfterThreadDeathTest | 0.855 | 0.748 | 0.815 | 0.605 | 1.098 | 0.691 | 0.299 | 0.424 | 1.683 | > | .../ArrayRangeTest | 0.659 | 0.823 | 0.794 | 0.702 | 1.445 | 0.837 | 0.783 | 0.503 | 1.267 | > | .../ConstantPoolInfo | 0.589 | 0.74 | 0.791 | 0.621 | 1.067 | 0.607 | 0.315 | 0.408 | 0.674 | > | .../CountFilterTest | 0.588 | 0.638 | 0.729 | 0.617 | 1.068 | 0.618 | 0.3 | 0.502 | 0.674 | > | .../EarlyReturnNegativeTest | 0.724 | 0.8 | 0.824 | 0.675 | 1.186 | 0.642 | 0.362 | 0.627 | 0.736 | > | .../EarlyReturnTest | 1.218 | 1.164 | 1.295 | 1.207 | 1.962 | 1.307 | 0.72 | 1.189 | 1.242 | > | .../FieldWatchpoints | 0.616 | 0.628 | 0.728 | 0.6 | 1.052 | 0.683 | 0.3 | 0.408 | 0.674 | > | .../FramesTest | 0.598 | 0.696 | 0.741 | 0.601 | 1.006 | 0.592 | 0.299 | 0.425 | 0.627 | > | .../InstanceFilter | 0.604 | 0.677 | 0.696 | 0.587 | 1.005 | 0.608 | 0.284 | 0.393 | 0.69 | > | .../InterfaceMethodsTest | 0.706 | 0.83 | 0.837 | 0.69 | 1.193 | 0.762 | 0.362 | 1.032 | 0.752 | > | .../InvokeTest | 0.719 | 0.788 | 0.861 | 0.71 | 1.196 | 0.647 | 0.377 | 0.752 | 0.721 | > | .../LocalVariableEqual | 0.66 | 0.662 | 0.714 | 0.622 | 1.087 | 0.715 | 0.315 | 0.383 | 0.612 | > | .../LocationTest | 0.639 | 0.651 | 0.688 | 0.715 | 1.014 | 0.612 | 0.299 | 0.362 | 0.58 | > | .../ModificationWatchpoints | 0.764 | 0.789 | 0.872 | 0.726 | 1.375 | 0.668 | 0.424 | 0.502 | 0.877 | > | .../MonitorEventTest | 0.597 | 0.638 | 0.69 | 1.608 | 1.03 | 0.648 | 0.284 | 0.377 | 0.689 | > | .../MonitorFrameInfo | 0.622 | 0.652 | 0.731 | 0.596 | 1.014 | 0.592 | 0.299 | 0.456 | 0.612 | > | .../NullThreadGroupNameTest | 0.602 | 0.702 | 0.733 | 0.588 | 1.045 | 0.572 | 0.299 | 0.362 | 0.58 | > | .../PopAndStepTest | 0.318 | 0.351 | 0.416 | 0.593 | 0.989 | 0.713 | 0.3 | 0.455 | 0.752 | > | .../PopAsynchronousTest | 0.718 | 0.869 | 0.8 | 0.654 | 1.063 | 0.619 | 0.519 | 0.581 | 0.737 | > | .../ProcessAttachTest | 6.748 | 6.482 | 6.781 | 7.115 | 9.167 | 6.973 | 6.043 | 6.355 | 6.881 | > | .../redefineMethod/RedefineTest | 3.678 | 3.743 | 4.072 | 5.207 | 7.081 | 3.757 | 2.976 | 3.568 | 4.723 | > | .../ReferrersTest | 0.846 | 0.811 | 0.866 | 1.493 | 2.295 | 1.096 | 0.642 | 0.892 | 1.31 | > | .../RequestReflectionTest | 0.642 | 0.644 | 0.706 | 0.59 | 1.172 | 0.584 | 0.3 | 0.737 | 0.736 | > | .../ResumeOneThreadTest | 0.612 | 0.661 | 0.688 | 0.669 | 1.073 | 0.583 | 0.502 | 0.362 | 0.658 | > | .../RunToExit | 1.434 | 1.454 | 1.462 | 1.215 | 1.182 | 1.188 | 1.126 | 1.126 | 1.22 | > | .../sde/MangleTest | 0.739 | 0.976 | 0.9 | 0.72 | 1.295 | 0.703 | 0.486 | 0.752 | 1.11 | > | .../sde/TemperatureTableTest | 0.923 | 0.986 | 0.992 | 0.784 | 1.368 | 0.846 | 0.502 | 0.892 | 0.908 | > | .../SourceNameFilterTest | 1.246 | 1.365 | 1.45 | 1.246 | 2.041 | 1.215 | 0.599 | 1.051 | 1.316 | > | .../VarargsTest | 0.713 | 0.763 | 0.814 | 0.718 | 1.183 | 0.654 | 0.393 | 0.533 | 0.924 | > | .../Vars | 0.568 | 0.609 | 0.692 | 0.628 | 1.012 | 0.583 | 0.284 | 0.362 | 0.564 | > ----------------------------------------------------------------------------------------------------------------------------------------------------------------- > | Total | 33.874 | 35.564 | 37.507 | 37.754 | 57.196 | 34.567 | 24.509 | 30.771 | 40.059 | > ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Thanks, Mikael From serguei.spitsyn at oracle.com Thu Nov 13 16:41:21 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 13 Nov 2014 08:41:21 -0800 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5464D3F2.9060107@oracle.com> References: <5464B874.4060206@oracle.com> <5464D3F2.9060107@oracle.com> Message-ID: <5464DF31.3000503@oracle.com> It looks good. Thanks, Serguei On 11/13/14 7:53 AM, Mikael Auno wrote: > On 2014-11-13 14:56, Mikael Auno wrote: >> Hi, >> >> Could I please get a review of this addition of SVC tests to JPRT submit >> jobs. So far, I'm only adding JDI tests as those are the only ones I >> have completed code coverage analysis on to determine the best subset to >> add. The other areas will be added too, but I'm adding these now to get >> the ball rolling asap. >> >> I've run these through JPRT once already without failures and have got >> two more runs in the pipe. I've also looked through the history for >> these tests and found that they do not have any known instabilities to >> worry about. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 >> Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ > The additional JPRT runs have completed now and have no failures. Here > are also the duration (in seconds) for each test on each platform to in > case anyone wonders ("com/sun/jdi" prefix stripped out): > >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | | lin_i586-c1 | lin_i586-c2 | lin_x64-c2 | osx_x64-c2 | sol_sparcv9-c2 | sol_x64-c2 | win_i586-c1 | win_i586-c2 | win_x64-c2 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | .../AcceptTimeout | 1.24 | 1.277 | 1.308 | 1.349 | 1.54 | 1.204 | 2.184 | 2.293 | 2.34 | >> | .../AccessSpecifierTest | 1.689 | 1.883 | 2.021 | 2.303 | 4.892 | 2.048 | 1.332 | 1.707 | 2.19 | >> | .../AfterThreadDeathTest | 0.855 | 0.748 | 0.815 | 0.605 | 1.098 | 0.691 | 0.299 | 0.424 | 1.683 | >> | .../ArrayRangeTest | 0.659 | 0.823 | 0.794 | 0.702 | 1.445 | 0.837 | 0.783 | 0.503 | 1.267 | >> | .../ConstantPoolInfo | 0.589 | 0.74 | 0.791 | 0.621 | 1.067 | 0.607 | 0.315 | 0.408 | 0.674 | >> | .../CountFilterTest | 0.588 | 0.638 | 0.729 | 0.617 | 1.068 | 0.618 | 0.3 | 0.502 | 0.674 | >> | .../EarlyReturnNegativeTest | 0.724 | 0.8 | 0.824 | 0.675 | 1.186 | 0.642 | 0.362 | 0.627 | 0.736 | >> | .../EarlyReturnTest | 1.218 | 1.164 | 1.295 | 1.207 | 1.962 | 1.307 | 0.72 | 1.189 | 1.242 | >> | .../FieldWatchpoints | 0.616 | 0.628 | 0.728 | 0.6 | 1.052 | 0.683 | 0.3 | 0.408 | 0.674 | >> | .../FramesTest | 0.598 | 0.696 | 0.741 | 0.601 | 1.006 | 0.592 | 0.299 | 0.425 | 0.627 | >> | .../InstanceFilter | 0.604 | 0.677 | 0.696 | 0.587 | 1.005 | 0.608 | 0.284 | 0.393 | 0.69 | >> | .../InterfaceMethodsTest | 0.706 | 0.83 | 0.837 | 0.69 | 1.193 | 0.762 | 0.362 | 1.032 | 0.752 | >> | .../InvokeTest | 0.719 | 0.788 | 0.861 | 0.71 | 1.196 | 0.647 | 0.377 | 0.752 | 0.721 | >> | .../LocalVariableEqual | 0.66 | 0.662 | 0.714 | 0.622 | 1.087 | 0.715 | 0.315 | 0.383 | 0.612 | >> | .../LocationTest | 0.639 | 0.651 | 0.688 | 0.715 | 1.014 | 0.612 | 0.299 | 0.362 | 0.58 | >> | .../ModificationWatchpoints | 0.764 | 0.789 | 0.872 | 0.726 | 1.375 | 0.668 | 0.424 | 0.502 | 0.877 | >> | .../MonitorEventTest | 0.597 | 0.638 | 0.69 | 1.608 | 1.03 | 0.648 | 0.284 | 0.377 | 0.689 | >> | .../MonitorFrameInfo | 0.622 | 0.652 | 0.731 | 0.596 | 1.014 | 0.592 | 0.299 | 0.456 | 0.612 | >> | .../NullThreadGroupNameTest | 0.602 | 0.702 | 0.733 | 0.588 | 1.045 | 0.572 | 0.299 | 0.362 | 0.58 | >> | .../PopAndStepTest | 0.318 | 0.351 | 0.416 | 0.593 | 0.989 | 0.713 | 0.3 | 0.455 | 0.752 | >> | .../PopAsynchronousTest | 0.718 | 0.869 | 0.8 | 0.654 | 1.063 | 0.619 | 0.519 | 0.581 | 0.737 | >> | .../ProcessAttachTest | 6.748 | 6.482 | 6.781 | 7.115 | 9.167 | 6.973 | 6.043 | 6.355 | 6.881 | >> | .../redefineMethod/RedefineTest | 3.678 | 3.743 | 4.072 | 5.207 | 7.081 | 3.757 | 2.976 | 3.568 | 4.723 | >> | .../ReferrersTest | 0.846 | 0.811 | 0.866 | 1.493 | 2.295 | 1.096 | 0.642 | 0.892 | 1.31 | >> | .../RequestReflectionTest | 0.642 | 0.644 | 0.706 | 0.59 | 1.172 | 0.584 | 0.3 | 0.737 | 0.736 | >> | .../ResumeOneThreadTest | 0.612 | 0.661 | 0.688 | 0.669 | 1.073 | 0.583 | 0.502 | 0.362 | 0.658 | >> | .../RunToExit | 1.434 | 1.454 | 1.462 | 1.215 | 1.182 | 1.188 | 1.126 | 1.126 | 1.22 | >> | .../sde/MangleTest | 0.739 | 0.976 | 0.9 | 0.72 | 1.295 | 0.703 | 0.486 | 0.752 | 1.11 | >> | .../sde/TemperatureTableTest | 0.923 | 0.986 | 0.992 | 0.784 | 1.368 | 0.846 | 0.502 | 0.892 | 0.908 | >> | .../SourceNameFilterTest | 1.246 | 1.365 | 1.45 | 1.246 | 2.041 | 1.215 | 0.599 | 1.051 | 1.316 | >> | .../VarargsTest | 0.713 | 0.763 | 0.814 | 0.718 | 1.183 | 0.654 | 0.393 | 0.533 | 0.924 | >> | .../Vars | 0.568 | 0.609 | 0.692 | 0.628 | 1.012 | 0.583 | 0.284 | 0.362 | 0.564 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | Total | 33.874 | 35.564 | 37.507 | 37.754 | 57.196 | 34.567 | 24.509 | 30.771 | 40.059 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- > Thanks, > Mikael From olivier.lagneau at oracle.com Thu Nov 13 17:21:53 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Thu, 13 Nov 2014 18:21:53 +0100 Subject: RFR(XS): JDK-8062037 java/lang/instrument/RetransformBigClass.sh should be quarantined In-Reply-To: <5463A580.2040302@oracle.com> References: <5463A49F.7030404@oracle.com> <5463A580.2040302@oracle.com> Message-ID: <5464E8B1.8090801@oracle.com> Thanks Dan and Serguey for the quick reply. I will change 8062037 reference to 8061177 in ProblemList.txt before pushing. Olivier. On 12/11/2014 19:22, Daniel D. Daugherty wrote: > Thumbs up on the quarantine. > > However, I think the bug reference in ProblemList.txt should be > 8061177 and not the bug used to do the quarantine. > > Dan > > > On 11/12/14 11:19 AM, olivier.lagneau at oracle.com wrote: >> Please review this addition to ProblemList.txt >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8062037 >> Initial Failure: https://bugs.openjdk.java.net/browse/JDK-8061177 >> Webrev: http://cr.openjdk.java.net/~olagneau/8062037/webrev.00/ >> >> Retransform/RedefineBigClass.sh have been showing again random >> failure(s) with crash and 134 exitcode. >> These are stress tests and showed they need a safe and not overloaded >> running context to avoid random >> errors. They should be moved to a stress suite. Quarantining them is >> a first step to such move. >> >> When further moving them to some stress suite they should also be >> refactored (back) using memory leak >> detection through OOM (rather than delta measurement on free memory) >> , and tuned to the expected running >> context. >> >> Thanks, >> Olivier. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Nov 13 18:18:40 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Nov 2014 11:18:40 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464C3E6.5000309@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> Message-ID: <5464F600.7040601@oracle.com> Magnus, Thanks for the review! Replies embedded below... On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: > On 2014-11-11 01:00, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) > > ... but you're only deleting the make files? Good catch! Looks like when I resurrected this fix from my JDK8 queue I missed a couple of deletes. > src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and > src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c could > be deleted as well, right? Yes, these should be deleted and I'll do that in this fix. Since these are two deletes of files that can no longer be built anyway, I presume I don't need to sent out another webrev... > > Good idea for the fix, anyway. I opened > https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a > similar solution in configure. Sounds good to me. Dan > > /Magnus From david.holmes at oracle.com Fri Nov 14 02:20:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Nov 2014 12:20:50 +1000 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464F600.7040601@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> Message-ID: <54656702.4090102@oracle.com> On 14/11/2014 4:18 AM, Daniel D. Daugherty wrote: > Magnus, > > Thanks for the review! > > Replies embedded below... > > On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >> >> ... but you're only deleting the make files? > > Good catch! Looks like when I resurrected this fix from my JDK8 > queue I missed a couple of deletes. > > >> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c could >> be deleted as well, right? > > Yes, these should be deleted and I'll do that in this fix. > Since these are two deletes of files that can no longer be > built anyway, I presume I don't need to sent out another > webrev... I don't need to see an updated webrev :) Thanks, David > >> >> Good idea for the fix, anyway. I opened >> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >> similar solution in configure. > > Sounds good to me. > > Dan > > >> >> /Magnus > From david.holmes at oracle.com Fri Nov 14 02:28:08 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Nov 2014 12:28:08 +1000 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5464D3F2.9060107@oracle.com> References: <5464B874.4060206@oracle.com> <5464D3F2.9060107@oracle.com> Message-ID: <546568B8.2050305@oracle.com> Hi Mikael, So to be clear this adds the JDK JDI tests (select subset thereof) to "-testset hotspot" for full forest submissions to JPRT. Test overhead seems okay. Hopefully the test stability will be exhibited in JPRT as well as other testing. Ok. David On 14/11/2014 1:53 AM, Mikael Auno wrote: > On 2014-11-13 14:56, Mikael Auno wrote: >> Hi, >> >> Could I please get a review of this addition of SVC tests to JPRT submit >> jobs. So far, I'm only adding JDI tests as those are the only ones I >> have completed code coverage analysis on to determine the best subset to >> add. The other areas will be added too, but I'm adding these now to get >> the ball rolling asap. >> >> I've run these through JPRT once already without failures and have got >> two more runs in the pipe. I've also looked through the history for >> these tests and found that they do not have any known instabilities to >> worry about. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 >> Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ > > The additional JPRT runs have completed now and have no failures. Here > are also the duration (in seconds) for each test on each platform to in > case anyone wonders ("com/sun/jdi" prefix stripped out): > >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | | lin_i586-c1 | lin_i586-c2 | lin_x64-c2 | osx_x64-c2 | sol_sparcv9-c2 | sol_x64-c2 | win_i586-c1 | win_i586-c2 | win_x64-c2 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | .../AcceptTimeout | 1.24 | 1.277 | 1.308 | 1.349 | 1.54 | 1.204 | 2.184 | 2.293 | 2.34 | >> | .../AccessSpecifierTest | 1.689 | 1.883 | 2.021 | 2.303 | 4.892 | 2.048 | 1.332 | 1.707 | 2.19 | >> | .../AfterThreadDeathTest | 0.855 | 0.748 | 0.815 | 0.605 | 1.098 | 0.691 | 0.299 | 0.424 | 1.683 | >> | .../ArrayRangeTest | 0.659 | 0.823 | 0.794 | 0.702 | 1.445 | 0.837 | 0.783 | 0.503 | 1.267 | >> | .../ConstantPoolInfo | 0.589 | 0.74 | 0.791 | 0.621 | 1.067 | 0.607 | 0.315 | 0.408 | 0.674 | >> | .../CountFilterTest | 0.588 | 0.638 | 0.729 | 0.617 | 1.068 | 0.618 | 0.3 | 0.502 | 0.674 | >> | .../EarlyReturnNegativeTest | 0.724 | 0.8 | 0.824 | 0.675 | 1.186 | 0.642 | 0.362 | 0.627 | 0.736 | >> | .../EarlyReturnTest | 1.218 | 1.164 | 1.295 | 1.207 | 1.962 | 1.307 | 0.72 | 1.189 | 1.242 | >> | .../FieldWatchpoints | 0.616 | 0.628 | 0.728 | 0.6 | 1.052 | 0.683 | 0.3 | 0.408 | 0.674 | >> | .../FramesTest | 0.598 | 0.696 | 0.741 | 0.601 | 1.006 | 0.592 | 0.299 | 0.425 | 0.627 | >> | .../InstanceFilter | 0.604 | 0.677 | 0.696 | 0.587 | 1.005 | 0.608 | 0.284 | 0.393 | 0.69 | >> | .../InterfaceMethodsTest | 0.706 | 0.83 | 0.837 | 0.69 | 1.193 | 0.762 | 0.362 | 1.032 | 0.752 | >> | .../InvokeTest | 0.719 | 0.788 | 0.861 | 0.71 | 1.196 | 0.647 | 0.377 | 0.752 | 0.721 | >> | .../LocalVariableEqual | 0.66 | 0.662 | 0.714 | 0.622 | 1.087 | 0.715 | 0.315 | 0.383 | 0.612 | >> | .../LocationTest | 0.639 | 0.651 | 0.688 | 0.715 | 1.014 | 0.612 | 0.299 | 0.362 | 0.58 | >> | .../ModificationWatchpoints | 0.764 | 0.789 | 0.872 | 0.726 | 1.375 | 0.668 | 0.424 | 0.502 | 0.877 | >> | .../MonitorEventTest | 0.597 | 0.638 | 0.69 | 1.608 | 1.03 | 0.648 | 0.284 | 0.377 | 0.689 | >> | .../MonitorFrameInfo | 0.622 | 0.652 | 0.731 | 0.596 | 1.014 | 0.592 | 0.299 | 0.456 | 0.612 | >> | .../NullThreadGroupNameTest | 0.602 | 0.702 | 0.733 | 0.588 | 1.045 | 0.572 | 0.299 | 0.362 | 0.58 | >> | .../PopAndStepTest | 0.318 | 0.351 | 0.416 | 0.593 | 0.989 | 0.713 | 0.3 | 0.455 | 0.752 | >> | .../PopAsynchronousTest | 0.718 | 0.869 | 0.8 | 0.654 | 1.063 | 0.619 | 0.519 | 0.581 | 0.737 | >> | .../ProcessAttachTest | 6.748 | 6.482 | 6.781 | 7.115 | 9.167 | 6.973 | 6.043 | 6.355 | 6.881 | >> | .../redefineMethod/RedefineTest | 3.678 | 3.743 | 4.072 | 5.207 | 7.081 | 3.757 | 2.976 | 3.568 | 4.723 | >> | .../ReferrersTest | 0.846 | 0.811 | 0.866 | 1.493 | 2.295 | 1.096 | 0.642 | 0.892 | 1.31 | >> | .../RequestReflectionTest | 0.642 | 0.644 | 0.706 | 0.59 | 1.172 | 0.584 | 0.3 | 0.737 | 0.736 | >> | .../ResumeOneThreadTest | 0.612 | 0.661 | 0.688 | 0.669 | 1.073 | 0.583 | 0.502 | 0.362 | 0.658 | >> | .../RunToExit | 1.434 | 1.454 | 1.462 | 1.215 | 1.182 | 1.188 | 1.126 | 1.126 | 1.22 | >> | .../sde/MangleTest | 0.739 | 0.976 | 0.9 | 0.72 | 1.295 | 0.703 | 0.486 | 0.752 | 1.11 | >> | .../sde/TemperatureTableTest | 0.923 | 0.986 | 0.992 | 0.784 | 1.368 | 0.846 | 0.502 | 0.892 | 0.908 | >> | .../SourceNameFilterTest | 1.246 | 1.365 | 1.45 | 1.246 | 2.041 | 1.215 | 0.599 | 1.051 | 1.316 | >> | .../VarargsTest | 0.713 | 0.763 | 0.814 | 0.718 | 1.183 | 0.654 | 0.393 | 0.533 | 0.924 | >> | .../Vars | 0.568 | 0.609 | 0.692 | 0.628 | 1.012 | 0.583 | 0.284 | 0.362 | 0.564 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | Total | 33.874 | 35.564 | 37.507 | 37.754 | 57.196 | 34.567 | 24.509 | 30.771 | 40.059 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Thanks, > Mikael > From staffan.larsen at oracle.com Fri Nov 14 07:51:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 14 Nov 2014 08:51:50 +0100 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5464D3F2.9060107@oracle.com> References: <5464B874.4060206@oracle.com> <5464D3F2.9060107@oracle.com> Message-ID: <1B9130A1-DC34-4562-8E1C-CF59E41010E2@oracle.com> Looks good! Thanks, /Staffan > On 13 nov 2014, at 16:53, Mikael Auno wrote: > > On 2014-11-13 14:56, Mikael Auno wrote: >> Hi, >> >> Could I please get a review of this addition of SVC tests to JPRT submit >> jobs. So far, I'm only adding JDI tests as those are the only ones I >> have completed code coverage analysis on to determine the best subset to >> add. The other areas will be added too, but I'm adding these now to get >> the ball rolling asap. >> >> I've run these through JPRT once already without failures and have got >> two more runs in the pipe. I've also looked through the history for >> these tests and found that they do not have any known instabilities to >> worry about. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 >> Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ > > The additional JPRT runs have completed now and have no failures. Here > are also the duration (in seconds) for each test on each platform to in > case anyone wonders ("com/sun/jdi" prefix stripped out): > >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | | lin_i586-c1 | lin_i586-c2 | lin_x64-c2 | osx_x64-c2 | sol_sparcv9-c2 | sol_x64-c2 | win_i586-c1 | win_i586-c2 | win_x64-c2 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | .../AcceptTimeout | 1.24 | 1.277 | 1.308 | 1.349 | 1.54 | 1.204 | 2.184 | 2.293 | 2.34 | >> | .../AccessSpecifierTest | 1.689 | 1.883 | 2.021 | 2.303 | 4.892 | 2.048 | 1.332 | 1.707 | 2.19 | >> | .../AfterThreadDeathTest | 0.855 | 0.748 | 0.815 | 0.605 | 1.098 | 0.691 | 0.299 | 0.424 | 1.683 | >> | .../ArrayRangeTest | 0.659 | 0.823 | 0.794 | 0.702 | 1.445 | 0.837 | 0.783 | 0.503 | 1.267 | >> | .../ConstantPoolInfo | 0.589 | 0.74 | 0.791 | 0.621 | 1.067 | 0.607 | 0.315 | 0.408 | 0.674 | >> | .../CountFilterTest | 0.588 | 0.638 | 0.729 | 0.617 | 1.068 | 0.618 | 0.3 | 0.502 | 0.674 | >> | .../EarlyReturnNegativeTest | 0.724 | 0.8 | 0.824 | 0.675 | 1.186 | 0.642 | 0.362 | 0.627 | 0.736 | >> | .../EarlyReturnTest | 1.218 | 1.164 | 1.295 | 1.207 | 1.962 | 1.307 | 0.72 | 1.189 | 1.242 | >> | .../FieldWatchpoints | 0.616 | 0.628 | 0.728 | 0.6 | 1.052 | 0.683 | 0.3 | 0.408 | 0.674 | >> | .../FramesTest | 0.598 | 0.696 | 0.741 | 0.601 | 1.006 | 0.592 | 0.299 | 0.425 | 0.627 | >> | .../InstanceFilter | 0.604 | 0.677 | 0.696 | 0.587 | 1.005 | 0.608 | 0.284 | 0.393 | 0.69 | >> | .../InterfaceMethodsTest | 0.706 | 0.83 | 0.837 | 0.69 | 1.193 | 0.762 | 0.362 | 1.032 | 0.752 | >> | .../InvokeTest | 0.719 | 0.788 | 0.861 | 0.71 | 1.196 | 0.647 | 0.377 | 0.752 | 0.721 | >> | .../LocalVariableEqual | 0.66 | 0.662 | 0.714 | 0.622 | 1.087 | 0.715 | 0.315 | 0.383 | 0.612 | >> | .../LocationTest | 0.639 | 0.651 | 0.688 | 0.715 | 1.014 | 0.612 | 0.299 | 0.362 | 0.58 | >> | .../ModificationWatchpoints | 0.764 | 0.789 | 0.872 | 0.726 | 1.375 | 0.668 | 0.424 | 0.502 | 0.877 | >> | .../MonitorEventTest | 0.597 | 0.638 | 0.69 | 1.608 | 1.03 | 0.648 | 0.284 | 0.377 | 0.689 | >> | .../MonitorFrameInfo | 0.622 | 0.652 | 0.731 | 0.596 | 1.014 | 0.592 | 0.299 | 0.456 | 0.612 | >> | .../NullThreadGroupNameTest | 0.602 | 0.702 | 0.733 | 0.588 | 1.045 | 0.572 | 0.299 | 0.362 | 0.58 | >> | .../PopAndStepTest | 0.318 | 0.351 | 0.416 | 0.593 | 0.989 | 0.713 | 0.3 | 0.455 | 0.752 | >> | .../PopAsynchronousTest | 0.718 | 0.869 | 0.8 | 0.654 | 1.063 | 0.619 | 0.519 | 0.581 | 0.737 | >> | .../ProcessAttachTest | 6.748 | 6.482 | 6.781 | 7.115 | 9.167 | 6.973 | 6.043 | 6.355 | 6.881 | >> | .../redefineMethod/RedefineTest | 3.678 | 3.743 | 4.072 | 5.207 | 7.081 | 3.757 | 2.976 | 3.568 | 4.723 | >> | .../ReferrersTest | 0.846 | 0.811 | 0.866 | 1.493 | 2.295 | 1.096 | 0.642 | 0.892 | 1.31 | >> | .../RequestReflectionTest | 0.642 | 0.644 | 0.706 | 0.59 | 1.172 | 0.584 | 0.3 | 0.737 | 0.736 | >> | .../ResumeOneThreadTest | 0.612 | 0.661 | 0.688 | 0.669 | 1.073 | 0.583 | 0.502 | 0.362 | 0.658 | >> | .../RunToExit | 1.434 | 1.454 | 1.462 | 1.215 | 1.182 | 1.188 | 1.126 | 1.126 | 1.22 | >> | .../sde/MangleTest | 0.739 | 0.976 | 0.9 | 0.72 | 1.295 | 0.703 | 0.486 | 0.752 | 1.11 | >> | .../sde/TemperatureTableTest | 0.923 | 0.986 | 0.992 | 0.784 | 1.368 | 0.846 | 0.502 | 0.892 | 0.908 | >> | .../SourceNameFilterTest | 1.246 | 1.365 | 1.45 | 1.246 | 2.041 | 1.215 | 0.599 | 1.051 | 1.316 | >> | .../VarargsTest | 0.713 | 0.763 | 0.814 | 0.718 | 1.183 | 0.654 | 0.393 | 0.533 | 0.924 | >> | .../Vars | 0.568 | 0.609 | 0.692 | 0.628 | 1.012 | 0.583 | 0.284 | 0.362 | 0.564 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- >> | Total | 33.874 | 35.564 | 37.507 | 37.754 | 57.196 | 34.567 | 24.509 | 30.771 | 40.059 | >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Thanks, > Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Nov 14 08:03:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Nov 2014 08:03:38 +0000 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5464B874.4060206@oracle.com> References: <5464B874.4060206@oracle.com> Message-ID: <5465B75A.5080609@oracle.com> On 13/11/2014 13:56, Mikael Auno wrote: > Hi, > > Could I please get a review of this addition of SVC tests to JPRT submit > jobs. So far, I'm only adding JDI tests as those are the only ones I > have completed code coverage analysis on to determine the best subset to > add. The other areas will be added too, but I'm adding these now to get > the ball rolling asap. > > I've run these through JPRT once already without failures and have got > two more runs in the pipe. I've also looked through the history for > these tests and found that they do not have any known instabilities to > worry about. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 > Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ > > This doesn't look very maintainable. If we are adding *_sanity groups then would be better to move them to their own section of the file so that they are in the middle of the main grouping of the tests? Also I think we should avoid list individual tests if we can, would it be better to leave out JDI until your analysis is completed? -Alan From staffan.larsen at oracle.com Fri Nov 14 08:40:27 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 14 Nov 2014 09:40:27 +0100 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5465B75A.5080609@oracle.com> References: <5464B874.4060206@oracle.com> <5465B75A.5080609@oracle.com> Message-ID: <6D4C1371-535D-4EA6-BE39-4B08AE9AB039@oracle.com> > On 14 nov 2014, at 09:03, Alan Bateman wrote: > > On 13/11/2014 13:56, Mikael Auno wrote: >> Hi, >> >> Could I please get a review of this addition of SVC tests to JPRT submit >> jobs. So far, I'm only adding JDI tests as those are the only ones I >> have completed code coverage analysis on to determine the best subset to >> add. The other areas will be added too, but I'm adding these now to get >> the ball rolling asap. >> >> I've run these through JPRT once already without failures and have got >> two more runs in the pipe. I've also looked through the history for >> these tests and found that they do not have any known instabilities to >> worry about. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 >> Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ >> >> > This doesn't look very maintainable. If we are adding *_sanity groups then would be better to move them to their own section of the file so that they are in the middle of the main grouping of the tests? Also I think we should avoid list individual tests if we can, would it be better to leave out JDI until your analysis is completed? So the goal here has been to increase the test coverage of hotspot jprt push jobs, but with a limited impact on execution time. This is all to make sure hotspot changes do no break serviceability features. While it would be great to run all tests at all times, we don?t have time for that. Mikael has been doing code coverage analysis to find the subset of test that provides the biggest bang for the buck. Starting with JDI is as good as any place to start. I agree that listing individual tests is not particularly appealing, but I don?t see many other options. We could possibly use @key tags to select the tests but there isn?t much support in makefiles and jprt for that if I recall. We could use sub-folders, but that quickly gets out of hand. We could move the _sanity lists to one place in the file to make it easier to see the rest. /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.auno at oracle.com Fri Nov 14 08:47:49 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 14 Nov 2014 09:47:49 +0100 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <546568B8.2050305@oracle.com> References: <5464B874.4060206@oracle.com> <5464D3F2.9060107@oracle.com> <546568B8.2050305@oracle.com> Message-ID: <5465C1B5.3080109@oracle.com> On 2014-11-14 03:28, David Holmes wrote: > So to be clear this adds the JDK JDI tests (select subset thereof) to > "-testset hotspot" for full forest submissions to JPRT. Yes, that is precisely the idea; adding SVC tests to hotspot JPRT pushes so that development in other teams does not break SVC features. This has already been done by compiler and runtime in the same way too, although their test groups are in hotspot/test instead of jdk/test. Mikael From Alan.Bateman at oracle.com Fri Nov 14 08:53:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Nov 2014 08:53:43 +0000 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <6D4C1371-535D-4EA6-BE39-4B08AE9AB039@oracle.com> References: <5464B874.4060206@oracle.com> <5465B75A.5080609@oracle.com> <6D4C1371-535D-4EA6-BE39-4B08AE9AB039@oracle.com> Message-ID: <5465C317.2060201@oracle.com> On 14/11/2014 08:40, Staffan Larsen wrote: > : > > So the goal here has been to increase the test coverage of hotspot > jprt push jobs, but with a limited impact on execution time. This is > all to make sure hotspot changes do no break serviceability features. > While it would be great to run all tests at all times, we don?t have > time for that. Mikael has been doing code coverage analysis to find > the subset of test that provides the biggest bang for the buck. > Starting with JDI is as good as any place to start. > > I agree that listing individual tests is not particularly appealing, > but I don?t see many other options. We could possibly use @key tags to > select the tests but there isn?t much support in makefiles and jprt > for that if I recall. We could use sub-folders, but that quickly gets > out of hand. > > We could move the _sanity lists to one place in the file to make it > easier to see the rest. > My main concern is keeping the test group hierarchy easy to understand and maintain. It has to be easy to identify any tests that aren't run by any of the top-level groups for example. For serviceability then the original idea was to have the jdk_svc group that ran all of the tests, this in turn consisted of 5 sub-groups to cover the various areas. This sub-groups will execute concurrently on different JPRT clients and works reasonably well, albeit with some imbalance in the execution time. The "real" definitions of the groups end just after the section with the comment "Client area groups" so if you can move the new sanity groups down to below that with a good comment to explain what they are then it should okay. At some point we need to look at removing completely the "Profile based ..." groups at the end. They are completely unmaintainable and there are much better ways of doing this now (with @requires). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.auno at oracle.com Fri Nov 14 09:32:16 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 14 Nov 2014 10:32:16 +0100 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5465C317.2060201@oracle.com> References: <5464B874.4060206@oracle.com> <5465B75A.5080609@oracle.com> <6D4C1371-535D-4EA6-BE39-4B08AE9AB039@oracle.com> <5465C317.2060201@oracle.com> Message-ID: <5465CC20.40802@oracle.com> On 2014-11-14 09:53, Alan Bateman wrote: > On 14/11/2014 08:40, Staffan Larsen wrote: >> : >> >> So the goal here has been to increase the test coverage of hotspot >> jprt push jobs, but with a limited impact on execution time. This is >> all to make sure hotspot changes do no break serviceability features. >> While it would be great to run all tests at all times, we don?t have >> time for that. Mikael has been doing code coverage analysis to find >> the subset of test that provides the biggest bang for the buck. >> Starting with JDI is as good as any place to start. >> >> I agree that listing individual tests is not particularly appealing, >> but I don?t see many other options. We could possibly use @key tags to >> select the tests but there isn?t much support in makefiles and jprt >> for that if I recall. We could use sub-folders, but that quickly gets >> out of hand. >> >> We could move the _sanity lists to one place in the file to make it >> easier to see the rest. >> > > My main concern is keeping the test group hierarchy easy to understand > and maintain. It has to be easy to identify any tests that aren't run by > any of the top-level groups for example. For serviceability then the > original idea was to have the jdk_svc group that ran all of the tests, > this in turn consisted of 5 sub-groups to cover the various areas. This > sub-groups will execute concurrently on different JPRT clients and works > reasonably well, albeit with some imbalance in the execution time. > > The "real" definitions of the groups end just after the section with the > comment "Client area groups" so if you can move the new sanity groups > down to below that with a good comment to explain what they are then it > should okay. > > At some point we need to look at removing completely the "Profile based > ..." groups at the end. They are completely unmaintainable and there are > much better ways of doing this now (with @requires). Here's an updated webrev with your proposed changes. http://cr.openjdk.java.net/~miauno/8064799/webrev.01/ Mikael From mattias.tobiasson at oracle.com Fri Nov 14 09:38:47 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Fri, 14 Nov 2014 01:38:47 -0800 (PST) Subject: PIT failures in jmap: Unable to deduce type of thread Message-ID: Hi, Many tmtools/jmap and tmtools/jstack tests fails in PIT. Below is a typical stack trace. My guess is that this is the same thing as last week about serviceability not recognizing a new compiler thread. https://bugs.openjdk.java.net/browse/JDK-8062735 Tests only fails on Mac. Does anyone know what the problem is? Thanks, Mattias java.lang.RuntimeException: Unable to deduce type of thread from address 0x00007f93e419c800 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, SurrogateLockerThread, or CodeCacheSweeperThread) at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:167) at sun.jvm.hotspot.runtime.Threads.first(Threads.java:151) at sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) at sun.tools.jstack.JStack.main(JStack.java:106) Caused by: sun.jvm.hotspot.debugger.UnmappedAddressException: 7f93e419c800 at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) at sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readCInteger(BsdDebuggerLocal.java:513) at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) at sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readAddress(BsdDebuggerLocal.java:448) at sun.jvm.hotspot.debugger.bsd.BsdAddress.getAddressAt(BsdAddress.java:74) at sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:52) at sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:163) From mattias.tobiasson at oracle.com Fri Nov 14 09:43:35 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Fri, 14 Nov 2014 01:43:35 -0800 (PST) Subject: PIT failures in jmap: Unable to deduce type of thread Message-ID: Or maybe the PIT was just started before the fix for JDK-8062735 was in? Pit started on november 7, and bug was closed on november 6. It should be in, but mayvbe it was not? Mattias ----- Original Message ----- From: mattias.tobiasson at oracle.com To: serviceability-dev at openjdk.java.net Cc: dmitry.fazunenko at oracle.com, albert.noll at oracle.com Sent: Friday, November 14, 2014 10:39:07 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: PIT failures in jmap: Unable to deduce type of thread Hi, Many tmtools/jmap and tmtools/jstack tests fails in PIT. Below is a typical stack trace. My guess is that this is the same thing as last week about serviceability not recognizing a new compiler thread. https://bugs.openjdk.java.net/browse/JDK-8062735 Tests only fails on Mac. Does anyone know what the problem is? Thanks, Mattias java.lang.RuntimeException: Unable to deduce type of thread from address 0x00007f93e419c800 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, SurrogateLockerThread, or CodeCacheSweeperThread) at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:167) at sun.jvm.hotspot.runtime.Threads.first(Threads.java:151) at sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) at sun.tools.jstack.JStack.main(JStack.java:106) Caused by: sun.jvm.hotspot.debugger.UnmappedAddressException: 7f93e419c800 at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) at sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readCInteger(BsdDebuggerLocal.java:513) at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) at sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readAddress(BsdDebuggerLocal.java:448) at sun.jvm.hotspot.debugger.bsd.BsdAddress.getAddressAt(BsdAddress.java:74) at sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:52) at sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:163) From Alan.Bateman at oracle.com Fri Nov 14 09:55:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Nov 2014 09:55:40 +0000 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5465CC20.40802@oracle.com> References: <5464B874.4060206@oracle.com> <5465B75A.5080609@oracle.com> <6D4C1371-535D-4EA6-BE39-4B08AE9AB039@oracle.com> <5465C317.2060201@oracle.com> <5465CC20.40802@oracle.com> Message-ID: <5465D19C.3040609@oracle.com> On 14/11/2014 09:32, Mikael Auno wrote: > : > Here's an updated webrev with your proposed changes. > > http://cr.openjdk.java.net/~miauno/8064799/webrev.01/ > This looks to okay, thanks for taking the concern on board. -Alan From mikael.auno at oracle.com Fri Nov 14 11:58:23 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 14 Nov 2014 12:58:23 +0100 Subject: RFR: 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job In-Reply-To: <5465D19C.3040609@oracle.com> References: <5464B874.4060206@oracle.com> <5465B75A.5080609@oracle.com> <6D4C1371-535D-4EA6-BE39-4B08AE9AB039@oracle.com> <5465C317.2060201@oracle.com> <5465CC20.40802@oracle.com> <5465D19C.3040609@oracle.com> Message-ID: <5465EE5F.7060902@oracle.com> On 2014-11-14 10:55, Alan Bateman wrote: > On 14/11/2014 09:32, Mikael Auno wrote: >> : >> Here's an updated webrev with your proposed changes. >> >> http://cr.openjdk.java.net/~miauno/8064799/webrev.01/ >> > This looks to okay, thanks for taking the concern on board. > > -Alan Perfect. Thanks for the reviews, all of you. Mikael From ivan.gerasimov at oracle.com Fri Nov 14 12:35:29 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Nov 2014 15:35:29 +0300 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 Message-ID: <5465F711.9090605@oracle.com> Hello! The recent fix for JDK-8059533 ((process) Make exiting process wait for exiting threads [win]) caused the warning message to be printed in some test environments: ----------- os_windows.cpp:3844 is in the newly updated os::win32::exit_process_or_thread(Ept what, int exit_code) ----------- This has been observed with debug builds on highly loaded systems. To address the issue it is proposed to do three things: 1) increase the timeout for debug builds, 2) increase the maximum number of the thread handles to be stored, 3) rise the priority of the exiting threads, if we need to wait for them. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ The fix was tested on all available platforms, with the hotspot testset. No failures. Sincerely yours, Ivan From jaroslav.bachorik at oracle.com Fri Nov 14 13:10:25 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 14 Nov 2014 14:10:25 +0100 Subject: RFR(XS): 8048050: Agent NullPointerException when rmi.port in use In-Reply-To: <5465FE9D.5060003@oracle.com> References: <5465FE9D.5060003@oracle.com> Message-ID: <5465FF41.2050507@oracle.com> Good to go. -JB- On 11/14/2014 02:07 PM, Sergey Gabdurakhmanov wrote: > Hi, > > Could I please have a review of this small fix. > > webrev: http://cr.openjdk.java.net/~sgabdura/8048050/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048050 > > Problem description: > If the com.sun.management.jmxremote.rmi.port option is provided it will > give a NPE if already in use by a different JVM. Its expected to fail > but should provide an appropriate exception. > > STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : > Run two instances in different JVMs at same time with the following > options: > -Dcom.sun.management.jmxremote.port=2222 > -Dcom.sun.management.jmxremote.rmi.port=2223 > -Dcom.sun.management.jmxremote.authenticate=false > > Root cause: > Then we trying to start JMXConnectorServer (see method exportMBeanServer > of class sun.management.jmxremote.ConnectorBootstrap on already used > port it cause IOException. Call of connServer.getAddress().toString() in > the exception handler cause NullPointerException because > connServer.getAddress() returns null. > > Solution: > Provide url.toString() if connServer.getAddress() is null > > I'm going to push this fix into JDK9, 8 and 7. > > BR, > Sergey > From daniel.fuchs at oracle.com Fri Nov 14 13:32:26 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Nov 2014 14:32:26 +0100 Subject: RFR(XS): 8048050: Agent NullPointerException when rmi.port in use In-Reply-To: <5465FF41.2050507@oracle.com> References: <5465FE9D.5060003@oracle.com> <5465FF41.2050507@oracle.com> Message-ID: <5466046A.2060309@oracle.com> Hi Sergey, The fix looks fine. I wonder whether there should be a testcase for that? best regards, -- daniel On 14/11/14 14:10, Jaroslav Bachorik wrote: > > Good to go. > > -JB- > > On 11/14/2014 02:07 PM, Sergey Gabdurakhmanov wrote: >> Hi, >> >> Could I please have a review of this small fix. >> >> webrev: http://cr.openjdk.java.net/~sgabdura/8048050/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8048050 >> >> Problem description: >> If the com.sun.management.jmxremote.rmi.port option is provided it will >> give a NPE if already in use by a different JVM. Its expected to fail >> but should provide an appropriate exception. >> >> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : >> Run two instances in different JVMs at same time with the following >> options: >> -Dcom.sun.management.jmxremote.port=2222 >> -Dcom.sun.management.jmxremote.rmi.port=2223 >> -Dcom.sun.management.jmxremote.authenticate=false >> >> Root cause: >> Then we trying to start JMXConnectorServer (see method exportMBeanServer >> of class sun.management.jmxremote.ConnectorBootstrap on already used >> port it cause IOException. Call of connServer.getAddress().toString() in >> the exception handler cause NullPointerException because >> connServer.getAddress() returns null. >> >> Solution: >> Provide url.toString() if connServer.getAddress() is null >> >> I'm going to push this fix into JDK9, 8 and 7. >> >> BR, >> Sergey >> > From thomas.stuefe at gmail.com Fri Nov 14 14:06:11 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 14 Nov 2014 15:06:11 +0100 Subject: Why is instrument.dll linked against static CRT on windows? Message-ID: Hi everyone, we have a problem in our instrument.dll - on windows - which is caused by the fact that it links against the static CRT instead of the dynamic CRT. The problem is probably uninteresting and has to do with the fact that we run then with two C-Runtimes; there are a number of ways to fix it, but an easy way would be to just link instrument.cll against the dynamic C-Runtime. I see that in Lib-java.instrument.gmk there is a special section for instrument.dll: 46 # Statically link the C runtime so that there are not dependencies on modules 47 # not on the search patch when invoked from the Windows system directory 48 # (or elsewhere). 49 LIBINSTRUMENT_CFLAGS := $(filter-out -MD, $(LIBINSTRUMENT_CFLAGS)) where /MD is removed from the compiler options, which causes the object files to link against the static CRT.. The comment sounds like I break something by linking against dynamic C-Runtime. But I do not understand the comment entirely, could someone please elaborate a bit? (more precisely, I do not see how we could even run into a situation where we could not resolve the dynamic C-Runtime and still be able to launch the JVM to load the instrument.dll). Thanks a lot! Thomas St?fe -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.gabdurakhmanov at oracle.com Fri Nov 14 16:23:21 2014 From: sergey.gabdurakhmanov at oracle.com (Sergey Gabdurakhmanov) Date: Fri, 14 Nov 2014 08:23:21 -0800 (PST) Subject: RFR(XS): 8048050: Agent NullPointerException when rmi.port in use Message-ID: <8c93fff6-4bdd-4293-ba0d-f49649489ecf@default> Hi Daniel, Our documentation does not specify the exact exception that should be thrown in this scenario. But it should be reasonable. That makes testcase very difficult to implement. Because "reasonable" is not clear for test. E.g. "divided by zero" is not reasonable, but "illegal argument" is... I prefer do not put any tests where. BR, Sergey ----- Original Message ----- From: daniel.fuchs at oracle.com To: jaroslav.bachorik at oracle.com, sergey.gabdurakhmanov at oracle.com, hotspot-runtime-dev at openjdk.java.net, dmitry.samersoff at oracle.com, serviceability-dev at openjdk.java.net Sent: Friday, November 14, 2014 4:32:38 PM (GMT+0300) Auto-Detected Subject: Re: RFR(XS): 8048050: Agent NullPointerException when rmi.port in use Hi Sergey, The fix looks fine. I wonder whether there should be a testcase for that? best regards, -- daniel On 14/11/14 14:10, Jaroslav Bachorik wrote: > > Good to go. > > -JB- > > On 11/14/2014 02:07 PM, Sergey Gabdurakhmanov wrote: >> Hi, >> >> Could I please have a review of this small fix. >> >> webrev: http://cr.openjdk.java.net/~sgabdura/8048050/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8048050 >> >> Problem description: >> If the com.sun.management.jmxremote.rmi.port option is provided it will >> give a NPE if already in use by a different JVM. Its expected to fail >> but should provide an appropriate exception. >> >> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : >> Run two instances in different JVMs at same time with the following >> options: >> -Dcom.sun.management.jmxremote.port=2222 >> -Dcom.sun.management.jmxremote.rmi.port=2223 >> -Dcom.sun.management.jmxremote.authenticate=false >> >> Root cause: >> Then we trying to start JMXConnectorServer (see method exportMBeanServer >> of class sun.management.jmxremote.ConnectorBootstrap on already used >> port it cause IOException. Call of connServer.getAddress().toString() in >> the exception handler cause NullPointerException because >> connServer.getAddress() returns null. >> >> Solution: >> Provide url.toString() if connServer.getAddress() is null >> >> I'm going to push this fix into JDK9, 8 and 7. >> >> BR, >> Sergey >> > From maynardj at us.ibm.com Fri Nov 14 17:00:27 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Fri, 14 Nov 2014 11:00:27 -0600 Subject: PowerPC: core file option not available with serviceability tools In-Reply-To: <5433EC3E.1010800@us.ibm.com> References: <53B5A92A.401@us.ibm.com> <53BD477D.2090107@us.ibm.com> <5429E046.8030003@us.ibm.com> <5433EC3E.1010800@us.ibm.com> Message-ID: <5466352B.3010504@us.ibm.com> On 10/07/2014 08:35 AM, Maynard Johnson wrote: > On 10/07/2014 03:58 AM, Volker Simonis wrote: >> Hi Maynard, >> >> I'm now back from JavaOne and can look at this issue. Could you please >> share your current implementation so I can reproduce your problem more >> easily. > See attachment. The two patches in the attached tar file apply to a jdk9-dev snapshot from July. I haven't even tried forward-porting to current upstream code, so I don't know how well they would apply. >> >> By the way, you can find the ppc frame layout description of all the >> different frame types (native, interpreted, compiled) in >> /hotspot/src/cpu/ppc/vm/frame_ppc.hpp. The different frame::sender() >> implementations (in frame_x86.cpp, frame_ppc.cpp, ..) contain all the > Yes, I've been studying those files, but I freely admit I don't have a good grasp of the code yet. >> gory details about how to walk a frame. That's what you have to >> implement in Java in order to get a full stack trace from the >> serviceability tools. On x86 the frame pointer (i.e. the ebp register >> points to the last frame pointer while (frame pointer - 1) points to >> the return pc. > Ummm . . . Stack addresses grow downward, and I was under the impression 'return pc' was the word on the stack directly before the ebp, which would mean return pc is at 'frame pointer + 1'. Or am I off base here? Nevertheless, my question below concerns the "pc", not the "return pc". Perhaps I'm misunderstanding "pc" in this context; but even so, the x86 code still seems wrong: > > this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()); > > If, in fact, 'this.pc' is supposed to represent 'return pc' in this context, then I would think the code should be: > > this.pc = raw_fp.getAddressAt(VM.getVM().getAddressSize()); > > I hope you can help set me on the right track. As you can see, I'm lost in the weeds right now. :-) Hi, Volker, I presume you've been too busy to help out with this, so I had another go at it, and was able to make quite a bit of progress. The main issue was that I was unwittingly building my openJDK source with the "--with-jvm-interpreter=cpp" configure option! Once I discovered that and removed that option, the stack started making sense, since my new ppc64 agent's reflection of the stack assumes the use of the template interpreter (as does the x86 agent code which the ppc64 stuff is based on). So now I have jmap, jsadebugd, and jstack working for ppc64 on both big endian and little endian -- almost. There are a couple issues yet with jstack that I'm stuck on. I will post the patches as an RFC and document those issues. If you could find time to review the patches and perhaps help out with the open issues, I would appreciate it. Thanks! -Maynard > > -Maynard >> >> Regards, >> Volker >> >> >> On Tue, Sep 30, 2014 at 12:42 AM, Maynard Johnson wrote: >>> On 07/09/2014 12:38 PM, Volker Simonis wrote: >>>> On Wed, Jul 9, 2014 at 3:45 PM, Maynard Johnson wrote: >>>>> On 07/04/2014 10:59 AM, Volker Simonis wrote: >>>>>> Hi Maynard, >>>>>> >>>>>> we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and >>>>>> AIX (we have other proprietary servicibility tools). Because of that >>>>>> (and because SA isn't specified by the SE specification) porting the >>>>>> SA agent was no top priority until now. But there are no technical >>>>>> reasons why it should not work (it's just a lack of resources). Of >>>>>> course contributions are always highly welcome:) >>>>>> >>>>>> That said, the SA agent library and jar file actually gets build. If >>>>>> you do a complete build you'll find them under: >>>>>> >>>>>> hotspot/linux_ppc64_compiler2/generated/sa-jdi.jar >>>>>> hotspot/linux_ppc64_compiler2/{product,fastdebug,debug}/libsaproc.so >>>>>> >>>>>> in the build directory. They are just not copied into the jdk >>>>>> workspace and the created images because they don't work out of the >>>>>> box. >>>>>> >>>>>> The following two patches for the jdk9 top-level and hotspot >>>>>> repositories respectively should fix the build such that the agent >>>>>> files will be correctly copied into the images. >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/sa_toplevel >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/sa_hotspot/ >>>>>> >>>>>> They will get you to the point where for example 'jstack' will run up >>>>>> to the following point: >>>>> Ok, great. This should be enough to get me started. I should have time to begin on this later this week or early next week. >>>> >>>> Hi Maynard, >>>> >>>> great to welcome you in the ppc64 porting team:) >>>> >>>>> I may come knocking at your "door" for some occasional help, but I'll try to keep that to a minimum. >>> Hi, Volker. Knock, knock. :-) >>> I was preoccupied for a while this summer rolling out the latest release of oprofile (for which I'm the maintainer), but am now coming back to this task. I've implemented what I believe are all of the necessary ppc64-specific Java files to enable the jstack and jmap tools to work on core files. I've also updated hotspot/agent/src/os/linux/LinuxDebuggerLocal.c to implement the accumulation of register data on ppc64 vi ptrace. But now I've run into a problem I need help with. >>> >>> When I run jstack on my POWER7 system, it gets stuck in a loop in sun.jvm.hotspot.tools.StackTrace::run. There's an inner for-loop there where cur.getLastJavaVFrameDbg() is called ('cur' is a JavaThread). For the first JavaThread, we do return from getLastJavaVFrameDbg(), just as we do when running jstack on my Intel laptop. But for the second JavaThread, we never return from getLastJavaVFrameDbg() on ppc64. I believe the root of the problem is in my new sun.jvm.hotspot.runtime.ppc64.PPC64Frame class. The getLastJavaVFrameDbg method calls getCurrentFrameGuess, which is implemented in the new sun.jvm.hotspot.runtime.linux_ppc64.LinuxPPC64JavaThreadPDAccess class. In both ppc64 and x86, this first level xxxCurrentFrameGuess object is instantiated with a 'pc' value of null, so getCurrentFrameGuess then new's up a xxxFrame object, passing in the SP and FP, but no PC. The implementation of the PPC64Frame(Address,Address) constructor is currently identical to the X86Frame ! c! > ons! >>> tructor, b >>> ut is almost certainly incorrect. In this constructor, the 'pc' is set as follows: >>> this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()); >>> >>> This works fine on X86, but not on ppc64. But I'm not understanding how this even works on X86. From what I understand, the data below the stack pointer on X86 is the "red zone". How is that being used as a pc? But more importantly, do you know how I can ascertain what the 'pc' value should be for ppc64? >>> >>> Thanks in advance for any assistance you can give. >>> >>> -Maynard >>> >>>> >>>> Please feel free to ask any questions. The OpenJDK project and >>>> especially the HotSpot part are known to take some getting used to. >>>> >>>>> I was wondering if a bug report should be opened in JBS, just to record that the issue is being worked. Thoughts? >>>> >>>> I have opened "8049715: PPC64: First steps to enable SA on >>>> Linux/PPC64" (https://bugs.openjdk.java.net/browse/JDK-8049715) for >>>> the patch which I sent you with the last mail. I've already sent out >>>> webrevs for that change and hopefully it will be fixed within the next >>>> few days. >>>> >>>> For the actual port of the ppc64-specific stuff I opened bug "8049716 >>>> PPC64: Implement SA on Linux/PPC64" >>>> (https://bugs.openjdk.java.net/browse/JDK-8049716). I can also help >>>> with hosting the webrevs, once you have a running version. >>>> >>>> Regards, >>>> Volker >>>> >>>>> >>>>> -Maynard >>>>>> >>>>>>> images/j2sdk-image/bin/jstack ./jdk/bin/java core.13547 >>>>>> Attaching to core core.13547 from executable ./jdk/bin/java, please wait... >>>>>> WARNING: Hotspot VM version >>>>>> 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 does not match with >>>>>> SA version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00. You may >>>>>> see unexpected results. >>>>>> Debugger attached successfully. >>>>>> Server compiler detected. >>>>>> JVM version is 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 >>>>>> Deadlock Detection: >>>>>> >>>>>> Exception in thread "main" java.lang.reflect.InvocationTargetException >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:484) >>>>>> at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) >>>>>> at sun.tools.jstack.JStack.main(JStack.java:106) >>>>>> Caused by: java.lang.ExceptionInInitializerError >>>>>> at sun.jvm.hotspot.runtime.VM.getThreads(VM.java:610) >>>>>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:54) >>>>>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >>>>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) >>>>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>>>>> at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) >>>>>> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>> at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) >>>>>> ... 6 more >>>>>> Caused by: java.lang.RuntimeException: OS/CPU combination linux/ppc64 >>>>>> not yet supported >>>>>> at sun.jvm.hotspot.runtime.Threads.initialize(Threads.java:97) >>>>>> at sun.jvm.hotspot.runtime.Threads.access$000(Threads.java:42) >>>>>> at sun.jvm.hotspot.runtime.Threads$1.update(Threads.java:52) >>>>>> at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) >>>>>> at sun.jvm.hotspot.runtime.Threads.(Threads.java:50) >>>>>> ... 16 more >>>>>> >>>>>> And that's the point where I was saying that "contributions are always >>>>>> highly welcome:)" >>>>>> >>>>>> Now all the Linux/PPC64 specific class under >>>>>> hotspot/agent/src/share/classes/ would have to be implemented (e.g. >>>>>> sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess). Are you >>>>>> interested in contributing to this project? >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> PS: I cc-ed serviceability-dev because I remember that they started a >>>>>> poll a while ago about who is using the SA tools. I'm therefore not >>>>>> quite sure what's the current status and what are the future plan for >>>>>> these libraries. >>>>>> >>>>>> >>>>>> On Thu, Jul 3, 2014 at 9:04 PM, Maynard Johnson wrote: >>>>>>> Hi, all, >>>>>>> On my Intel laptop, I note that certain jdk9 serviceability tools -- jstack, jmap, jsadebugd -- have an option to pass a core file instead of a process ID; for example: >>>>>>> >>>>>>> $ jstack -h >>>>>>> Usage: >>>>>>> jstack [-l] >>>>>>> (to connect to running process) >>>>>>> jstack -F [-m] [-l] >>>>>>> (to connect to a hung process) >>>>>>> jstack [-m] [-l] >>>>>>> (to connect to a core file) >>>>>>> jstack [-m] [-l] [server_id@] >>>>>>> (to connect to a remote debug server) >>>>>>> >>>>>>> But on my PowerLinux box, the core file option is missing from the usage output. I see that jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStack.java requires the existence of sun.jvm.hotspot.tools.JStack for the core file option to be made available. On my Intel system, the sun.jvm.hotspot.tools.JStack class is packaged in sa-jdi.jar in /jvm/openjdk-1.9.0-internal/lib/. But the sa-jdi.jar is missing on PowerPC. Is there a technical reason for this or is it an oversight? >>>>>>> >>>>>>> The jsadebugd tool does not run at all on PowerLinux; it gets the following error: >>>>>>> >>>>>>> Error: Could not find or load main class sun.jvm.hotspot.jdi.SADebugServer >>>>>>> >>>>>>> On my Intel system, the SADebugServer class is packaged in the sa-jdi.jar mentioned above. >>>>>>> >>>>>>> I've spent the past day or so looking at makefiles until I'm cross-eyed, but haven't yet found where the issue might be. Any tips would be appreciated. >>>>>>> >>>>>>> Thanks. >>>>>>> -Maynard >>>>>>> >>>>>> >>>>> >>>> >>> >> > From maynardj at us.ibm.com Fri Nov 14 18:09:24 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Fri, 14 Nov 2014 12:09:24 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files Message-ID: <54664554.4060309@us.ibm.com> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: OS/CPU combination linux/ppc64 not yet supported I will post a patch set that adds this support. The patch set consists of the following patches: PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. ------------ Open issues: ------------ 1) The jstack tool does not print a stack entry for the 'main()' method of the Java workload (attached) under test. For example: (Note: Addresses and method signatures elided for brevity.) Thread 24358: (state = IN_JAVA, current Java SP = null ) - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) ==> (Expect an entry for test.main() here) 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: Thread 24779: (state = IN_JAVA, current Java SP = null ) - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) Again, the 'test.main' method is missing, but there's also the anomaly of the test.run_test' method showing up twice in the stack, implying that it is called by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- but these are totally distinct call graphs. Somehow, we are seeing these two distinct stacks in the core file, which seems impossible. --------- Any help offered on these two open issues would be greatly appreciated. -Maynard -------------- next part -------------- A non-text attachment was scrubbed... Name: test.java Type: text/x-java Size: 1447 bytes Desc: not available URL: From maynardj at us.ibm.com Fri Nov 14 18:10:01 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Fri, 14 Nov 2014 12:10:01 -0600 Subject: PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files Message-ID: <54664579.8010200@us.ibm.com> This patch updates some build files and C/C++ files to enable the PPC64 Serviceability agent code in patch 2/2. Signed-off-by: Maynard Johnson Index: jdk9-dev/hotspot/agent/make/Makefile =================================================================== --- jdk9-dev.orig/hotspot/agent/make/Makefile +++ jdk9-dev/hotspot/agent/make/Makefile @@ -58,15 +58,19 @@ sun.jvm.hotspot.debugger.cdbg.basic.x86 sun.jvm.hotspot.debugger.dummy \ sun.jvm.hotspot.debugger.linux \ sun.jvm.hotspot.debugger.linux.amd64 \ +sun.jvm.hotspot.debugger.linux.ppc64 \ sun.jvm.hotspot.debugger.linux.x86 \ sun.jvm.hotspot.debugger.posix \ sun.jvm.hotspot.debugger.posix.elf \ +sun.jvm.hotspot.debugger.ppc64 \ sun.jvm.hotspot.debugger.proc \ sun.jvm.hotspot.debugger.proc.amd64 \ +sun.jvm.hotspot.debugger.proc.ppc64 \ sun.jvm.hotspot.debugger.proc.sparc \ sun.jvm.hotspot.debugger.proc.x86 \ sun.jvm.hotspot.debugger.remote \ sun.jvm.hotspot.debugger.remote.amd64 \ +sun.jvm.hotspot.debugger.remote.ppc64 \ sun.jvm.hotspot.debugger.remote.sparc \ sun.jvm.hotspot.debugger.remote.x86 \ sun.jvm.hotspot.debugger.sparc \ @@ -93,9 +97,11 @@ sun.jvm.hotspot.runtime.bsd_amd64 \ sun.jvm.hotspot.runtime.bsd_x86 \ sun.jvm.hotspot.runtime.linux \ sun.jvm.hotspot.runtime.linux_amd64 \ +sun.jvm.hotspot.runtime.linux_ppc64 \ sun.jvm.hotspot.runtime.linux_sparc \ sun.jvm.hotspot.runtime.linux_x86 \ sun.jvm.hotspot.runtime.posix \ +sun.jvm.hotspot.runtime.ppc64 \ sun.jvm.hotspot.runtime.solaris_amd64 \ sun.jvm.hotspot.runtime.solaris_sparc \ sun.jvm.hotspot.runtime.solaris_x86 \ @@ -142,15 +148,19 @@ sun/jvm/hotspot/debugger/cdbg/basic/amd6 sun/jvm/hotspot/debugger/cdbg/basic/x86/*.java \ sun/jvm/hotspot/debugger/dummy/*.java \ sun/jvm/hotspot/debugger/linux/*.java \ +sun/jvm/hotspot/debugger/linux/ppc64/*.java \ sun/jvm/hotspot/debugger/linux/x86/*.java \ sun/jvm/hotspot/debugger/posix/*.java \ sun/jvm/hotspot/debugger/posix/elf/*.java \ +sun/jvm/hotspot/debugger/ppc64/*.java \ sun/jvm/hotspot/debugger/proc/*.java \ sun/jvm/hotspot/debugger/proc/amd64/*.java \ +sun/jvm/hotspot/debugger/proc/ppc64/*.java \ sun/jvm/hotspot/debugger/proc/sparc/*.java \ sun/jvm/hotspot/debugger/proc/x86/*.java \ sun/jvm/hotspot/debugger/remote/*.java \ sun/jvm/hotspot/debugger/remote/amd64/*.java \ +sun/jvm/hotspot/debugger/remote/ppc64/*.java \ sun/jvm/hotspot/debugger/remote/sparc/*.java \ sun/jvm/hotspot/debugger/remote/x86/*.java \ sun/jvm/hotspot/debugger/sparc/*.java \ @@ -174,9 +184,11 @@ sun/jvm/hotspot/runtime/bsd_amd64/*.java sun/jvm/hotspot/runtime/bsd_x86/*.java \ sun/jvm/hotspot/runtime/linux/*.java \ sun/jvm/hotspot/runtime/linux_amd64/*.java \ +sun/jvm/hotspot/runtime/linux_ppc64/*.java \ sun/jvm/hotspot/runtime/linux_sparc/*.java \ sun/jvm/hotspot/runtime/linux_x86/*.java \ sun/jvm/hotspot/runtime/posix/*.java \ +sun/jvm/hotspot/runtime/ppc64/*.java \ sun/jvm/hotspot/runtime/solaris_amd64/*.java \ sun/jvm/hotspot/runtime/solaris_sparc/*.java \ sun/jvm/hotspot/runtime/solaris_x86/*.java \ Index: jdk9-dev/hotspot/make/sa.files =================================================================== --- jdk9-dev.orig/hotspot/make/sa.files +++ jdk9-dev/hotspot/make/sa.files @@ -51,16 +51,20 @@ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugge $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/dummy/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/linux/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/linux/amd64/*.java \ +$(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/linux/ppc64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/linux/x86/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/linux/sparc/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/posix/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/posix/elf/*.java \ +$(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/ppc64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/proc/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/proc/amd64/*.java \ +$(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/proc/ppc64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/proc/sparc/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/proc/x86/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/remote/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/remote/amd64/*.java \ +$(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/remote/ppc64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/remote/sparc/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/remote/x86/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/debugger/sparc/*.java \ Index: jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c =================================================================== --- jdk9-dev.orig/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c +++ jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c @@ -49,6 +49,10 @@ #include "sun_jvm_hotspot_debugger_sparc_SPARCThreadContext.h" #endif +#ifdef ppc64 +#include "sun_jvm_hotspot_debugger_ppc64_PPC64ThreadContext.h" +#endif + static jfieldID p_ps_prochandle_ID = 0; static jfieldID threadList_ID = 0; static jfieldID loadObjectList_ID = 0; @@ -341,7 +345,7 @@ JNIEXPORT jbyteArray JNICALL Java_sun_jv return (err == PS_OK)? array : 0; } -#if defined(i386) || defined(amd64) || defined(sparc) || defined(sparcv9) +#if defined(i386) || defined(amd64) || defined(sparc) || defined(sparcv9) | defined(ppc64) JNIEXPORT jlongArray JNICALL Java_sun_jvm_hotspot_debugger_linux_LinuxDebuggerLocal_getThreadIntegerRegisterSet0 (JNIEnv *env, jobject this_obj, jint lwp_id) { @@ -366,6 +370,10 @@ JNIEXPORT jlongArray JNICALL Java_sun_jv #if defined(sparc) || defined(sparcv9) #define NPRGREG sun_jvm_hotspot_debugger_sparc_SPARCThreadContext_NPRGREG #endif +#ifdef ppc64 +#define NPRGREG sun_jvm_hotspot_debugger_ppc64_PPC64ThreadContext_NPRGREG +#endif + array = (*env)->NewLongArray(env, NPRGREG); CHECK_EXCEPTION_(0); @@ -458,6 +466,45 @@ JNIEXPORT jlongArray JNICALL Java_sun_jv regs[REG_INDEX(R_O7)] = gregs.u_regs[14]; #endif /* sparc */ +#ifdef ppc64 +#define REG_INDEX(reg) sun_jvm_hotspot_debugger_ppc64_PPC64ThreadContext_##reg + + regs[REG_INDEX(LR)] = gregs.link; + regs[REG_INDEX(NIP)] = gregs.nip; + regs[REG_INDEX(R0)] = gregs.gpr[0]; + regs[REG_INDEX(R1)] = gregs.gpr[1]; + regs[REG_INDEX(R2)] = gregs.gpr[2]; + regs[REG_INDEX(R3)] = gregs.gpr[3]; + regs[REG_INDEX(R4)] = gregs.gpr[4]; + regs[REG_INDEX(R5)] = gregs.gpr[5]; + regs[REG_INDEX(R6)] = gregs.gpr[6]; + regs[REG_INDEX(R7)] = gregs.gpr[7]; + regs[REG_INDEX(R8)] = gregs.gpr[8]; + regs[REG_INDEX(R9)] = gregs.gpr[9]; + regs[REG_INDEX(R10)] = gregs.gpr[10]; + regs[REG_INDEX(R11)] = gregs.gpr[11]; + regs[REG_INDEX(R12)] = gregs.gpr[12]; + regs[REG_INDEX(R13)] = gregs.gpr[13]; + regs[REG_INDEX(R14)] = gregs.gpr[14]; + regs[REG_INDEX(R15)] = gregs.gpr[15]; + regs[REG_INDEX(R16)] = gregs.gpr[16]; + regs[REG_INDEX(R17)] = gregs.gpr[17]; + regs[REG_INDEX(R18)] = gregs.gpr[18]; + regs[REG_INDEX(R19)] = gregs.gpr[19]; + regs[REG_INDEX(R20)] = gregs.gpr[20]; + regs[REG_INDEX(R21)] = gregs.gpr[21]; + regs[REG_INDEX(R22)] = gregs.gpr[22]; + regs[REG_INDEX(R23)] = gregs.gpr[23]; + regs[REG_INDEX(R24)] = gregs.gpr[24]; + regs[REG_INDEX(R25)] = gregs.gpr[25]; + regs[REG_INDEX(R26)] = gregs.gpr[26]; + regs[REG_INDEX(R27)] = gregs.gpr[27]; + regs[REG_INDEX(R28)] = gregs.gpr[28]; + regs[REG_INDEX(R29)] = gregs.gpr[29]; + regs[REG_INDEX(R30)] = gregs.gpr[30]; + regs[REG_INDEX(R31)] = gregs.gpr[31]; + +#endif (*env)->ReleaseLongArrayElements(env, array, regs, JNI_COMMIT); return array; Index: jdk9-dev/hotspot/make/linux/makefiles/sa.make =================================================================== --- jdk9-dev.orig/hotspot/make/linux/makefiles/sa.make +++ jdk9-dev/hotspot/make/linux/makefiles/sa.make @@ -109,6 +109,7 @@ $(GENERATED)/sa-jdi.jar:: $(AGENT_FILES) $(QUIETLY) $(REMOTE) $(RUN.JAVAH) -classpath $(SA_CLASSDIR) -d $(GENERATED) -jni sun.jvm.hotspot.debugger.x86.X86ThreadContext $(QUIETLY) $(REMOTE) $(RUN.JAVAH) -classpath $(SA_CLASSDIR) -d $(GENERATED) -jni sun.jvm.hotspot.debugger.amd64.AMD64ThreadContext $(QUIETLY) $(REMOTE) $(RUN.JAVAH) -classpath $(SA_CLASSDIR) -d $(GENERATED) -jni sun.jvm.hotspot.debugger.sparc.SPARCThreadContext + $(QUIETLY) $(REMOTE) $(RUN.JAVAH) -classpath $(SA_CLASSDIR) -d $(GENERATED) -jni sun.jvm.hotspot.debugger.ppc64.PPC64ThreadContext $(QUIETLY) $(REMOTE) $(RUN.JAVAH) -classpath $(SA_CLASSDIR) -d $(GENERATED) -jni sun.jvm.hotspot.asm.Disassembler clean: Index: jdk9-dev/hotspot/src/share/vm/runtime/vmStructs.cpp =================================================================== --- jdk9-dev.orig/hotspot/src/share/vm/runtime/vmStructs.cpp +++ jdk9-dev/hotspot/src/share/vm/runtime/vmStructs.cpp @@ -2568,6 +2568,8 @@ typedef TwoOopHashtable This patch adds PPC64 implementations of various class files needed to support the Hotspot serviceability agent, most of which involves mirroring the VM's stack for the jstack tool. The patch also makes some minor updates to several architecture-independent class files to enable ppc64 support. Going along with what appears to be tradition, the new PPC64 files have the Oracle copyright statement instead of an IBM copyright, since much of the code in these files was copied over from the x86 versions. Signed-off-by: Maynard Johnson Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java =================================================================== --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java @@ -26,14 +26,17 @@ package sun.jvm.hotspot.debugger.linux; import java.io.*; import java.util.*; + import sun.jvm.hotspot.debugger.*; import sun.jvm.hotspot.debugger.cdbg.*; import sun.jvm.hotspot.debugger.x86.*; import sun.jvm.hotspot.debugger.amd64.*; import sun.jvm.hotspot.debugger.sparc.*; +import sun.jvm.hotspot.debugger.ppc64.*; import sun.jvm.hotspot.debugger.linux.x86.*; import sun.jvm.hotspot.debugger.linux.amd64.*; import sun.jvm.hotspot.debugger.linux.sparc.*; +import sun.jvm.hotspot.debugger.linux.ppc64.*; import sun.jvm.hotspot.utilities.*; class LinuxCDebugger implements CDebugger { @@ -96,7 +99,14 @@ class LinuxCDebugger implements CDebugge Address pc = context.getRegisterAsAddress(SPARCThreadContext.R_O7); if (pc == null) return null; return new LinuxSPARCCFrame(dbg, sp, pc, LinuxDebuggerLocal.getAddressSize()); - } else { + } else if (cpu.equals("ppc64")) { + PPC64ThreadContext context = (PPC64ThreadContext) thread.getContext(); + Address sp = context.getRegisterAsAddress(PPC64ThreadContext.SP); + if (sp == null) return null; + Address pc = context.getRegisterAsAddress(PPC64ThreadContext.PC); + if (pc == null) return null; + return new LinuxPPC64CFrame(dbg, sp, pc, LinuxDebuggerLocal.getAddressSize()); + } else { // Runtime exception thrown by LinuxThreadContextFactory if unknown cpu ThreadContext context = (ThreadContext) thread.getContext(); return context.getTopFrame(dbg); Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java =================================================================== --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java @@ -29,6 +29,7 @@ import sun.jvm.hotspot.debugger.*; import sun.jvm.hotspot.debugger.linux.amd64.*; import sun.jvm.hotspot.debugger.linux.ia64.*; import sun.jvm.hotspot.debugger.linux.x86.*; +import sun.jvm.hotspot.debugger.linux.ppc64.*; import sun.jvm.hotspot.debugger.linux.sparc.*; class LinuxThreadContextFactory { @@ -42,6 +43,8 @@ class LinuxThreadContextFactory { return new LinuxIA64ThreadContext(dbg); } else if (cpu.equals("sparc")) { return new LinuxSPARCThreadContext(dbg); + } else if (cpu.equals("ppc64")) { + return new LinuxPPC64ThreadContext(dbg); } else { try { Class tcc = Class.forName("sun.jvm.hotspot.debugger.linux." + Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java @@ -0,0 +1,79 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.linux.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.debugger.linux.*; +import sun.jvm.hotspot.debugger.cdbg.*; +import sun.jvm.hotspot.debugger.cdbg.basic.*; + +final public class LinuxPPC64CFrame extends BasicCFrame { + // package/class internals only + + public LinuxPPC64CFrame(LinuxDebugger dbg, Address sp, Address pc, int address_size) { + super(dbg.getCDebugger()); + this.sp = sp; + this.pc = pc; + this.dbg = dbg; + this.address_size=address_size; + } + + // override base class impl to avoid ELF parsing + public ClosestSymbol closestSymbolToPC() { + // try native lookup in debugger. + return dbg.lookup(dbg.getAddressValue(pc())); + } + + public Address pc() { + return pc; + } + + public Address localVariableBase() { + return sp; + } + + public CFrame sender(ThreadProxy thread) { + if (sp == null) { + return null; + } + + Address nextSP = sp.getAddressAt( PPC64ThreadContext.SP * address_size + PPC64_STACK_BIAS); + if (nextSP == null) { + return null; + } + Address nextPC = sp.getAddressAt(PPC64ThreadContext.PC * address_size + PPC64_STACK_BIAS); + if (nextPC == null) { + return null; + } + return new LinuxPPC64CFrame(dbg, nextSP, nextPC,address_size); + } + + public static int PPC64_STACK_BIAS = 0; + private static int address_size; + private Address pc; + private Address sp; + private LinuxDebugger dbg; +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java @@ -0,0 +1,46 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.linux.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.debugger.linux.*; + +public class LinuxPPC64ThreadContext extends PPC64ThreadContext { + private LinuxDebugger debugger; + + public LinuxPPC64ThreadContext(LinuxDebugger debugger) { + super(); + this.debugger = debugger; + } + + public void setRegisterAsAddress(int index, Address value) { + setRegister(index, debugger.getAddressValue(value)); + } + + public Address getRegisterAsAddress(int index) { + return debugger.newAddress(getRegister(index)); + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java @@ -0,0 +1,123 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.cdbg.*; + +/** Specifies the thread context on ppc64 platforms; only a sub-portion + * of the context is guaranteed to be present on all operating + * systems. */ + +public abstract class PPC64ThreadContext implements ThreadContext { + + // NOTE: The indices for the various registers must be maintained as + // listed across various operating systems. However, only a small + // subset of the registers' values are guaranteed to be present (and + // must be present for the SA's stack walking to work). + + public static final int R31 = 0; + public static final int R30 = 1; + public static final int R29 = 2; + public static final int R28 = 3; + public static final int R27 = 4; + public static final int R26 = 5; + public static final int R25 = 6; + public static final int R24 = 7; + public static final int R23 = 8; + public static final int R22 = 9; + public static final int R21 = 10; + public static final int R20 = 11; + public static final int R19 = 12; + public static final int R18 = 13; + public static final int R17 = 14; + public static final int R16 = 15; + public static final int R15 = 16; + public static final int R14 = 17; + public static final int R13 = 18; + public static final int R12 = 19; + public static final int R11 = 20; + public static final int R10 = 21; + public static final int R9 = 22; + public static final int R8 = 23; + public static final int R7 = 24; + public static final int R6 = 25; + public static final int R5 = 26; + public static final int R4 = 27; + public static final int R3 = 28; + public static final int R2 = 29; + public static final int R1 = 30; + public static final int R0 = 31; + public static final int NIP = 32; + public static final int LR = 33; + + public static final int NPRGREG = 34; + + private static final String[] regNames = { + "r31", "r30", "r29", "r28", "r27", "r26", "r25", "r24", + "r23", "r22", "r21", "r20", "r19", "r18", "r17", "r16", + "r15", "r14", "r13", "r12", "r11", "r10", "r9", "r8", + "r7", "r6", "r5", "r4", "r3", "r2", "r1", "r0", + "nip", "link" + }; + + public static final int PC = NIP; + public static final int SP = R1; + + private long[] data; + + public PPC64ThreadContext() { + data = new long[NPRGREG]; + } + + public int getNumRegisters() { + return NPRGREG; + } + + public String getRegisterName(int index) { + return regNames[index]; + } + + public void setRegister(int index, long value) { + data[index] = value; + } + + public long getRegister(int index) { + return data[index]; + } + + public CFrame getTopFrame(Debugger dbg) { + return null; + } + + /** This can't be implemented in this class since we would have to + * tie the implementation to, for example, the debugging system */ + public abstract void setRegisterAsAddress(int index, Address value); + + /** This can't be implemented in this class since we would have to + * tie the implementation to, for example, the debugging system */ + public abstract Address getRegisterAsAddress(int index); + +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java =================================================================== --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -32,7 +32,9 @@ import sun.jvm.hotspot.debugger.*; import sun.jvm.hotspot.debugger.cdbg.*; import sun.jvm.hotspot.debugger.proc.amd64.*; import sun.jvm.hotspot.debugger.proc.sparc.*; +import sun.jvm.hotspot.debugger.proc.ppc64.*; import sun.jvm.hotspot.debugger.proc.x86.*; +import sun.jvm.hotspot.debugger.ppc64.*; import sun.jvm.hotspot.debugger.amd64.*; import sun.jvm.hotspot.debugger.sparc.*; import sun.jvm.hotspot.debugger.x86.*; @@ -86,6 +88,10 @@ public class ProcDebuggerLocal extends D threadFactory = new ProcAMD64ThreadFactory(this); pcRegIndex = AMD64ThreadContext.RIP; fpRegIndex = AMD64ThreadContext.RBP; + } else if (cpu.equals("ppc64")) { + threadFactory = new ProcPPC64ThreadFactory(this); + pcRegIndex = PPC64ThreadContext.PC; + fpRegIndex = PPC64ThreadContext.SP; } else { try { Class tfc = Class.forName("sun.jvm.hotspot.debugger.proc." + Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java @@ -0,0 +1,86 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.proc.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.debugger.proc.*; +import sun.jvm.hotspot.utilities.*; + +public class ProcPPC64Thread implements ThreadProxy { + private ProcDebugger debugger; + private int id; + + public ProcPPC64Thread(ProcDebugger debugger, Address addr) { + this.debugger = debugger; + + // FIXME: the size here should be configurable. However, making it + // so would produce a dependency on the "types" package from the + // debugger package, which is not desired. + this.id = (int) addr.getCIntegerAt(0, 4, true); + } + + public ProcPPC64Thread(ProcDebugger debugger, long id) { + this.debugger = debugger; + this.id = (int) id; + } + + public ThreadContext getContext() throws IllegalThreadStateException { + ProcPPC64ThreadContext context = new ProcPPC64ThreadContext(debugger); + long[] regs = debugger.getThreadIntegerRegisterSet(id); + if (Assert.ASSERTS_ENABLED) { + Assert.that(regs.length <= PPC64ThreadContext.NPRGREG, "size of register set is greater than " + PPC64ThreadContext.NPRGREG); + } + for (int i = 0; i < regs.length; i++) { + context.setRegister(i, regs[i]); + } + return context; + } + + public boolean canSetContext() throws DebuggerException { + return false; + } + + public void setContext(ThreadContext context) + throws IllegalThreadStateException, DebuggerException { + throw new DebuggerException("Unimplemented"); + } + + public String toString() { + return "t@" + id; + } + + public boolean equals(Object obj) { + if ((obj == null) || !(obj instanceof ProcPPC64Thread)) { + return false; + } + + return (((ProcPPC64Thread) obj).id == id); + } + + public int hashCode() { + return id; + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java @@ -0,0 +1,46 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.proc.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.debugger.proc.*; + +public class ProcPPC64ThreadContext extends PPC64ThreadContext { + private ProcDebugger debugger; + + public ProcPPC64ThreadContext(ProcDebugger debugger) { + super(); + this.debugger = debugger; + } + + public void setRegisterAsAddress(int index, Address value) { + setRegister(index, debugger.getAddressValue(value)); + } + + public Address getRegisterAsAddress(int index) { + return debugger.newAddress(getRegister(index)); + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java @@ -0,0 +1,44 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.proc.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.proc.*; + +public class ProcPPC64ThreadFactory implements ProcThreadFactory { + private ProcDebugger debugger; + + public ProcPPC64ThreadFactory(ProcDebugger debugger) { + this.debugger = debugger; + } + + public ThreadProxy createThreadWrapper(Address threadIdentifierAddr) { + return new ProcPPC64Thread(debugger, threadIdentifierAddr); + } + + public ThreadProxy createThreadWrapper(long id) { + return new ProcPPC64Thread(debugger, id); + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java =================================================================== --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java @@ -33,6 +33,7 @@ import sun.jvm.hotspot.debugger.cdbg.*; import sun.jvm.hotspot.debugger.remote.sparc.*; import sun.jvm.hotspot.debugger.remote.x86.*; import sun.jvm.hotspot.debugger.remote.amd64.*; +import sun.jvm.hotspot.debugger.remote.ppc64.*; /** An implementation of Debugger which wraps a RemoteDebugger, providing remote debugging via RMI. @@ -70,6 +71,11 @@ public class RemoteDebuggerClient extend cachePageSize = 4096; cacheNumPages = parseCacheNumPagesProperty(cacheSize / cachePageSize); unalignedAccessesOkay = true; + } else if (cpu.equals("ppc64")) { + threadFactory = new RemotePPC64ThreadFactory(this); + cachePageSize = 4096; + cacheNumPages = parseCacheNumPagesProperty(cacheSize / cachePageSize); + unalignedAccessesOkay = true; } else { try { Class tf = Class.forName("sun.jvm.hotspot.debugger.remote." + Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java @@ -0,0 +1,53 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.remote.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.debugger.remote.*; +import sun.jvm.hotspot.utilities.*; + +public class RemotePPC64Thread extends RemoteThread { + public RemotePPC64Thread(RemoteDebuggerClient debugger, Address addr) { + super(debugger, addr); + } + + public RemotePPC64Thread(RemoteDebuggerClient debugger, long id) { + super(debugger, id); + } + + public ThreadContext getContext() throws IllegalThreadStateException { + RemotePPC64ThreadContext context = new RemotePPC64ThreadContext(debugger); + long[] regs = (addr != null)? debugger.getThreadIntegerRegisterSet(addr) : + debugger.getThreadIntegerRegisterSet(id); + if (Assert.ASSERTS_ENABLED) { + Assert.that(regs.length == PPC64ThreadContext.NPRGREG, "size of register set must match"); + } + for (int i = 0; i < regs.length; i++) { + context.setRegister(i, regs[i]); + } + return context; + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java @@ -0,0 +1,50 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.remote.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.debugger.remote.*; + +public class RemotePPC64ThreadContext extends PPC64ThreadContext { + private RemoteDebuggerClient debugger; + + public RemotePPC64ThreadContext(RemoteDebuggerClient debugger) { + super(); + this.debugger = debugger; + } + + /** This can't be implemented in this class since we would have to + tie the implementation to, for example, the debugging system */ + public void setRegisterAsAddress(int index, Address value) { + setRegister(index, debugger.getAddressValue(value)); + } + + /** This can't be implemented in this class since we would have to + tie the implementation to, for example, the debugging system */ + public Address getRegisterAsAddress(int index) { + return debugger.newAddress(getRegister(index)); + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java @@ -0,0 +1,44 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.debugger.remote.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.remote.*; + +public class RemotePPC64ThreadFactory implements RemoteThreadFactory { + private RemoteDebuggerClient debugger; + + public RemotePPC64ThreadFactory(RemoteDebuggerClient debugger) { + this.debugger = debugger; + } + + public ThreadProxy createThreadWrapper(Address threadIdentifierAddr) { + return new RemotePPC64Thread(debugger, threadIdentifierAddr); + } + + public ThreadProxy createThreadWrapper(long id) { + return new RemotePPC64Thread(debugger, id); + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java =================================================================== --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java @@ -25,6 +25,7 @@ package sun.jvm.hotspot.runtime; import java.util.*; + import sun.jvm.hotspot.debugger.*; import sun.jvm.hotspot.types.*; import sun.jvm.hotspot.runtime.solaris_sparc.SolarisSPARCJavaThreadPDAccess; @@ -34,6 +35,7 @@ import sun.jvm.hotspot.runtime.win32_amd import sun.jvm.hotspot.runtime.win32_x86.Win32X86JavaThreadPDAccess; import sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess; import sun.jvm.hotspot.runtime.linux_amd64.LinuxAMD64JavaThreadPDAccess; +import sun.jvm.hotspot.runtime.linux_ppc64.LinuxPPC64JavaThreadPDAccess; import sun.jvm.hotspot.runtime.linux_sparc.LinuxSPARCJavaThreadPDAccess; import sun.jvm.hotspot.runtime.bsd_x86.BsdX86JavaThreadPDAccess; import sun.jvm.hotspot.runtime.bsd_amd64.BsdAMD64JavaThreadPDAccess; @@ -87,6 +89,8 @@ public class Threads { access = new LinuxAMD64JavaThreadPDAccess(); } else if (cpu.equals("sparc")) { access = new LinuxSPARCJavaThreadPDAccess(); + } else if (cpu.equals("ppc64")) { + access = new LinuxPPC64JavaThreadPDAccess(); } else { try { access = (JavaThreadPDAccess) Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java @@ -0,0 +1,132 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.runtime.linux_ppc64; + +import java.io.*; +import java.util.*; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.runtime.*; +import sun.jvm.hotspot.runtime.ppc64.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.utilities.*; + +public class LinuxPPC64JavaThreadPDAccess implements JavaThreadPDAccess { + private static AddressField osThreadField; + + // Field from OSThread + private static CIntegerField osThreadThreadIDField; + + // This is currently unneeded but is being kept in case we change + // the currentFrameGuess algorithm + private static final long GUESS_SCAN_RANGE = 128 * 1024; + + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + Type type = db.lookupType("JavaThread"); + osThreadField = type.getAddressField("_osthread"); + + Type osThreadType = db.lookupType("OSThread"); + osThreadThreadIDField = osThreadType.getCIntegerField("_thread_id"); + } + + public Address getLastJavaFP(Address addr) { + return null; + } + + public Address getLastJavaPC(Address addr) { + return null; + } + + public Address getBaseOfStackPointer(Address addr) { + return null; + } + + public Frame getLastFramePD(JavaThread thread, Address addr) { + Address fp = thread.getLastJavaFP(); + if (fp == null) { + return null; // no information + } + return new PPC64Frame(thread.getLastJavaSP(), fp); + } + + public RegisterMap newRegisterMap(JavaThread thread, boolean updateMap) { + return new PPC64RegisterMap(thread, updateMap); + } + + public Frame getCurrentFrameGuess(JavaThread thread, Address addr) { + ThreadProxy t = getThreadProxy(addr); + PPC64ThreadContext context = (PPC64ThreadContext) t.getContext(); + PPC64CurrentFrameGuess guesser = new PPC64CurrentFrameGuess(context, thread); + if (!guesser.run(GUESS_SCAN_RANGE)) { + return null; + } + if (guesser.getPC() == null) { + return new PPC64Frame(guesser.getSP(), guesser.getFP()); + } else { + return new PPC64Frame(guesser.getSP(), guesser.getFP(), guesser.getPC(), guesser.getLR()); + } + } + + public void printThreadIDOn(Address addr, PrintStream tty) { + tty.print(getThreadProxy(addr)); + } + + public void printInfoOn(Address threadAddr, PrintStream tty) { + tty.print("Thread id: "); + printThreadIDOn(threadAddr, tty); +// tty.println("\nPostJavaState: " + getPostJavaState(threadAddr)); + } + + public Address getLastSP(Address addr) { + ThreadProxy t = getThreadProxy(addr); + PPC64ThreadContext context = (PPC64ThreadContext) t.getContext(); + return context.getRegisterAsAddress(PPC64ThreadContext.SP); + } + + public Address getLastFP(Address addr) { + return getLastSP(addr).getAddressAt(0); + } + + public ThreadProxy getThreadProxy(Address addr) { + // Addr is the address of the JavaThread. + // Fetch the OSThread (for now and for simplicity, not making a + // separate "OSThread" class in this package) + Address osThreadAddr = osThreadField.getValue(addr); + // Get the address of the _thread_id from the OSThread + Address threadIdAddr = osThreadAddr.addOffsetTo(osThreadThreadIDField.getOffset()); + + JVMDebugger debugger = VM.getVM().getDebugger(); + return debugger.getThreadForIdentifierAddress(threadIdAddr); + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java @@ -0,0 +1,181 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.runtime.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.debugger.ppc64.*; +import sun.jvm.hotspot.code.*; +import sun.jvm.hotspot.interpreter.*; +import sun.jvm.hotspot.runtime.*; +import sun.jvm.hotspot.runtime.ppc64.*; + +/**

Should be able to be used on all ppc64 platforms we support + (Linux/ppc64) to implement JavaThread's "currentFrameGuess()" + functionality. Input is a PPC64ThreadContext; output is SP, FP, + lr, and PC for an PPC64Frame. Instantiation of the PPC64Frame is left + to the caller, since we may need to subclass PPC64Frame to support + signal handler frames on Unix platforms.

+ */ + +public class PPC64CurrentFrameGuess { + private PPC64ThreadContext context; + private JavaThread thread; + private Address spFound; + private Address fpFound; + private Address pcFound; + private Address lrFound; + + private static final boolean DEBUG = System.getProperty("sun.jvm.hotspot.runtime.ppc64.PPC64Frame.DEBUG") + != null; + + public PPC64CurrentFrameGuess(PPC64ThreadContext context, + JavaThread thread) { + this.context = context; + this.thread = thread; + } + + /** Returns false if not able to find a frame within a reasonable range. */ + public boolean run(long regionInBytesToSearch) { + Address sp = context.getRegisterAsAddress(PPC64ThreadContext.SP); + Address pc = context.getRegisterAsAddress(PPC64ThreadContext.PC); + Address lr = context.getRegisterAsAddress(PPC64ThreadContext.LR); + if (sp == null) { + // Bail out if no last java frame either + if (thread.getLastJavaSP() != null) { + Address javaSP = thread.getLastJavaSP(); + Address javaFP = javaSP.getAddressAt(0); + setValues(javaSP, javaFP, null, lr); + return true; + } + return false; + } + /* There is no frame pointer per se for the ppc64 architecture. To mirror + * the behavior of the VM frame manager, we set fp to be the caller's (i.e., "sender's") + * stack pointer, which is the back chain value contained in our sp. + */ + Address fp = sp.getAddressAt(0); + setValues(null, null, null, null); // Assume we're not going to find anything + + VM vm = VM.getVM(); + if (vm.isJavaPCDbg(pc)) { + if (vm.isClientCompiler()) { + // Topmost frame is a Java frame. + if (DEBUG) { + System.out.println("CurrentFrameGuess: choosing compiler frame: sp = " + + sp + ", fp = " + fp + ", pc = " + pc + ", lr = " + lr); + } + setValues(sp, fp, pc, lr); + return true; + } else { + if (vm.getInterpreter().contains(pc)) { + if (DEBUG) { + System.out.println("CurrentFrameGuess: choosing interpreter frame: sp = " + + sp + ", fp = " + fp + ", pc = " + pc + ", lr = " + lr); + } + setValues(sp, fp, pc, lr); + return true; + } + + // This algorithm takes the current PC as a given and tries to + // find the correct corresponding SP by walking up the stack + // and repeatedly performing stackwalks (very inefficient). + for (long offset = 0; + offset < regionInBytesToSearch; + offset += vm.getAddressSize()) { + try { + Address curSP = sp.addOffsetTo(offset); + fp = curSP.getAddressAt(0); + Frame frame = new PPC64Frame(curSP, fp, pc, lr); + RegisterMap map = thread.newRegisterMap(false); + while (frame != null) { + if (frame.isEntryFrame() && frame.entryFrameIsFirst()) { + // We were able to traverse all the way to the + // bottommost Java frame. + // This sp looks good. Keep it. + if (DEBUG) { + System.out.println("CurrentFrameGuess: Choosing sp = " + curSP + ", pc = " + pc); + } + setValues(curSP, fp, pc, lr); + return true; + } + frame = frame.sender(map); + } + } catch (Exception e) { + if (DEBUG) { + System.out.println("CurrentFrameGuess: Exception " + e + " at offset " + offset); + } + // Bad SP. Try another. + } + } + + // Were not able to find a plausible SP to go with this PC. + // Bail out. + return false; + + } + } else { + // If the current program counter was not known to us as a Java + // PC, we currently assume that we are in the run-time system + // and attempt to look to thread-local storage for saved java SP. + // Note that if this is null (because we were, in fact, + // in Java code, i.e., vtable stubs or similar, and the SA + // didn't have enough insight into the target VM to understand + // that) then we are going to lose the entire stack trace for + // the thread, which is sub-optimal. FIXME. + + if (thread.getLastJavaSP() == null) { + if (DEBUG) + System.out.println("CurrentFrameGuess: last java sp is null"); + return false; // No known Java frames on stack + } + + Address javaSP = thread.getLastJavaSP(); + Address javaFP = javaSP.getAddressAt(0); + Address javaPC = thread.getLastJavaPC(); + lr = javaSP.getAddressAt(2 * VM.getVM().getAddressSize()); + if (DEBUG) { + System.out.println("CurrentFrameGuess: choosing last Java frame: sp = " + + javaSP + ", fp = " + javaFP + ", pc = " + javaPC + ", lr = " + lr); + } + setValues(javaSP, javaFP, javaPC, lr); + return true; + } + } + + public Address getSP() { return spFound; } + public Address getFP() { return fpFound; } + public Address getLR() { return lrFound; } + /** May be null if getting values from thread-local storage; take + care to call the correct PPC64Frame constructor to recover this if + necessary */ + public Address getPC() { return pcFound; } + + private void setValues(Address sp, Address fp, Address pc, Address lr) { + spFound = sp; + fpFound = fp; + pcFound = pc; + lrFound = lr; + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java @@ -0,0 +1,516 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.runtime.ppc64; + +import java.util.*; +import sun.jvm.hotspot.code.*; +import sun.jvm.hotspot.compiler.*; +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.oops.*; +import sun.jvm.hotspot.runtime.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.utilities.*; + +/** Specialization of and implementation of abstract methods of the + Frame class for the ppc64 family of CPUs. */ + +public class PPC64Frame extends Frame { + private static final boolean DEBUG; + static { + DEBUG = System.getProperty("sun.jvm.hotspot.runtime.ppc64.PPC64Frame.DEBUG") != null; + } + + // All frames + private static final int SENDER_SP_OFFSET = 0; + + // Interpreter frames + private static final int INTERPRETER_FRAME_MIRROR_OFFSET = -3; // for native calls only + private static final int INTERPRETER_FRAME_SENDER_SP_OFFSET = -4; + private static final int INTERPRETER_FRAME_LAST_SP_OFFSET = INTERPRETER_FRAME_SENDER_SP_OFFSET - 1; + private static final int INTERPRETER_FRAME_MDX_OFFSET = INTERPRETER_FRAME_LAST_SP_OFFSET -1; + private static final int INTERPRETER_FRAME_ESP_OFFSET = INTERPRETER_FRAME_MDX_OFFSET - 1; + private static final int INTERPRETER_FRAME_BCX_OFFSET = INTERPRETER_FRAME_ESP_OFFSET - 1; + private static final int INTERPRETER_FRAME_CACHE_OFFSET =INTERPRETER_FRAME_BCX_OFFSET - 1; + private static final int INTERPRETER_FRAME_MONITORS_OFFSET = INTERPRETER_FRAME_CACHE_OFFSET - 1; + private static final int INTERPRETER_FRAME_LOCALS_OFFSET = INTERPRETER_FRAME_MONITORS_OFFSET - 1; + private static final int INTERPRETER_FRAME_METHOD_OFFSET = INTERPRETER_FRAME_LOCALS_OFFSET - 1; + private static final int INTERPRETER_FRAME_INITIAL_SP_OFFSET = INTERPRETER_FRAME_BCX_OFFSET - 1; // FIXME: probably wrong, but unused anyway + private static final int INTERPRETER_FRAME_MONITOR_BLOCK_TOP_OFFSET = INTERPRETER_FRAME_INITIAL_SP_OFFSET; + private static final int INTERPRETER_FRAME_MONITOR_BLOCK_BOTTOM_OFFSET = INTERPRETER_FRAME_INITIAL_SP_OFFSET; + + // Entry frames + private static int ENTRY_FRAME_CALL_WRAPPER_OFFSET; + + // Native frames + private static int NATIVE_FRAME_INITIAL_PARAM_OFFSET; + + + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + int abi_minframe_size = db.lookupIntConstant("frame::abi_minframe_size").intValue(); + int entry_frame_locals_size = db.lookupIntConstant("frame::entry_frame_locals_size").intValue(); + int wordLength = (int)VM.getVM().getAddressSize(); + NATIVE_FRAME_INITIAL_PARAM_OFFSET = -abi_minframe_size/wordLength; + ENTRY_FRAME_CALL_WRAPPER_OFFSET = -entry_frame_locals_size/wordLength; + } + + + // an additional field beyond sp and pc: + Address raw_fp; // frame pointer + private Address lr; + private Address raw_unextendedSP; + + private PPC64Frame() { + } + + private void adjustForDeopt() { + if ( pc != null) { + // Look for a deopt pc and if it is deopted convert to original pc + CodeBlob cb = VM.getVM().getCodeCache().findBlob(pc); + if (cb != null && cb.isJavaMethod()) { + NMethod nm = (NMethod) cb; + if (pc.equals(nm.deoptHandlerBegin())) { + if (Assert.ASSERTS_ENABLED) { + Assert.that(this.getUnextendedSP() != null, "null SP in Java frame"); + } + // adjust pc if frame is deoptimized. + pc = this.getUnextendedSP().getAddressAt(nm.origPCOffset()); + deoptimized = true; + } + } + } + } + + public PPC64Frame(Address raw_sp, Address raw_fp, Address pc, Address lr) { + this.raw_sp = raw_sp; + this.raw_unextendedSP = raw_sp; + if (raw_fp == null) + this.raw_fp = raw_sp.getAddressAt(0); + else + this.raw_fp = raw_fp; + if (pc == null) + this.pc = raw_sp.getAddressAt(2 * VM.getVM().getAddressSize()); + else + this.pc = pc; + this.lr = lr; + adjustUnextendedSP(); + + // Frame must be fully constructed before this call + adjustForDeopt(); + + if (DEBUG) { + System.out.println("PPC64Frame(sp, fp, pc, lr): " + this); + dumpStack(); + } + } + + public PPC64Frame(Address raw_sp, Address raw_fp) { + this.raw_sp = raw_sp; + this.raw_unextendedSP = raw_sp; + if (raw_fp == null) + this.raw_fp = raw_sp.getAddressAt(0); + else + this.raw_fp = raw_fp; + this.pc = raw_sp.getAddressAt(2 * VM.getVM().getAddressSize()); + adjustUnextendedSP(); + + // Frame must be fully constructed before this call + adjustForDeopt(); + + if (DEBUG) { + System.out.println("PPC64Frame(sp, fp): " + this); + dumpStack(); + } + } + + public PPC64Frame(Address raw_sp, Address raw_unextendedSp, Address raw_fp, Address pc, Address lr) { + this.raw_sp = raw_sp; + this.raw_unextendedSP = raw_unextendedSp; + if (raw_fp == null) + this.raw_fp = raw_sp.getAddressAt(0); + else + this.raw_fp = raw_fp; + if (pc == null) + this.pc = raw_sp.getAddressAt(2 * VM.getVM().getAddressSize()); + else + this.pc = pc; + this.lr = lr; + adjustUnextendedSP(); + + // Frame must be fully constructed before this call + adjustForDeopt(); + + if (DEBUG) { + System.out.println("PPC64Frame(sp, unextendedSP, fp, pc, lr): " + this); + dumpStack(); + } + + } + + public Object clone() { + PPC64Frame frame = new PPC64Frame(); + frame.raw_sp = raw_sp; + frame.raw_unextendedSP = raw_unextendedSP; + frame.raw_fp = raw_fp; + frame.pc = pc; + frame.lr = lr; + frame.deoptimized = deoptimized; + return frame; + } + + public boolean equals(Object arg) { + if (arg == null) { + return false; + } + + if (!(arg instanceof PPC64Frame)) { + return false; + } + + PPC64Frame other = (PPC64Frame) arg; + + return (AddressOps.equal(getSP(), other.getSP()) && + AddressOps.equal(getUnextendedSP(), other.getUnextendedSP()) && + AddressOps.equal(getFP(), other.getFP()) && + AddressOps.equal(getPC(), other.getPC()) && + AddressOps.equal(getLR(), other.getLR())); + } + + public int hashCode() { + if (raw_sp == null) { + return 0; + } + + return raw_sp.hashCode(); + } + + public String toString() { + return "sp: " + (getSP() == null? "null" : getSP().toString()) + + ", unextendedSP: " + (getUnextendedSP() == null? "null" : getUnextendedSP().toString()) + + ", fp: " + (getFP() == null? "null" : getFP().toString()) + + ", pc: " + (pc == null? "null" : pc.toString()) + + ", lr: " + (lr == null? "null" : lr.toString()); + } + + // accessors for the instance variables + public Address getFP() { return raw_fp; } + public Address getSP() { return raw_sp; } + public Address getID() { return raw_sp; } + public Address getLR() { return lr; } + + // FIXME: not implemented yet (should be done for Solaris/PPC64) + public boolean isSignalHandlerFrameDbg() { return false; } + public int getSignalNumberDbg() { return 0; } + public String getSignalNameDbg() { return null; } + + public boolean isInterpretedFrameValid() { + if (Assert.ASSERTS_ENABLED) { + Assert.that(isInterpretedFrame(), "Not an interpreted frame"); + } + + // These are reasonable sanity checks + if (getFP() == null || getFP().andWithMask(0x3) != null) { + return false; + } + + if (getSP() == null || getSP().andWithMask(0x3) != null) { + return false; + } + + // These are hacks to keep us out of trouble. + // The problem with these is that they mask other problems + if (getFP().lessThanOrEqual(getSP())) { + // this attempts to deal with unsigned comparison above + return false; + } + + if (getFP().minus(getSP()) > 4096 * VM.getVM().getAddressSize()) { + // stack frames shouldn't be large. + return false; + } + + return true; + } + + // FIXME: not applicable in current system + // void patch_pc(Thread* thread, address pc); + + public Frame sender(RegisterMap regMap, CodeBlob cb) { + PPC64RegisterMap map = (PPC64RegisterMap) regMap; + + if (Assert.ASSERTS_ENABLED) { + Assert.that(map != null, "map must be set"); + } + + // Default is we done have to follow them. The sender_for_xxx will + // update it accordingly + map.setIncludeArgumentOops(false); + + if (isEntryFrame()) return senderForEntryFrame(map); + if (isInterpretedFrame()) return senderForInterpreterFrame(map); + + if(cb == null) { + cb = VM.getVM().getCodeCache().findBlob(getPC()); + } else { + if (Assert.ASSERTS_ENABLED) { + Assert.that(cb.equals(VM.getVM().getCodeCache().findBlob(getPC())), "Must be the same"); + } + } + + if (cb != null) { + return senderForCompiledFrame(map, cb); + } + + // Must be native-compiled frame, i.e. the marshaling code for native + // methods that exists in the core system. + return new PPC64Frame(getSenderSP(), getLink(), getSenderPC(), null); + } + + private Frame senderForEntryFrame(PPC64RegisterMap map) { + if (DEBUG) { + System.out.println("senderForEntryFrame"); + } + if (Assert.ASSERTS_ENABLED) { + Assert.that(map != null, "map must be set"); + } + // Java frame called from C; skip all C frames and return top C + // frame of that chunk as the sender + PPC64JavaCallWrapper jcw = (PPC64JavaCallWrapper) getEntryFrameCallWrapper(); + if (Assert.ASSERTS_ENABLED) { + Assert.that(!entryFrameIsFirst(), "next Java fp must be non zero"); + Assert.that(jcw.getLastJavaSP().greaterThan(getSP()), "must be above this frame on stack"); + } + PPC64Frame fr; + if (jcw.getLastJavaPC() != null) { + fr = new PPC64Frame(jcw.getLastJavaSP(), jcw.getLastJavaFP(), jcw.getLastJavaPC(), null); + } else { + fr = new PPC64Frame(jcw.getLastJavaSP(), jcw.getLastJavaFP()); + } + map.clear(); + if (Assert.ASSERTS_ENABLED) { + Assert.that(map.getIncludeArgumentOops(), "should be set by clear"); + } + return fr; + } + + //------------------------------------------------------------------------------ + // frame::adjust_unextended_sp + private void adjustUnextendedSP() { + raw_unextendedSP = getFP(); + } + private Frame senderForInterpreterFrame(PPC64RegisterMap map) { + if (DEBUG) { + System.out.println("senderForInterpreterFrame"); + } + Address unextendedSP = addressOfStackSlot(INTERPRETER_FRAME_SENDER_SP_OFFSET).getAddressAt(0); + Address sp = getSenderSP(); + + return new PPC64Frame(sp, unextendedSP, getLink(), getSenderPC(), null); + } + + + private Frame senderForCompiledFrame(PPC64RegisterMap map, CodeBlob cb) { + if (DEBUG) { + System.out.println("senderForCompiledFrame"); + } + + // + // NOTE: some of this code is (unfortunately) duplicated in PPC64CurrentFrameGuess + // + + if (Assert.ASSERTS_ENABLED) { + Assert.that(map != null, "map must be set"); + } + + // frame owned by optimizing compiler + if (Assert.ASSERTS_ENABLED) { + Assert.that(cb.getFrameSize() >= 0, "must have non-zero frame size"); + } + Address senderSP = getSenderSP(); + + // On ppc64, the return address is gotten from the link register -- not saved on stack + Address senderPC = getLR(); + + if (map.getUpdateMap()) { + // Tell GC to use argument oopmaps for some runtime stubs that need it. + // For C1, the runtime stub might not have oop maps, so set this flag + // outside of update_register_map. + map.setIncludeArgumentOops(cb.callerMustGCArguments()); + + if (cb.getOopMaps() != null) { + OopMapSet.updateRegisterMap(this, cb, map, true); + } + } + + return new PPC64Frame(senderSP, getLink(), senderPC, null); + } + + protected boolean hasSenderPD() { + // FIXME + return true; + } + + public long frameSize() { + return (getSenderSP().minus(getSP()) / VM.getVM().getAddressSize()); + } + + public Address getLink() { + return getSenderSP().getAddressAt(0); + } + + public Address getUnextendedSP() { return raw_unextendedSP; } + + // Return address: + public Address getSenderPC() { return lr; } + + // return address of param, zero origin index. + // MPJ note: Appears to be unused. + public Address getNativeParamAddr(int idx) { + return null; + // return addressOfStackSlot(NATIVE_FRAME_INITIAL_PARAM_OFFSET + idx); + } + + public Address getSenderSP() { return getFP(); } + public Address addressOfInterpreterFrameLocals() { + return addressOfStackSlot(INTERPRETER_FRAME_LOCALS_OFFSET); + } + + private Address addressOfInterpreterFrameBCX() { + return addressOfStackSlot(INTERPRETER_FRAME_BCX_OFFSET); + } + + public int getInterpreterFrameBCI() { + // FIXME: this is not atomic with respect to GC and is unsuitable + // for use in a non-debugging, or reflective, system. Need to + // figure out how to express this. + Address bcp = addressOfInterpreterFrameBCX().getAddressAt(0); + Address methodHandle = addressOfInterpreterFrameMethod().getAddressAt(0); + Method method = (Method)Metadata.instantiateWrapperFor(methodHandle); + return bcpToBci(bcp, method); + } + + public Address addressOfInterpreterFrameMDX() { + return addressOfStackSlot(INTERPRETER_FRAME_MDX_OFFSET); + } + + // FIXME + //inline int frame::interpreter_frame_monitor_size() { + // return BasicObjectLock::size(); + //} + + // expression stack + // (the max_stack arguments are used by the GC; see class FrameClosure) + + public Address addressOfInterpreterFrameExpressionStack() { + Address monitorEnd = interpreterFrameMonitorEnd().address(); + return monitorEnd.addOffsetTo(-1 * VM.getVM().getAddressSize()); + } + + public int getInterpreterFrameExpressionStackDirection() { return -1; } + + // top of expression stack + public Address addressOfInterpreterFrameTOS() { + return getSP(); + } + + /** Expression stack from top down */ + public Address addressOfInterpreterFrameTOSAt(int slot) { + return addressOfInterpreterFrameTOS().addOffsetTo(slot * VM.getVM().getAddressSize()); + } + + public Address getInterpreterFrameSenderSP() { + if (Assert.ASSERTS_ENABLED) { + Assert.that(isInterpretedFrame(), "interpreted frame expected"); + } + return addressOfStackSlot(INTERPRETER_FRAME_SENDER_SP_OFFSET).getAddressAt(0); + } + + // Monitors + public BasicObjectLock interpreterFrameMonitorBegin() { + return new BasicObjectLock(addressOfStackSlot(INTERPRETER_FRAME_MONITOR_BLOCK_BOTTOM_OFFSET)); + } + + public BasicObjectLock interpreterFrameMonitorEnd() { + Address result = addressOfStackSlot(INTERPRETER_FRAME_MONITOR_BLOCK_TOP_OFFSET).getAddressAt(0); + if (Assert.ASSERTS_ENABLED) { + // make sure the pointer points inside the frame + Assert.that(AddressOps.gt(getFP(), result), "result must < than frame pointer"); + Assert.that(AddressOps.lte(getSP(), result), "result must >= than stack pointer"); + } + return new BasicObjectLock(result); + } + + public int interpreterFrameMonitorSize() { + return BasicObjectLock.size(); + } + + // Method + public Address addressOfInterpreterFrameMethod() { + return addressOfStackSlot(INTERPRETER_FRAME_METHOD_OFFSET); + } + + // Constant pool cache + public Address addressOfInterpreterFrameCPCache() { + return addressOfStackSlot(INTERPRETER_FRAME_CACHE_OFFSET); + } + + // Entry frames + public JavaCallWrapper getEntryFrameCallWrapper() { + return new PPC64JavaCallWrapper(addressOfStackSlot(ENTRY_FRAME_CALL_WRAPPER_OFFSET).getAddressAt(0)); + } + + protected Address addressOfSavedOopResult() { + // offset is 2 for compiler2 and 3 for compiler1 + return getSP().addOffsetTo((VM.getVM().isClientCompiler() ? 2 : 3) * + VM.getVM().getAddressSize()); + } + + protected Address addressOfSavedReceiver() { + return getSP().addOffsetTo(-4 * VM.getVM().getAddressSize()); + } + + private void dumpStack() { + if (getFP() != null) { + for (Address addr = getSP().addOffsetTo(-5 * VM.getVM().getAddressSize()); + AddressOps.lte(addr, getFP().addOffsetTo(5 * VM.getVM().getAddressSize())); + addr = addr.addOffsetTo(VM.getVM().getAddressSize())) { + System.out.println(addr + ": " + addr.getAddressAt(0)); + } + } else { + for (Address addr = getSP().addOffsetTo(-5 * VM.getVM().getAddressSize()); + AddressOps.lte(addr, getSP().addOffsetTo(20 * VM.getVM().getAddressSize())); + addr = addr.addOffsetTo(VM.getVM().getAddressSize())) { + System.out.println(addr + ": " + addr.getAddressAt(0)); + } + } + } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java @@ -0,0 +1,43 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.runtime.ppc64; + +import java.util.*; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.runtime.*; + +public class PPC64JavaCallWrapper extends JavaCallWrapper { + + public PPC64JavaCallWrapper(Address addr) { + super(addr); + } + + public Address getLastJavaFP() { + return null; + } + +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java =================================================================== --- /dev/null +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java @@ -0,0 +1,51 @@ +/* + * Copyright (c) 20014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.runtime.ppc64; + +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.runtime.*; + +public class PPC64RegisterMap extends RegisterMap { + + /** This is the only public constructor */ + public PPC64RegisterMap(JavaThread thread, boolean updateMap) { + super(thread, updateMap); + } + + protected PPC64RegisterMap(RegisterMap map) { + super(map); + } + + public Object clone() { + PPC64RegisterMap retval = new PPC64RegisterMap(this); + return retval; + } + + // no PD state to clear or copy: + protected void clearPD() {} + protected void initializePD() {} + protected void initializeFromPD(RegisterMap map) {} + protected Address getLocationPD(VMReg reg) { return null; } +} Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java =================================================================== --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java @@ -34,6 +34,10 @@ public class MachineDescriptionPPC64 ext } public boolean isBigEndian() { - return true; + String endian = System.getProperty("sun.cpu.endian"); + if (endian.equals("big")) + return true; + else + return false; } } From volker.simonis at gmail.com Fri Nov 14 19:23:59 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 14 Nov 2014 20:23:59 +0100 Subject: PowerPC: core file option not available with serviceability tools In-Reply-To: <5466352B.3010504@us.ibm.com> References: <53B5A92A.401@us.ibm.com> <53BD477D.2090107@us.ibm.com> <5429E046.8030003@us.ibm.com> <5433EC3E.1010800@us.ibm.com> <5466352B.3010504@us.ibm.com> Message-ID: On Fri, Nov 14, 2014 at 6:00 PM, Maynard Johnson wrote: > On 10/07/2014 08:35 AM, Maynard Johnson wrote: >> On 10/07/2014 03:58 AM, Volker Simonis wrote: >>> Hi Maynard, >>> >>> I'm now back from JavaOne and can look at this issue. Could you please >>> share your current implementation so I can reproduce your problem more >>> easily. >> See attachment. The two patches in the attached tar file apply to a jdk9-dev snapshot from July. I haven't even tried forward-porting to current upstream code, so I don't know how well they would apply. >>> >>> By the way, you can find the ppc frame layout description of all the >>> different frame types (native, interpreted, compiled) in >>> /hotspot/src/cpu/ppc/vm/frame_ppc.hpp. The different frame::sender() >>> implementations (in frame_x86.cpp, frame_ppc.cpp, ..) contain all the >> Yes, I've been studying those files, but I freely admit I don't have a good grasp of the code yet. >>> gory details about how to walk a frame. That's what you have to >>> implement in Java in order to get a full stack trace from the >>> serviceability tools. On x86 the frame pointer (i.e. the ebp register >>> points to the last frame pointer while (frame pointer - 1) points to >>> the return pc. >> Ummm . . . Stack addresses grow downward, and I was under the impression 'return pc' was the word on the stack directly before the ebp, which would mean return pc is at 'frame pointer + 1'. Or am I off base here? Nevertheless, my question below concerns the "pc", not the "return pc". Perhaps I'm misunderstanding "pc" in this context; but even so, the x86 code still seems wrong: >> >> this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()); >> >> If, in fact, 'this.pc' is supposed to represent 'return pc' in this context, then I would think the code should be: >> >> this.pc = raw_fp.getAddressAt(VM.getVM().getAddressSize()); >> >> I hope you can help set me on the right track. As you can see, I'm lost in the weeds right now. :-) > Hi, Volker, > I presume you've been too busy to help out with this, so I had another go at it, and was able to make > quite a bit of progress. The main issue was that I was unwittingly building my openJDK source > with the "--with-jvm-interpreter=cpp" configure option! Once I discovered that and removed that option, > the stack started making sense, since my new ppc64 agent's reflection of the stack assumes the use > of the template interpreter (as does the x86 agent code which the ppc64 stuff is based on). > > So now I have jmap, jsadebugd, and jstack working for ppc64 on both big endian and little endian -- almost. > There are a couple issues yet with jstack that I'm stuck on. I will post the patches as an RFC > and document those issues. If you could find time to review the patches and perhaps help out with > the open issues, I would appreciate it. Thanks! > Hi Maynard, sorry, I was quite busy indeed. I'm really happy that you've made some progress in the meantime and I promise to look at your changes next week. Thank you and best regards, Volker > -Maynard >> >> -Maynard >>> >>> Regards, >>> Volker >>> >>> >>> On Tue, Sep 30, 2014 at 12:42 AM, Maynard Johnson wrote: >>>> On 07/09/2014 12:38 PM, Volker Simonis wrote: >>>>> On Wed, Jul 9, 2014 at 3:45 PM, Maynard Johnson wrote: >>>>>> On 07/04/2014 10:59 AM, Volker Simonis wrote: >>>>>>> Hi Maynard, >>>>>>> >>>>>>> we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and >>>>>>> AIX (we have other proprietary servicibility tools). Because of that >>>>>>> (and because SA isn't specified by the SE specification) porting the >>>>>>> SA agent was no top priority until now. But there are no technical >>>>>>> reasons why it should not work (it's just a lack of resources). Of >>>>>>> course contributions are always highly welcome:) >>>>>>> >>>>>>> That said, the SA agent library and jar file actually gets build. If >>>>>>> you do a complete build you'll find them under: >>>>>>> >>>>>>> hotspot/linux_ppc64_compiler2/generated/sa-jdi.jar >>>>>>> hotspot/linux_ppc64_compiler2/{product,fastdebug,debug}/libsaproc.so >>>>>>> >>>>>>> in the build directory. They are just not copied into the jdk >>>>>>> workspace and the created images because they don't work out of the >>>>>>> box. >>>>>>> >>>>>>> The following two patches for the jdk9 top-level and hotspot >>>>>>> repositories respectively should fix the build such that the agent >>>>>>> files will be correctly copied into the images. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/sa_toplevel >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/sa_hotspot/ >>>>>>> >>>>>>> They will get you to the point where for example 'jstack' will run up >>>>>>> to the following point: >>>>>> Ok, great. This should be enough to get me started. I should have time to begin on this later this week or early next week. >>>>> >>>>> Hi Maynard, >>>>> >>>>> great to welcome you in the ppc64 porting team:) >>>>> >>>>>> I may come knocking at your "door" for some occasional help, but I'll try to keep that to a minimum. >>>> Hi, Volker. Knock, knock. :-) >>>> I was preoccupied for a while this summer rolling out the latest release of oprofile (for which I'm the maintainer), but am now coming back to this task. I've implemented what I believe are all of the necessary ppc64-specific Java files to enable the jstack and jmap tools to work on core files. I've also updated hotspot/agent/src/os/linux/LinuxDebuggerLocal.c to implement the accumulation of register data on ppc64 vi ptrace. But now I've run into a problem I need help with. >>>> >>>> When I run jstack on my POWER7 system, it gets stuck in a loop in sun.jvm.hotspot.tools.StackTrace::run. There's an inner for-loop there where cur.getLastJavaVFrameDbg() is called ('cur' is a JavaThread). For the first JavaThread, we do return from getLastJavaVFrameDbg(), just as we do when running jstack on my Intel laptop. But for the second JavaThread, we never return from getLastJavaVFrameDbg() on ppc64. I believe the root of the problem is in my new sun.jvm.hotspot.runtime.ppc64.PPC64Frame class. The getLastJavaVFrameDbg method calls getCurrentFrameGuess, which is implemented in the new sun.jvm.hotspot.runtime.linux_ppc64.LinuxPPC64JavaThreadPDAccess class. In both ppc64 and x86, this first level xxxCurrentFrameGuess object is instantiated with a 'pc' value of null, so getCurrentFrameGuess then new's up a xxxFrame object, passing in the SP and FP, but no PC. The implementation of the PPC64Frame(Address,Address) constructor is currently identical to the X86Frame ! > c! >> ons! >>>> tructor, b >>>> ut is almost certainly incorrect. In this constructor, the 'pc' is set as follows: >>>> this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()); >>>> >>>> This works fine on X86, but not on ppc64. But I'm not understanding how this even works on X86. From what I understand, the data below the stack pointer on X86 is the "red zone". How is that being used as a pc? But more importantly, do you know how I can ascertain what the 'pc' value should be for ppc64? >>>> >>>> Thanks in advance for any assistance you can give. >>>> >>>> -Maynard >>>> >>>>> >>>>> Please feel free to ask any questions. The OpenJDK project and >>>>> especially the HotSpot part are known to take some getting used to. >>>>> >>>>>> I was wondering if a bug report should be opened in JBS, just to record that the issue is being worked. Thoughts? >>>>> >>>>> I have opened "8049715: PPC64: First steps to enable SA on >>>>> Linux/PPC64" (https://bugs.openjdk.java.net/browse/JDK-8049715) for >>>>> the patch which I sent you with the last mail. I've already sent out >>>>> webrevs for that change and hopefully it will be fixed within the next >>>>> few days. >>>>> >>>>> For the actual port of the ppc64-specific stuff I opened bug "8049716 >>>>> PPC64: Implement SA on Linux/PPC64" >>>>> (https://bugs.openjdk.java.net/browse/JDK-8049716). I can also help >>>>> with hosting the webrevs, once you have a running version. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>>> >>>>>> -Maynard >>>>>>> >>>>>>>> images/j2sdk-image/bin/jstack ./jdk/bin/java core.13547 >>>>>>> Attaching to core core.13547 from executable ./jdk/bin/java, please wait... >>>>>>> WARNING: Hotspot VM version >>>>>>> 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 does not match with >>>>>>> SA version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00. You may >>>>>>> see unexpected results. >>>>>>> Debugger attached successfully. >>>>>>> Server compiler detected. >>>>>>> JVM version is 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 >>>>>>> Deadlock Detection: >>>>>>> >>>>>>> Exception in thread "main" java.lang.reflect.InvocationTargetException >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>> at java.lang.reflect.Method.invoke(Method.java:484) >>>>>>> at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) >>>>>>> at sun.tools.jstack.JStack.main(JStack.java:106) >>>>>>> Caused by: java.lang.ExceptionInInitializerError >>>>>>> at sun.jvm.hotspot.runtime.VM.getThreads(VM.java:610) >>>>>>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:54) >>>>>>> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >>>>>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) >>>>>>> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >>>>>>> at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) >>>>>>> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>> at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) >>>>>>> ... 6 more >>>>>>> Caused by: java.lang.RuntimeException: OS/CPU combination linux/ppc64 >>>>>>> not yet supported >>>>>>> at sun.jvm.hotspot.runtime.Threads.initialize(Threads.java:97) >>>>>>> at sun.jvm.hotspot.runtime.Threads.access$000(Threads.java:42) >>>>>>> at sun.jvm.hotspot.runtime.Threads$1.update(Threads.java:52) >>>>>>> at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) >>>>>>> at sun.jvm.hotspot.runtime.Threads.(Threads.java:50) >>>>>>> ... 16 more >>>>>>> >>>>>>> And that's the point where I was saying that "contributions are always >>>>>>> highly welcome:)" >>>>>>> >>>>>>> Now all the Linux/PPC64 specific class under >>>>>>> hotspot/agent/src/share/classes/ would have to be implemented (e.g. >>>>>>> sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess). Are you >>>>>>> interested in contributing to this project? >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> PS: I cc-ed serviceability-dev because I remember that they started a >>>>>>> poll a while ago about who is using the SA tools. I'm therefore not >>>>>>> quite sure what's the current status and what are the future plan for >>>>>>> these libraries. >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 3, 2014 at 9:04 PM, Maynard Johnson wrote: >>>>>>>> Hi, all, >>>>>>>> On my Intel laptop, I note that certain jdk9 serviceability tools -- jstack, jmap, jsadebugd -- have an option to pass a core file instead of a process ID; for example: >>>>>>>> >>>>>>>> $ jstack -h >>>>>>>> Usage: >>>>>>>> jstack [-l] >>>>>>>> (to connect to running process) >>>>>>>> jstack -F [-m] [-l] >>>>>>>> (to connect to a hung process) >>>>>>>> jstack [-m] [-l] >>>>>>>> (to connect to a core file) >>>>>>>> jstack [-m] [-l] [server_id@] >>>>>>>> (to connect to a remote debug server) >>>>>>>> >>>>>>>> But on my PowerLinux box, the core file option is missing from the usage output. I see that jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStack.java requires the existence of sun.jvm.hotspot.tools.JStack for the core file option to be made available. On my Intel system, the sun.jvm.hotspot.tools.JStack class is packaged in sa-jdi.jar in /jvm/openjdk-1.9.0-internal/lib/. But the sa-jdi.jar is missing on PowerPC. Is there a technical reason for this or is it an oversight? >>>>>>>> >>>>>>>> The jsadebugd tool does not run at all on PowerLinux; it gets the following error: >>>>>>>> >>>>>>>> Error: Could not find or load main class sun.jvm.hotspot.jdi.SADebugServer >>>>>>>> >>>>>>>> On my Intel system, the SADebugServer class is packaged in the sa-jdi.jar mentioned above. >>>>>>>> >>>>>>>> I've spent the past day or so looking at makefiles until I'm cross-eyed, but haven't yet found where the issue might be. Any tips would be appreciated. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> -Maynard >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Fri Nov 14 20:01:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 Nov 2014 12:01:26 -0800 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <54664554.4060309@us.ibm.com> References: <54664554.4060309@us.ibm.com> Message-ID: <54665F96.9030905@oracle.com> Volker or Goetz, can you help Maynard to create bugs and prepare webrevs on cr.openjdk for these 3 changes? Thanks, Vladimir On 11/14/14 10:09 AM, Maynard Johnson wrote: > When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: > > OS/CPU combination linux/ppc64 not yet supported > > I will post a patch set that adds this support. The patch set consists of the following patches: > > PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files > > PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files > > These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. > > ------------ > Open issues: > ------------ > 1) The jstack tool does not print a stack entry for the 'main()' method of the Java > workload (attached) under test. For example: > > (Note: Addresses and method signatures elided for brevity.) > > Thread 24358: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > ==> (Expect an entry for test.main() here) > > 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: > > Thread 24779: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) > - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) > > Again, the 'test.main' method is missing, but there's also the anomaly of the > test.run_test' method showing up twice in the stack, implying that it is called > by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test > does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- > but these are totally distinct call graphs. Somehow, we are seeing these two distinct > stacks in the core file, which seems impossible. > > --------- > > Any help offered on these two open issues would be greatly appreciated. > > -Maynard > From dmitry.samersoff at oracle.com Fri Nov 14 20:11:51 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Nov 2014 23:11:51 +0300 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <54664554.4060309@us.ibm.com> References: <54664554.4060309@us.ibm.com> Message-ID: <54666207.9090701@oracle.com> Maynard, Thank you for this contribution. Could I ask you to prepare a webrev? http://openjdk.java.net/guide/webrevHelp.html -Dmitry On 2014-11-14 21:09, Maynard Johnson wrote: > When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: > > OS/CPU combination linux/ppc64 not yet supported > > I will post a patch set that adds this support. The patch set consists of the following patches: > > PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files > > PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files > > These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. > > ------------ > Open issues: > ------------ > 1) The jstack tool does not print a stack entry for the 'main()' method of the Java > workload (attached) under test. For example: > > (Note: Addresses and method signatures elided for brevity.) > > Thread 24358: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > ==> (Expect an entry for test.main() here) > > 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: > > Thread 24779: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) > - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) > > Again, the 'test.main' method is missing, but there's also the anomaly of the > test.run_test' method showing up twice in the stack, implying that it is called > by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test > does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- > but these are totally distinct call graphs. Somehow, we are seeing these two distinct > stacks in the core file, which seems impossible. > > --------- > > Any help offered on these two open issues would be greatly appreciated. > > -Maynard > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Fri Nov 14 21:30:11 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 14 Nov 2014 14:30:11 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5464F600.7040601@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> Message-ID: <54667463.7000405@oracle.com> > I presume I don't need to sent out another webrev... I have to change my mind on this because this fix needs to be backported to JDK8u-hs-dev. Here's the updated JDK9 webrev: http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/ And here's the JDK8u-hs-dev backport: http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/ Because of improvements to the JDK9 makefiles, a bunch of the anchor text has changed. The best way to sanity check the backport is to download the two patch files and look at them in your favorite diff tool: http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch I need just one sanity check on the backport... Thanks, in advance, for any comments, questions or suggestions. Dan On 11/13/14 11:18 AM, Daniel D. Daugherty wrote: > Magnus, > > Thanks for the review! > > Replies embedded below... > > On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >> >> ... but you're only deleting the make files? > > Good catch! Looks like when I resurrected this fix from my JDK8 > queue I missed a couple of deletes. > > >> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c >> could be deleted as well, right? > > Yes, these should be deleted and I'll do that in this fix. > Since these are two deletes of files that can no longer be > built anyway, I presume I don't need to sent out another > webrev... > > >> >> Good idea for the fix, anyway. I opened >> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >> similar solution in configure. > > Sounds good to me. > > Dan > > >> >> /Magnus On 11/10/14 5:00 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a Solaris Full Debug Symbols (FDS) fix ready for review. > Yes, it is a small fix, but it is in Makefiles so feel free to > run screaming from the room... :-) On the plus side the fix does > delete two work around source files (Coleen would say that's a > Good Thing (TM)!) > > The fix is to detect the version of GNU objcopy that is being > used on the machine and only enable Full Debug Symbols when that > version is 2.21.1 or newer. If you don't have the right version, > then the build drops back to pre-FDS build configs with a message > like this: > > WARNING: /usr/sfw/bin/gobjcopy --version info: > WARNING: GNU objcopy 2.15 > WARNING: an objcopy version of 2.21.1 or newer is needed to create valid .debuginfo files. > WARNING: ignoring above objcopy command. > WARNING: patch 149063-01 or newer contains the correct Solaris 10 SPARC version. > WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 version. > WARNING: Solaris 11 Update 1 contains the correct version. > INFO: no objcopy cmd found so cannot create .debuginfo files. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 > > This work is being tracked by the following bug IDs: > > JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC > https://bugs.openjdk.java.net/browse/JDK-8033602 > > JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on Solaris X86 > https://bugs.openjdk.java.net/browse/JDK-8034005 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ > > Testing: > > - JPRT test jobs to verify that the current JPRT Solaris hosts > are happy > - local builds on my Solaris 10 X86 machine to verify that the > wrong version of GNU objcopy is caught > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From volker.simonis at gmail.com Fri Nov 14 23:09:34 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 15 Nov 2014 00:09:34 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <54665F96.9030905@oracle.com> References: <54664554.4060309@us.ibm.com> <54665F96.9030905@oracle.com> Message-ID: On Friday, November 14, 2014, Vladimir Kozlov wrote: > Volker or Goetz, can you help Maynard to create bugs and prepare webrevs > on cr.openjdk for these 3 changes? > > I will create the bugs and have look at the changes on monday. Regards, Volker > Thanks, > Vladimir > > On 11/14/14 10:09 AM, Maynard Johnson wrote: > >> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core >> file, they fail with the following runtime exception: >> >> OS/CPU combination linux/ppc64 not yet supported >> >> I will post a patch set that adds this support. The patch set consists >> of the following patches: >> >> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA >> with core files >> >> PATCH 2/2: New PPC64 class files (and updates to generic files) to >> support linux/ppc64 Hotspot SA with core files >> >> These two patches apply cleanly to a November 13 pull of the jdk9-dev >> upstream sources. >> >> ------------ >> Open issues: >> ------------ >> 1) The jstack tool does not print a stack entry for the 'main()' >> method of the Java >> workload (attached) under test. For example: >> >> (Note: Addresses and method signatures elided for brevity.) >> >> Thread 24358: (state = IN_JAVA, current Java SP = null >> ) >> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., >> Method*=... (Compiled frame; ... imprecise) >> - test.run_test() @bci=80, line=33, pc=..., Method*=... >> (Compiled frame) >> ==> (Expect an entry for test.main() here) >> >> 2) The jstack tool sometimes prints what appears to be two complete >> stacks for the Java workload. For example: >> >> Thread 24779: (state = IN_JAVA, current Java SP = null >> ) >> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., >> Method*=... (Compiled frame; ... imprecise) >> - test.run_test() @bci=80, line=33, pc=..., Method*=... >> (Compiled frame) >> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... >> (Compiled frame) >> - test.run_test() @bci=92, line=34, pc=..., Method*=... >> (Compiled frame) >> >> Again, the 'test.main' method is missing, but there's also the >> anomaly of the >> test.run_test' method showing up twice in the stack, implying >> that it is called >> by 'test.get_my_chars' at line 15. But that that is not >> accurate. In fact, run_test >> does call String.getChars at line 33 *and* it calls >> test.get_my_chars at line 34 -- >> but these are totally distinct call graphs. Somehow, we are >> seeing these two distinct >> stacks in the core file, which seems impossible. >> >> --------- >> >> Any help offered on these two open issues would be greatly appreciated. >> >> -Maynard >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Nov 14 23:22:23 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 14 Nov 2014 16:22:23 -0700 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <5465F711.9090605@oracle.com> References: <5465F711.9090605@oracle.com> Message-ID: <54668EAF.9070807@oracle.com> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: > Hello! > > The recent fix for JDK-8059533 ((process) Make exiting process wait > for exiting threads [win]) caused the warning message to be printed in > some test environments: > ----------- > os_windows.cpp:3844 is in the newly updated > os::win32::exit_process_or_thread(Ept what, int exit_code) > ----------- > > This has been observed with debug builds on highly loaded systems. > > > To address the issue it is proposed to do three things: > 1) increase the timeout for debug builds, > 2) increase the maximum number of the thread handles to be stored, > 3) rise the priority of the exiting threads, if we need to wait for them. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 > WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ src/os/windows/vm/os_windows.cpp line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) Instead of NOT_DEBUG can you use PRODUCT_ONLY? Instead of DEBUG_ONLY can you used NOT_PRODUCT? That uses the smaller value for only one build config (PRODUCT). line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) /*1 sec in product, 4 sec in debug*/ Instead of NOT_DEBUG can you use PRODUCT_ONLY? Instead of DEBUG_ONLY can you used NOT_PRODUCT? Please add spaces between the comment delimiters and the comment text. That uses the smaller timeout for only one build config (PRODUCT). line 3836 // Rise the priority... Typo: 'Rise' -> 'Raise' About the general idea of raising the exiting thread's priority, if the exiting thread is looping in some Win* OS code after this point, will raising the priority make the machine unusable? Dan > > The fix was tested on all available platforms, with the hotspot > testset. No failures. > > Sincerely yours, > Ivan > From dmitry.samersoff at oracle.com Sat Nov 15 18:57:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 15 Nov 2014 21:57:10 +0300 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <54667463.7000405@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> <54667463.7000405@oracle.com> Message-ID: <5467A206.7020105@oracle.com> Dan, The fix looks good for me. -Dmitry On 2014-11-15 00:30, Daniel D. Daugherty wrote: >> I presume I don't need to sent out another webrev... > > I have to change my mind on this because this fix needs to be > backported to JDK8u-hs-dev. > > Here's the updated JDK9 webrev: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/ > > And here's the JDK8u-hs-dev backport: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/ > > Because of improvements to the JDK9 makefiles, a bunch of the > anchor text has changed. The best way to sanity check the backport > is to download the two patch files and look at them in your favorite > diff tool: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch > > > I need just one sanity check on the backport... > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > > > On 11/13/14 11:18 AM, Daniel D. Daugherty wrote: >> Magnus, >> >> Thanks for the review! >> >> Replies embedded below... >> >> On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >>> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>>> Yes, it is a small fix, but it is in Makefiles so feel free to >>>> run screaming from the room... :-) On the plus side the fix does >>>> delete two work around source files (Coleen would say that's a >>>> Good Thing (TM)!) >>> >>> ... but you're only deleting the make files? >> >> Good catch! Looks like when I resurrected this fix from my JDK8 >> queue I missed a couple of deletes. >> >> >>> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >>> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c >>> could be deleted as well, right? >> >> Yes, these should be deleted and I'll do that in this fix. >> Since these are two deletes of files that can no longer be >> built anyway, I presume I don't need to sent out another >> webrev... >> >> >>> >>> Good idea for the fix, anyway. I opened >>> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >>> similar solution in configure. >> >> Sounds good to me. >> >> Dan >> >> >>> >>> /Magnus > > > > On 11/10/14 5:00 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create > valid .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 > SPARC version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Sat Nov 15 19:06:59 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 15 Nov 2014 12:06:59 -0700 Subject: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005 In-Reply-To: <5467A206.7020105@oracle.com> References: <546151A9.1080100@oracle.com> <5464C3E6.5000309@oracle.com> <5464F600.7040601@oracle.com> <54667463.7000405@oracle.com> <5467A206.7020105@oracle.com> Message-ID: <5467A453.8020001@oracle.com> Thanks! Dan On 11/15/14 11:57 AM, Dmitry Samersoff wrote: > Dan, > > The fix looks good for me. > > -Dmitry > > > On 2014-11-15 00:30, Daniel D. Daugherty wrote: >>> I presume I don't need to sent out another webrev... >> I have to change my mind on this because this fix needs to be >> backported to JDK8u-hs-dev. >> >> Here's the updated JDK9 webrev: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/ >> >> And here's the JDK8u-hs-dev backport: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/ >> >> Because of improvements to the JDK9 makefiles, a bunch of the >> anchor text has changed. The best way to sanity check the backport >> is to download the two patch files and look at them in your favorite >> diff tool: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch >> >> >> I need just one sanity check on the backport... >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> >> >> On 11/13/14 11:18 AM, Daniel D. Daugherty wrote: >>> Magnus, >>> >>> Thanks for the review! >>> >>> Replies embedded below... >>> >>> On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >>>> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>>>> Yes, it is a small fix, but it is in Makefiles so feel free to >>>>> run screaming from the room... :-) On the plus side the fix does >>>>> delete two work around source files (Coleen would say that's a >>>>> Good Thing (TM)!) >>>> ... but you're only deleting the make files? >>> Good catch! Looks like when I resurrected this fix from my JDK8 >>> queue I missed a couple of deletes. >>> >>> >>>> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >>>> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c >>>> could be deleted as well, right? >>> Yes, these should be deleted and I'll do that in this fix. >>> Since these are two deletes of files that can no longer be >>> built anyway, I presume I don't need to sent out another >>> webrev... >>> >>> >>>> Good idea for the fix, anyway. I opened >>>> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >>>> similar solution in configure. >>> Sounds good to me. >>> >>> Dan >>> >>> >>>> /Magnus >> >> >> On 11/10/14 5:00 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>> Yes, it is a small fix, but it is in Makefiles so feel free to >>> run screaming from the room... :-) On the plus side the fix does >>> delete two work around source files (Coleen would say that's a >>> Good Thing (TM)!) >>> >>> The fix is to detect the version of GNU objcopy that is being >>> used on the machine and only enable Full Debug Symbols when that >>> version is 2.21.1 or newer. If you don't have the right version, >>> then the build drops back to pre-FDS build configs with a message >>> like this: >>> >>> WARNING: /usr/sfw/bin/gobjcopy --version info: >>> WARNING: GNU objcopy 2.15 >>> WARNING: an objcopy version of 2.21.1 or newer is needed to create >> valid .debuginfo files. >>> WARNING: ignoring above objcopy command. >>> WARNING: patch 149063-01 or newer contains the correct Solaris 10 >> SPARC version. >>> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 >> version. >>> WARNING: Solaris 11 Update 1 contains the correct version. >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >>> >>> This work is being tracked by the following bug IDs: >>> >>> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >>> https://bugs.openjdk.java.net/browse/JDK-8033602 >>> >>> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on >> Solaris X86 >>> https://bugs.openjdk.java.net/browse/JDK-8034005 >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >>> >>> Testing: >>> >>> - JPRT test jobs to verify that the current JPRT Solaris hosts >>> are happy >>> - local builds on my Solaris 10 X86 machine to verify that the >>> wrong version of GNU objcopy is caught >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan > From ivan.gerasimov at oracle.com Sun Nov 16 21:23:43 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 17 Nov 2014 00:23:43 +0300 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <54668EAF.9070807@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> Message-ID: <546915DF.7080106@oracle.com> Thank you Daniel! Please find the updated webrev with your suggestions incorporated here: http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ Concerning the thread priority: If the application is of NORMAL_PRIORITY_CLASS, then setting the thread's priority level to THREAD_PRIORITY_HIGHEST will result in its priority value to be only 10 (of maximum 31). http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx And if the process is HIGH_PRIORITY_CLASS, then the tread with the HIGHEST priority level will have priority value == 15 of 31. I believe, it should not be too much, and the machine will not become busy with only those closing threads. However, I hope it would be enough to make them complete faster than other threads of the NORMAL priority level withing the same application. Sincerely yours, Ivan On 15.11.2014 2:22, Daniel D. Daugherty wrote: > On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >> Hello! >> >> The recent fix for JDK-8059533 ((process) Make exiting process wait >> for exiting threads [win]) caused the warning message to be printed >> in some test environments: >> ----------- >> os_windows.cpp:3844 is in the newly updated >> os::win32::exit_process_or_thread(Ept what, int exit_code) >> ----------- >> >> This has been observed with debug builds on highly loaded systems. >> >> >> To address the issue it is proposed to do three things: >> 1) increase the timeout for debug builds, >> 2) increase the maximum number of the thread handles to be stored, >> 3) rise the priority of the exiting threads, if we need to wait for >> them. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ > > src/os/windows/vm/os_windows.cpp > > line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) > Instead of NOT_DEBUG can you use PRODUCT_ONLY? > Instead of DEBUG_ONLY can you used NOT_PRODUCT? > > That uses the smaller value for only one build config (PRODUCT). > > line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) > /*1 sec in product, 4 sec in debug*/ > Instead of NOT_DEBUG can you use PRODUCT_ONLY? > Instead of DEBUG_ONLY can you used NOT_PRODUCT? > Please add spaces between the comment delimiters and the comment > text. > > That uses the smaller timeout for only one build config (PRODUCT). > > line 3836 // Rise the priority... > Typo: 'Rise' -> 'Raise' > > About the general idea of raising the exiting thread's priority, > if the exiting thread is looping in some Win* OS code after this > point, will raising the priority make the machine unusable? > > Dan > > >> >> The fix was tested on all available platforms, with the hotspot >> testset. No failures. >> >> Sincerely yours, >> Ivan >> > > > From david.holmes at oracle.com Mon Nov 17 06:40:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Nov 2014 16:40:05 +1000 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <546915DF.7080106@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> Message-ID: <54699845.5010901@oracle.com> On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: > Thank you Daniel! > > Please find the updated webrev with your suggestions incorporated here: > http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ > > Concerning the thread priority: If the application is of > NORMAL_PRIORITY_CLASS, then setting the thread's priority level to > THREAD_PRIORITY_HIGHEST will result in its priority value to be only 10 > (of maximum 31). > http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx > > > And if the process is HIGH_PRIORITY_CLASS, then the tread with the > HIGHEST priority level will have priority value == 15 of 31. > > I believe, it should not be too much, and the machine will not become > busy with only those closing threads. > However, I hope it would be enough to make them complete faster than > other threads of the NORMAL priority level withing the same application. I don't think this is necessary or desirable. Under normal usage we're giving priority to exiting threads and that may disrupt the usual scheduling patterns that applications see. You may posit that it is "harmless" but we can't say that for sure. Nor can we actually know that this will help with this particular bug. I would not add in this new code. David > Sincerely yours, > Ivan > > > On 15.11.2014 2:22, Daniel D. Daugherty wrote: >> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>> for exiting threads [win]) caused the warning message to be printed >>> in some test environments: >>> ----------- >>> os_windows.cpp:3844 is in the newly updated >>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>> ----------- >>> >>> This has been observed with debug builds on highly loaded systems. >>> >>> >>> To address the issue it is proposed to do three things: >>> 1) increase the timeout for debug builds, >>> 2) increase the maximum number of the thread handles to be stored, >>> 3) rise the priority of the exiting threads, if we need to wait for >>> them. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> >> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >> >> That uses the smaller value for only one build config (PRODUCT). >> >> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) >> /*1 sec in product, 4 sec in debug*/ >> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >> Please add spaces between the comment delimiters and the comment >> text. >> >> That uses the smaller timeout for only one build config (PRODUCT). >> >> line 3836 // Rise the priority... >> Typo: 'Rise' -> 'Raise' >> >> About the general idea of raising the exiting thread's priority, >> if the exiting thread is looping in some Win* OS code after this >> point, will raising the priority make the machine unusable? >> >> Dan >> >> >>> >>> The fix was tested on all available platforms, with the hotspot >>> testset. No failures. >>> >>> Sincerely yours, >>> Ivan >>> >> >> >> > From markus.gronlund at oracle.com Mon Nov 17 08:33:45 2014 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Mon, 17 Nov 2014 00:33:45 -0800 (PST) Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <54699845.5010901@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> Message-ID: I agree with David. The side effects will be unknown and very hard to debug. Is there another way to accomplish the results without manipulating base services? Thanks Markus -----Original Message----- From: David Holmes Sent: den 17 november 2014 07:40 To: Ivan Gerasimov; Daniel Daugherty Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: > Thank you Daniel! > > Please find the updated webrev with your suggestions incorporated here: > http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ > > Concerning the thread priority: If the application is of > NORMAL_PRIORITY_CLASS, then setting the thread's priority level to > THREAD_PRIORITY_HIGHEST will result in its priority value to be only > 10 (of maximum 31). > http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs. > 85).aspx > > > And if the process is HIGH_PRIORITY_CLASS, then the tread with the > HIGHEST priority level will have priority value == 15 of 31. > > I believe, it should not be too much, and the machine will not become > busy with only those closing threads. > However, I hope it would be enough to make them complete faster than > other threads of the NORMAL priority level withing the same application. I don't think this is necessary or desirable. Under normal usage we're giving priority to exiting threads and that may disrupt the usual scheduling patterns that applications see. You may posit that it is "harmless" but we can't say that for sure. Nor can we actually know that this will help with this particular bug. I would not add in this new code. David > Sincerely yours, > Ivan > > > On 15.11.2014 2:22, Daniel D. Daugherty wrote: >> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>> for exiting threads [win]) caused the warning message to be printed >>> in some test environments: >>> ----------- >>> os_windows.cpp:3844 is in the newly updated >>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>> ----------- >>> >>> This has been observed with debug builds on highly loaded systems. >>> >>> >>> To address the issue it is proposed to do three things: >>> 1) increase the timeout for debug builds, >>> 2) increase the maximum number of the thread handles to be stored, >>> 3) rise the priority of the exiting threads, if we need to wait for >>> them. >>> >>> Would you please help review the fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> >> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >> >> That uses the smaller value for only one build config (PRODUCT). >> >> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) >> /*1 sec in product, 4 sec in debug*/ >> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >> Please add spaces between the comment delimiters and the comment >> text. >> >> That uses the smaller timeout for only one build config (PRODUCT). >> >> line 3836 // Rise the priority... >> Typo: 'Rise' -> 'Raise' >> >> About the general idea of raising the exiting thread's priority, >> if the exiting thread is looping in some Win* OS code after this >> point, will raising the priority make the machine unusable? >> >> Dan >> >> >>> >>> The fix was tested on all available platforms, with the hotspot >>> testset. No failures. >>> >>> Sincerely yours, >>> Ivan >>> >> >> >> > From ivan.gerasimov at oracle.com Mon Nov 17 09:00:16 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 17 Nov 2014 12:00:16 +0300 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <54699845.5010901@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> Message-ID: <5469B920.4040300@oracle.com> Thanks David! On 17.11.2014 9:40, David Holmes wrote: > On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >> Thank you Daniel! >> >> Please find the updated webrev with your suggestions incorporated here: >> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >> >> Concerning the thread priority: If the application is of >> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >> THREAD_PRIORITY_HIGHEST will result in its priority value to be only 10 >> (of maximum 31). >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx >> >> >> >> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >> HIGHEST priority level will have priority value == 15 of 31. >> >> I believe, it should not be too much, and the machine will not become >> busy with only those closing threads. >> However, I hope it would be enough to make them complete faster than >> other threads of the NORMAL priority level withing the same application. > > I don't think this is necessary or desirable. Under normal usage we're > giving priority to exiting threads and that may disrupt the usual > scheduling patterns that applications see. You may posit that it is > "harmless" but we can't say that for sure. Nor can we actually know > that this will help with this particular bug. I would not add in this > new code. > There are two places where I put adjusting the thread's priority: 1) We've the array of handles filled up. If we're found in this code branch, it'll mean that unfortunately we've already got broken exit pattern, because the current thread has to do a blocking call, having the ownership of a critical section. The full array of handles means that many threads are exiting at that time, thus all the threads that are starting to exit after the current one will block at the attempt to grab ownership of the critical section. Raising the priority of one thread that had already reached _endthreadex(), seems appropriate to me in such a situation, because it helps shorten the period of time when the threads remain blocked. Choosing the oldest exiting thread ensures that the period of time when the priority of one thread is higher is the smallest possible. 2) The process exit branch. That's the main part of the fix -- here we make the process to wait for all the threads having called _endthreadex() to complete, at the same time preventing any other threads from starting the exiting procedure. The execution flow is already changed here (I don't want to say disrupted, because it was meant to fix the issue). All running threads are about to be terminated soon by ending the process, so raising the priority of some of the threads should not have any bad impact on the program flow. Instead, it may make the time the process has to wait before calling exit() shorter. I can surely remove that playing with the threads' priority, as it's not the essential part of the fix. However, I think it's a useful hint to the scheduler, which can improve things in some situations, and I'm not really sure how it can harm. Sincerely yours, Ivan > David > >> Sincerely yours, >> Ivan >> >> >> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>> for exiting threads [win]) caused the warning message to be printed >>>> in some test environments: >>>> ----------- >>>> os_windows.cpp:3844 is in the newly updated >>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>> ----------- >>>> >>>> This has been observed with debug builds on highly loaded systems. >>>> >>>> >>>> To address the issue it is proposed to do three things: >>>> 1) increase the timeout for debug builds, >>>> 2) increase the maximum number of the thread handles to be stored, >>>> 3) rise the priority of the exiting threads, if we need to wait for >>>> them. >>>> >>>> Would you please help review the fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>> >>> src/os/windows/vm/os_windows.cpp >>> >>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>> >>> That uses the smaller value for only one build config (PRODUCT). >>> >>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) >>> /*1 sec in product, 4 sec in debug*/ >>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>> Please add spaces between the comment delimiters and the comment >>> text. >>> >>> That uses the smaller timeout for only one build config (PRODUCT). >>> >>> line 3836 // Rise the priority... >>> Typo: 'Rise' -> 'Raise' >>> >>> About the general idea of raising the exiting thread's priority, >>> if the exiting thread is looping in some Win* OS code after this >>> point, will raising the priority make the machine unusable? >>> >>> Dan >>> >>> >>>> >>>> The fix was tested on all available platforms, with the hotspot >>>> testset. No failures. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >>> >>> >> > > From maynardj at us.ibm.com Mon Nov 17 16:00:58 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 17 Nov 2014 10:00:58 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <54665F96.9030905@oracle.com> Message-ID: <546A1BBA.4070400@us.ibm.com> On 11/14/2014 05:09 PM, Volker Simonis wrote: > > > On Friday, November 14, 2014, Vladimir Kozlov > wrote: > > Volker or Goetz, can you help Maynard to create bugs and prepare webrevs on cr.openjdk for these 3 changes? > > > I will create the bugs and have look at the changes on monday. > > Regards, > Volker > > > Thanks, > Vladimir > > On 11/14/14 10:09 AM, Maynard Johnson wrote: > > When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: > > OS/CPU combination linux/ppc64 not yet supported > > I will post a patch set that adds this support. The patch set consists of the following patches: > > PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files > > PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files > > These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. > > ------------ > Open issues: > ------------ > 1) The jstack tool does not print a stack entry for the 'main()' method of the Java > workload (attached) under test. For example: > > (Note: Addresses and method signatures elided for brevity.) > > Thread 24358: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > ==> (Expect an entry for test.main() here) > > 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: > > Thread 24779: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) > - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) > > Again, the 'test.main' method is missing, but there's also the anomaly of the > test.run_test' method showing up twice in the stack, implying that it is called > by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test > does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- > but these are totally distinct call graphs. Somehow, we are seeing these two distinct > stacks in the core file, which seems impossible. Sorry, I neglected to mention a third issue: 3) The mixed mode option for jstack does not work. Still investigating. -Maynard > > --------- > > Any help offered on these two open issues would be greatly appreciated. > > -Maynard > From volker.simonis at gmail.com Mon Nov 17 16:20:05 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Nov 2014 17:20:05 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <54664554.4060309@us.ibm.com> References: <54664554.4060309@us.ibm.com> Message-ID: Hi Maynard, I'm currently looking at your changes. At first glance they look good. I could open a simple core file which contained both, interpreted and compiled frames: $ jstack ./images/j2sdk-image/bin/java core.7034 ... Thread 7035: (state = IN_VM) - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) - Crash.doIt() @bci=45, line=23 (Compiled frame) - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=100, line=62 (Interpreted frame) - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6, line=43 (Interpreted frame) - java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) @bci=56, line=498 (Interpreted frame) - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) The one thing that doesn't currently work is "jstack -m" (i.e. "mixed mode" for java and native frames). Are you aware of this? Regarding your "test.java" example - how do you use it? If I just attach with jstack to the Java process which runs "test.java" I get the correct stack trace of all threads. But I think that's actual no SA-functionality but a VM-feature (the same that can be triggered by sending kill -SIGQUIT to java process). If I attach with "jstack -F" I see the problems you mentioned. First I didn't saw any frame at all which confused me but then I also saw the two cases mentioned by you. I'll need to have a closer look what happens. Regards, Volker On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: > When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: > > OS/CPU combination linux/ppc64 not yet supported > > I will post a patch set that adds this support. The patch set consists of the following patches: > > PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files > > PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files > > These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. > > ------------ > Open issues: > ------------ > 1) The jstack tool does not print a stack entry for the 'main()' method of the Java > workload (attached) under test. For example: > > (Note: Addresses and method signatures elided for brevity.) > > Thread 24358: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > ==> (Expect an entry for test.main() here) > > 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: > > Thread 24779: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) > - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) > - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) > > Again, the 'test.main' method is missing, but there's also the anomaly of the > test.run_test' method showing up twice in the stack, implying that it is called > by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test > does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- > but these are totally distinct call graphs. Somehow, we are seeing these two distinct > stacks in the core file, which seems impossible. > > --------- > > Any help offered on these two open issues would be greatly appreciated. > > -Maynard From maynardj at us.ibm.com Mon Nov 17 17:59:04 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 17 Nov 2014 11:59:04 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> Message-ID: <546A3768.20809@us.ibm.com> On 11/17/2014 10:20 AM, Volker Simonis wrote: > Hi Maynard, > > I'm currently looking at your changes. At first glance they look good. > > I could open a simple core file which contained both, interpreted and > compiled frames: > > $ jstack ./images/j2sdk-image/bin/java core.7034 > ... > Thread 7035: (state = IN_VM) > - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) > - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) > - Crash.doIt() @bci=45, line=23 (Compiled frame) > - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, > java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) > - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) @bci=100, line=62 (Interpreted frame) > - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, > java.lang.Object[]) @bci=6, line=43 (Interpreted frame) > - java.lang.reflect.Method.invoke(java.lang.Object, > java.lang.Object[]) @bci=56, line=498 (Interpreted frame) > - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) > > The one thing that doesn't currently work is "jstack -m" (i.e. "mixed > mode" for java and native frames). Are you aware of this? Hi, Volker, Yeah, I knew about this problem and forgot to mention it in my patch posting. I started looking at it this morning, and so far, I have at least fixed the UnmappedAddressException. But now I'm getting different results on little endian vs big endian ppc64 systems. On BE, I either get no symbol names (i.e., "?????") or wrong symbol names. On LE, I seem to get correct symbol names for the first symbol (either __pthread_cond_wait or __pthread_cond_timedwait) and the last symbol (start_thread) of each stack, but everything in between is "?????". > > Regarding your "test.java" example - how do you use it? > > If I just attach with jstack to the Java process which runs > "test.java" I get the correct stack trace of all threads. But I think > that's actual no SA-functionality but a VM-feature (the same that can > be triggered by sending kill -SIGQUIT to java process). > > If I attach with "jstack -F" I see the problems you mentioned. First I > didn't saw any frame at all which confused me but then I also saw the > two cases mentioned by you. I'll need to have a closer look what > happens. I was just running the 'test' java app and, in another session, killing it with SIGSEGV. To be honest, I wasn't aware of the 'jstack -F' option. -Maynard > > Regards, > Volker > > > > On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: >> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: >> >> OS/CPU combination linux/ppc64 not yet supported >> >> I will post a patch set that adds this support. The patch set consists of the following patches: >> >> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files >> >> PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files >> >> These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. >> >> ------------ >> Open issues: >> ------------ >> 1) The jstack tool does not print a stack entry for the 'main()' method of the Java >> workload (attached) under test. For example: >> >> (Note: Addresses and method signatures elided for brevity.) >> >> Thread 24358: (state = IN_JAVA, current Java SP = null >> ) >> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >> ==> (Expect an entry for test.main() here) >> >> 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: >> >> Thread 24779: (state = IN_JAVA, current Java SP = null >> ) >> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) >> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) >> >> Again, the 'test.main' method is missing, but there's also the anomaly of the >> test.run_test' method showing up twice in the stack, implying that it is called >> by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test >> does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- >> but these are totally distinct call graphs. Somehow, we are seeing these two distinct >> stacks in the core file, which seems impossible. >> >> --------- >> >> Any help offered on these two open issues would be greatly appreciated. >> >> -Maynard > From volker.simonis at gmail.com Mon Nov 17 19:21:58 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Nov 2014 20:21:58 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <546A3768.20809@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> Message-ID: On Mon, Nov 17, 2014 at 6:59 PM, Maynard Johnson wrote: > On 11/17/2014 10:20 AM, Volker Simonis wrote: >> Hi Maynard, >> >> I'm currently looking at your changes. At first glance they look good. >> >> I could open a simple core file which contained both, interpreted and >> compiled frames: >> >> $ jstack ./images/j2sdk-image/bin/java core.7034 >> ... >> Thread 7035: (state = IN_VM) >> - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) >> - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) >> - Crash.doIt() @bci=45, line=23 (Compiled frame) >> - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >> - java.lang.reflect.Method.invoke(java.lang.Object, >> java.lang.Object[]) @bci=56, line=498 (Interpreted frame) >> - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) >> >> The one thing that doesn't currently work is "jstack -m" (i.e. "mixed >> mode" for java and native frames). Are you aware of this? > Hi, Volker, > Yeah, I knew about this problem and forgot to mention it in my patch posting. I started > looking at it this morning, and so far, I have at least fixed the UnmappedAddressException. > But now I'm getting different results on little endian vs big endian ppc64 systems. > On BE, I either get no symbol names (i.e., "?????") or wrong symbol names. On LE, > I seem to get correct symbol names for the first symbol (either __pthread_cond_wait > or __pthread_cond_timedwait) and the last symbol (start_thread) of each stack, but > everything in between is "?????". > Maybe this is related to the fact that we have function descriptors on BE and simple function pointers on LE. You may have a look at the elf-decoder for ppc64 to find some more information. >> >> Regarding your "test.java" example - how do you use it? >> >> If I just attach with jstack to the Java process which runs >> "test.java" I get the correct stack trace of all threads. But I think >> that's actual no SA-functionality but a VM-feature (the same that can >> be triggered by sending kill -SIGQUIT to java process). >> >> If I attach with "jstack -F" I see the problems you mentioned. First I >> didn't saw any frame at all which confused me but then I also saw the >> two cases mentioned by you. I'll need to have a closer look what >> happens. > > I was just running the 'test' java app and, in another session, killing it with SIGSEGV. > To be honest, I wasn't aware of the 'jstack -F' option. > Another possibility I've just found out is to create a core from gdb with the 'generate-core-file' command. You can than still inspect the original program in gdb while debugging how jstack is working on the core file. > -Maynard > >> >> Regards, >> Volker >> >> >> >> On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: >>> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: >>> >>> OS/CPU combination linux/ppc64 not yet supported >>> >>> I will post a patch set that adds this support. The patch set consists of the following patches: >>> >>> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files >>> >>> PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files >>> >>> These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. >>> >>> ------------ >>> Open issues: >>> ------------ >>> 1) The jstack tool does not print a stack entry for the 'main()' method of the Java >>> workload (attached) under test. For example: >>> >>> (Note: Addresses and method signatures elided for brevity.) >>> >>> Thread 24358: (state = IN_JAVA, current Java SP = null >>> ) >>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>> ==> (Expect an entry for test.main() here) >>> >>> 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: >>> >>> Thread 24779: (state = IN_JAVA, current Java SP = null >>> ) >>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) >>> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) >>> >>> Again, the 'test.main' method is missing, but there's also the anomaly of the >>> test.run_test' method showing up twice in the stack, implying that it is called >>> by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test >>> does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- >>> but these are totally distinct call graphs. Somehow, we are seeing these two distinct >>> stacks in the core file, which seems impossible. >>> >>> --------- >>> >>> Any help offered on these two open issues would be greatly appreciated. >>> >>> -Maynard >> > From maynardj at us.ibm.com Mon Nov 17 23:20:14 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 17 Nov 2014 17:20:14 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> Message-ID: <546A82AE.6010703@us.ibm.com> On 11/17/2014 01:21 PM, Volker Simonis wrote: > On Mon, Nov 17, 2014 at 6:59 PM, Maynard Johnson wrote: >> On 11/17/2014 10:20 AM, Volker Simonis wrote: >>> Hi Maynard, >>> >>> I'm currently looking at your changes. At first glance they look good. >>> >>> I could open a simple core file which contained both, interpreted and >>> compiled frames: >>> >>> $ jstack ./images/j2sdk-image/bin/java core.7034 >>> ... >>> Thread 7035: (state = IN_VM) >>> - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) >>> - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) >>> - Crash.doIt() @bci=45, line=23 (Compiled frame) >>> - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >>> - java.lang.reflect.Method.invoke(java.lang.Object, >>> java.lang.Object[]) @bci=56, line=498 (Interpreted frame) >>> - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) >>> >>> The one thing that doesn't currently work is "jstack -m" (i.e. "mixed >>> mode" for java and native frames). Are you aware of this? >> Hi, Volker, >> Yeah, I knew about this problem and forgot to mention it in my patch posting. I started >> looking at it this morning, and so far, I have at least fixed the UnmappedAddressException. >> But now I'm getting different results on little endian vs big endian ppc64 systems. >> On BE, I either get no symbol names (i.e., "?????") or wrong symbol names. On LE, >> I seem to get correct symbol names for the first symbol (either __pthread_cond_wait >> or __pthread_cond_timedwait) and the last symbol (start_thread) of each stack, but >> everything in between is "?????". >> > > Maybe this is related to the fact that we have function descriptors on > BE and simple function pointers on LE. You may have a look at the > elf-decoder for ppc64 to find some more information. Yes, indeed. With the following patch, the mixed mode option works fine on ppc64 little endian, but not on big endian: Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java =================================================================== --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java @@ -60,14 +60,15 @@ final public class LinuxPPC64CFrame exte return null; } - Address nextSP = sp.getAddressAt( PPC64ThreadContext.SP * address_size + PPC64_STACK_BIAS); + Address nextSP = sp.getAddressAt(0); if (nextSP == null) { return null; } - Address nextPC = sp.getAddressAt(PPC64ThreadContext.PC * address_size + PPC64_STACK_BIAS); + Address nextPC = sp.getAddressAt(2 * address_size); if (nextPC == null) { return null; } + return new LinuxPPC64CFrame(dbg, nextSP, nextPC,address_size); } ------------------------------------------------- I see that ppc64 fixups were made in the hotspot utilities (by you) about a year ago (http://cr.openjdk.java.net/~simonis/webrevs/8019929.v3/). We obviously need something similar in the hotspot agent native code that implements the JNI call 'lookupByAddress0'. I hacked the build_symtab_internal() function in hotspot/agent/src/os/linux/symtab.c and see that the symbol "offset" we're getting is really the address of the symbol's opd. I'm not sure where to start to fix this, so if you have any suggestions, I'm all ears. :-) Thanks. -Maynard > >>> >>> Regarding your "test.java" example - how do you use it? >>> >>> If I just attach with jstack to the Java process which runs >>> "test.java" I get the correct stack trace of all threads. But I think >>> that's actual no SA-functionality but a VM-feature (the same that can >>> be triggered by sending kill -SIGQUIT to java process). >>> >>> If I attach with "jstack -F" I see the problems you mentioned. First I >>> didn't saw any frame at all which confused me but then I also saw the >>> two cases mentioned by you. I'll need to have a closer look what >>> happens. >> >> I was just running the 'test' java app and, in another session, killing it with SIGSEGV. >> To be honest, I wasn't aware of the 'jstack -F' option. >> > > Another possibility I've just found out is to create a core from gdb > with the 'generate-core-file' command. You can than still inspect the > original program in gdb while debugging how jstack is working on the > core file. > >> -Maynard >> >>> >>> Regards, >>> Volker >>> >>> >>> >>> On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: >>>> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: >>>> >>>> OS/CPU combination linux/ppc64 not yet supported >>>> >>>> I will post a patch set that adds this support. The patch set consists of the following patches: >>>> >>>> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files >>>> >>>> PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files >>>> >>>> These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. >>>> >>>> ------------ >>>> Open issues: >>>> ------------ >>>> 1) The jstack tool does not print a stack entry for the 'main()' method of the Java >>>> workload (attached) under test. For example: >>>> >>>> (Note: Addresses and method signatures elided for brevity.) >>>> >>>> Thread 24358: (state = IN_JAVA, current Java SP = null >>>> ) >>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>> ==> (Expect an entry for test.main() here) >>>> >>>> 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: >>>> >>>> Thread 24779: (state = IN_JAVA, current Java SP = null >>>> ) >>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) >>>> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) >>>> >>>> Again, the 'test.main' method is missing, but there's also the anomaly of the >>>> test.run_test' method showing up twice in the stack, implying that it is called >>>> by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test >>>> does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- >>>> but these are totally distinct call graphs. Somehow, we are seeing these two distinct >>>> stacks in the core file, which seems impossible. >>>> >>>> --------- >>>> >>>> Any help offered on these two open issues would be greatly appreciated. >>>> >>>> -Maynard >>> >> > From david.holmes at oracle.com Tue Nov 18 01:50:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Nov 2014 11:50:14 +1000 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <5469B920.4040300@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> <5469B920.4040300@oracle.com> Message-ID: <546AA5D6.4050203@oracle.com> Hi Ivan, On 17/11/2014 7:00 PM, Ivan Gerasimov wrote: > Thanks David! > > On 17.11.2014 9:40, David Holmes wrote: >> On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >>> Thank you Daniel! >>> >>> Please find the updated webrev with your suggestions incorporated here: >>> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >>> >>> Concerning the thread priority: If the application is of >>> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >>> THREAD_PRIORITY_HIGHEST will result in its priority value to be only 10 >>> (of maximum 31). >>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx >>> >>> >>> >>> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >>> HIGHEST priority level will have priority value == 15 of 31. >>> >>> I believe, it should not be too much, and the machine will not become >>> busy with only those closing threads. >>> However, I hope it would be enough to make them complete faster than >>> other threads of the NORMAL priority level withing the same application. >> >> I don't think this is necessary or desirable. Under normal usage we're >> giving priority to exiting threads and that may disrupt the usual >> scheduling patterns that applications see. You may posit that it is >> "harmless" but we can't say that for sure. Nor can we actually know >> that this will help with this particular bug. I would not add in this >> new code. >> > > There are two places where I put adjusting the thread's priority: > > 1) We've the array of handles filled up. > > If we're found in this code branch, it'll mean that unfortunately we've > already got broken exit pattern, because the current thread has to do a > blocking call, having the ownership of a critical section. > The full array of handles means that many threads are exiting at that > time, thus all the threads that are starting to exit after the current > one will block at the attempt to grab ownership of the critical section. > > Raising the priority of one thread that had already reached > _endthreadex(), seems appropriate to me in such a situation, because it > helps shorten the period of time when the threads remain blocked. > > Choosing the oldest exiting thread ensures that the period of time when > the priority of one thread is higher is the smallest possible. > > 2) The process exit branch. > > That's the main part of the fix -- here we make the process to wait for > all the threads having called _endthreadex() to complete, at the same > time preventing any other threads from starting the exiting procedure. > The execution flow is already changed here (I don't want to say > disrupted, because it was meant to fix the issue). > > All running threads are about to be terminated soon by ending the > process, so raising the priority of some of the threads should not have > any bad impact on the program flow. > Instead, it may make the time the process has to wait before calling > exit() shorter. > > > I can surely remove that playing with the threads' priority, as it's not > the essential part of the fix. > However, I think it's a useful hint to the scheduler, which can improve > things in some situations, and I'm not really sure how it can harm. Okay. You've convinced me. I'm okay with the priority changes to try to minimize the exit time blocking. Thanks, David > > Sincerely yours, > Ivan > > >> David >> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>>> for exiting threads [win]) caused the warning message to be printed >>>>> in some test environments: >>>>> ----------- >>>>> os_windows.cpp:3844 is in the newly updated >>>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>>> ----------- >>>>> >>>>> This has been observed with debug builds on highly loaded systems. >>>>> >>>>> >>>>> To address the issue it is proposed to do three things: >>>>> 1) increase the timeout for debug builds, >>>>> 2) increase the maximum number of the thread handles to be stored, >>>>> 3) rise the priority of the exiting threads, if we need to wait for >>>>> them. >>>>> >>>>> Would you please help review the fix? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> >>>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>> >>>> That uses the smaller value for only one build config (PRODUCT). >>>> >>>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) >>>> /*1 sec in product, 4 sec in debug*/ >>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>> Please add spaces between the comment delimiters and the comment >>>> text. >>>> >>>> That uses the smaller timeout for only one build config (PRODUCT). >>>> >>>> line 3836 // Rise the priority... >>>> Typo: 'Rise' -> 'Raise' >>>> >>>> About the general idea of raising the exiting thread's priority, >>>> if the exiting thread is looping in some Win* OS code after this >>>> point, will raising the priority make the machine unusable? >>>> >>>> Dan >>>> >>>> >>>>> >>>>> The fix was tested on all available platforms, with the hotspot >>>>> testset. No failures. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>> >>>> >>>> >>> >> >> > From daniel.daugherty at oracle.com Tue Nov 18 02:01:18 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 17 Nov 2014 19:01:18 -0700 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <546AA5D6.4050203@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> <5469B920.4040300@oracle.com> <546AA5D6.4050203@oracle.com> Message-ID: <546AA86E.3030308@oracle.com> Ivan, Please coordinate with Staffan Larsen about when he is planning to take this week's snapshot of JDK9-hs-rt (RT_Baseline). Please push your fix after Staffan's snapshot so we can have a week of soak time for this version of the fix... Dan On 11/17/14 6:50 PM, David Holmes wrote: > Hi Ivan, > > On 17/11/2014 7:00 PM, Ivan Gerasimov wrote: >> Thanks David! >> >> On 17.11.2014 9:40, David Holmes wrote: >>> On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >>>> Thank you Daniel! >>>> >>>> Please find the updated webrev with your suggestions incorporated >>>> here: >>>> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >>>> >>>> Concerning the thread priority: If the application is of >>>> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >>>> THREAD_PRIORITY_HIGHEST will result in its priority value to be >>>> only 10 >>>> (of maximum 31). >>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx >>>> >>>> >>>> >>>> >>>> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >>>> HIGHEST priority level will have priority value == 15 of 31. >>>> >>>> I believe, it should not be too much, and the machine will not become >>>> busy with only those closing threads. >>>> However, I hope it would be enough to make them complete faster than >>>> other threads of the NORMAL priority level withing the same >>>> application. >>> >>> I don't think this is necessary or desirable. Under normal usage we're >>> giving priority to exiting threads and that may disrupt the usual >>> scheduling patterns that applications see. You may posit that it is >>> "harmless" but we can't say that for sure. Nor can we actually know >>> that this will help with this particular bug. I would not add in this >>> new code. >>> >> >> There are two places where I put adjusting the thread's priority: >> >> 1) We've the array of handles filled up. >> >> If we're found in this code branch, it'll mean that unfortunately we've >> already got broken exit pattern, because the current thread has to do a >> blocking call, having the ownership of a critical section. >> The full array of handles means that many threads are exiting at that >> time, thus all the threads that are starting to exit after the current >> one will block at the attempt to grab ownership of the critical section. >> >> Raising the priority of one thread that had already reached >> _endthreadex(), seems appropriate to me in such a situation, because it >> helps shorten the period of time when the threads remain blocked. >> >> Choosing the oldest exiting thread ensures that the period of time when >> the priority of one thread is higher is the smallest possible. >> >> 2) The process exit branch. >> >> That's the main part of the fix -- here we make the process to wait for >> all the threads having called _endthreadex() to complete, at the same >> time preventing any other threads from starting the exiting procedure. >> The execution flow is already changed here (I don't want to say >> disrupted, because it was meant to fix the issue). >> >> All running threads are about to be terminated soon by ending the >> process, so raising the priority of some of the threads should not have >> any bad impact on the program flow. >> Instead, it may make the time the process has to wait before calling >> exit() shorter. >> >> >> I can surely remove that playing with the threads' priority, as it's not >> the essential part of the fix. >> However, I think it's a useful hint to the scheduler, which can improve >> things in some situations, and I'm not really sure how it can harm. > > Okay. You've convinced me. I'm okay with the priority changes to try > to minimize the exit time blocking. > > Thanks, > David > >> >> Sincerely yours, >> Ivan >> >> >>> David >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>>>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>>>> Hello! >>>>>> >>>>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>>>> for exiting threads [win]) caused the warning message to be printed >>>>>> in some test environments: >>>>>> ----------- >>>>>> os_windows.cpp:3844 is in the newly updated >>>>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>>>> ----------- >>>>>> >>>>>> This has been observed with debug builds on highly loaded systems. >>>>>> >>>>>> >>>>>> To address the issue it is proposed to do three things: >>>>>> 1) increase the timeout for debug builds, >>>>>> 2) increase the maximum number of the thread handles to be stored, >>>>>> 3) rise the priority of the exiting threads, if we need to wait for >>>>>> them. >>>>>> >>>>>> Would you please help review the fix? >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>>>> >>>>> src/os/windows/vm/os_windows.cpp >>>>> >>>>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>> >>>>> That uses the smaller value for only one build config (PRODUCT). >>>>> >>>>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) >>>>> DEBUG_ONLY(4000) >>>>> /*1 sec in product, 4 sec in debug*/ >>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>> Please add spaces between the comment delimiters and the comment >>>>> text. >>>>> >>>>> That uses the smaller timeout for only one build config >>>>> (PRODUCT). >>>>> >>>>> line 3836 // Rise the priority... >>>>> Typo: 'Rise' -> 'Raise' >>>>> >>>>> About the general idea of raising the exiting thread's priority, >>>>> if the exiting thread is looping in some Win* OS code after this >>>>> point, will raising the priority make the machine unusable? >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> The fix was tested on all available platforms, with the hotspot >>>>>> testset. No failures. >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> From daniel.daugherty at oracle.com Tue Nov 18 02:05:30 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 17 Nov 2014 19:05:30 -0700 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <546AA86E.3030308@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> <5469B920.4040300@oracle.com> <546AA5D6.4050203@oracle.com> <546AA86E.3030308@oracle.com> Message-ID: <546AA96A.1020203@oracle.com> Ivan, I spoke too soon. There's a review comment from Markus G that hasn't been addressed. We need to see if you've convinced Markus in addition to David H. Dan P.S. Look for Markus' reply to David H's e-mail; it not in this fork of the review thread... On 11/17/14 7:01 PM, Daniel D. Daugherty wrote: > Ivan, > > Please coordinate with Staffan Larsen about when he is planning to > take this week's snapshot of JDK9-hs-rt (RT_Baseline). Please push > your fix after Staffan's snapshot so we can have a week of soak > time for this version of the fix... > > Dan > > > On 11/17/14 6:50 PM, David Holmes wrote: >> Hi Ivan, >> >> On 17/11/2014 7:00 PM, Ivan Gerasimov wrote: >>> Thanks David! >>> >>> On 17.11.2014 9:40, David Holmes wrote: >>>> On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >>>>> Thank you Daniel! >>>>> >>>>> Please find the updated webrev with your suggestions incorporated >>>>> here: >>>>> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >>>>> >>>>> Concerning the thread priority: If the application is of >>>>> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >>>>> THREAD_PRIORITY_HIGHEST will result in its priority value to be >>>>> only 10 >>>>> (of maximum 31). >>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx >>>>> >>>>> >>>>> >>>>> >>>>> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >>>>> HIGHEST priority level will have priority value == 15 of 31. >>>>> >>>>> I believe, it should not be too much, and the machine will not become >>>>> busy with only those closing threads. >>>>> However, I hope it would be enough to make them complete faster than >>>>> other threads of the NORMAL priority level withing the same >>>>> application. >>>> >>>> I don't think this is necessary or desirable. Under normal usage we're >>>> giving priority to exiting threads and that may disrupt the usual >>>> scheduling patterns that applications see. You may posit that it is >>>> "harmless" but we can't say that for sure. Nor can we actually know >>>> that this will help with this particular bug. I would not add in this >>>> new code. >>>> >>> >>> There are two places where I put adjusting the thread's priority: >>> >>> 1) We've the array of handles filled up. >>> >>> If we're found in this code branch, it'll mean that unfortunately we've >>> already got broken exit pattern, because the current thread has to do a >>> blocking call, having the ownership of a critical section. >>> The full array of handles means that many threads are exiting at that >>> time, thus all the threads that are starting to exit after the current >>> one will block at the attempt to grab ownership of the critical >>> section. >>> >>> Raising the priority of one thread that had already reached >>> _endthreadex(), seems appropriate to me in such a situation, because it >>> helps shorten the period of time when the threads remain blocked. >>> >>> Choosing the oldest exiting thread ensures that the period of time when >>> the priority of one thread is higher is the smallest possible. >>> >>> 2) The process exit branch. >>> >>> That's the main part of the fix -- here we make the process to wait for >>> all the threads having called _endthreadex() to complete, at the same >>> time preventing any other threads from starting the exiting procedure. >>> The execution flow is already changed here (I don't want to say >>> disrupted, because it was meant to fix the issue). >>> >>> All running threads are about to be terminated soon by ending the >>> process, so raising the priority of some of the threads should not have >>> any bad impact on the program flow. >>> Instead, it may make the time the process has to wait before calling >>> exit() shorter. >>> >>> >>> I can surely remove that playing with the threads' priority, as it's >>> not >>> the essential part of the fix. >>> However, I think it's a useful hint to the scheduler, which can improve >>> things in some situations, and I'm not really sure how it can harm. >> >> Okay. You've convinced me. I'm okay with the priority changes to try >> to minimize the exit time blocking. >> >> Thanks, >> David >> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>>> David >>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>>>>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>>>>> Hello! >>>>>>> >>>>>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>>>>> for exiting threads [win]) caused the warning message to be printed >>>>>>> in some test environments: >>>>>>> ----------- >>>>>>> os_windows.cpp:3844 is in the newly updated >>>>>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>>>>> ----------- >>>>>>> >>>>>>> This has been observed with debug builds on highly loaded systems. >>>>>>> >>>>>>> >>>>>>> To address the issue it is proposed to do three things: >>>>>>> 1) increase the timeout for debug builds, >>>>>>> 2) increase the maximum number of the thread handles to be stored, >>>>>>> 3) rise the priority of the exiting threads, if we need to wait for >>>>>>> them. >>>>>>> >>>>>>> Would you please help review the fix? >>>>>>> >>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>>>>> >>>>>> src/os/windows/vm/os_windows.cpp >>>>>> >>>>>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>>> >>>>>> That uses the smaller value for only one build config (PRODUCT). >>>>>> >>>>>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) >>>>>> DEBUG_ONLY(4000) >>>>>> /*1 sec in product, 4 sec in debug*/ >>>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>>> Please add spaces between the comment delimiters and the comment >>>>>> text. >>>>>> >>>>>> That uses the smaller timeout for only one build config >>>>>> (PRODUCT). >>>>>> >>>>>> line 3836 // Rise the priority... >>>>>> Typo: 'Rise' -> 'Raise' >>>>>> >>>>>> About the general idea of raising the exiting thread's priority, >>>>>> if the exiting thread is looping in some Win* OS code after this >>>>>> point, will raising the priority make the machine unusable? >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> The fix was tested on all available platforms, with the hotspot >>>>>>> testset. No failures. >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > > > > From ivan.gerasimov at oracle.com Tue Nov 18 07:29:30 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 18 Nov 2014 10:29:30 +0300 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> Message-ID: <546AF55A.8090203@oracle.com> Hi Markus! The priority of the exiting thread will be raised for quite a short period of time -- right before the thread finishes exiting. There are two places where the priority is adjusted. Under normal conditions we should never see the first place hit. However, if we do, this means we have a huge number of threads. Raising the priority of one of them is a hint about which thread we want the scheduler to focus on. The second place is a bit different. We have several threads running immediately before ending the process. Some of them are at the exiting path and block exiting of the whole process. Raising the priority of those threads is a way to say we're not interested in all the other threads, as they are going to be terminated anyway. I just noticed that in second scenario it may be appropriate to set the priority of the current thread to the same level as for the exiting threads. This way it'll be given a fair chance to continue if the timeout expires. I also think it should be enough to set the priority level to THREAD_PRIORITY_ABOVE_NORMAL instead of THREAD_PRIORITY_HIGHEST. It will give just +1 to the priority value -- should be enough for the hint. Would you please take a look at the updated webrev: http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ Sincerely yours, Ivan On 17.11.2014 11:33, Markus Gr?nlund wrote: > I agree with David. > > The side effects will be unknown and very hard to debug. > > Is there another way to accomplish the results without manipulating base services? > > Thanks > Markus > > -----Original Message----- > From: David Holmes > Sent: den 17 november 2014 07:40 > To: Ivan Gerasimov; Daniel Daugherty > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev > Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 > > On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >> Thank you Daniel! >> >> Please find the updated webrev with your suggestions incorporated here: >> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >> >> Concerning the thread priority: If the application is of >> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >> THREAD_PRIORITY_HIGHEST will result in its priority value to be only >> 10 (of maximum 31). >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs. >> 85).aspx >> >> >> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >> HIGHEST priority level will have priority value == 15 of 31. >> >> I believe, it should not be too much, and the machine will not become >> busy with only those closing threads. >> However, I hope it would be enough to make them complete faster than >> other threads of the NORMAL priority level withing the same application. > I don't think this is necessary or desirable. Under normal usage we're giving priority to exiting threads and that may disrupt the usual scheduling patterns that applications see. You may posit that it is "harmless" but we can't say that for sure. Nor can we actually know that this will help with this particular bug. I would not add in this new code. > > David > >> Sincerely yours, >> Ivan >> >> >> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>> for exiting threads [win]) caused the warning message to be printed >>>> in some test environments: >>>> ----------- >>>> os_windows.cpp:3844 is in the newly updated >>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>> ----------- >>>> >>>> This has been observed with debug builds on highly loaded systems. >>>> >>>> >>>> To address the issue it is proposed to do three things: >>>> 1) increase the timeout for debug builds, >>>> 2) increase the maximum number of the thread handles to be stored, >>>> 3) rise the priority of the exiting threads, if we need to wait for >>>> them. >>>> >>>> Would you please help review the fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>> src/os/windows/vm/os_windows.cpp >>> >>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>> >>> That uses the smaller value for only one build config (PRODUCT). >>> >>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) >>> /*1 sec in product, 4 sec in debug*/ >>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>> Please add spaces between the comment delimiters and the comment >>> text. >>> >>> That uses the smaller timeout for only one build config (PRODUCT). >>> >>> line 3836 // Rise the priority... >>> Typo: 'Rise' -> 'Raise' >>> >>> About the general idea of raising the exiting thread's priority, >>> if the exiting thread is looping in some Win* OS code after this >>> point, will raising the priority make the machine unusable? >>> >>> Dan >>> >>> >>>> The fix was tested on all available platforms, with the hotspot >>>> testset. No failures. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >>> > From yekaterina.kantserova at oracle.com Tue Nov 18 11:07:09 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 18 Nov 2014 12:07:09 +0100 Subject: RFR(S): 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined Message-ID: <546B285D.1040505@oracle.com> Hi, Could I please have a review of this fix. In this fix I take an opportunity to refactor sun/tools/jinfo/Basic.sh and to add more tests for jinfo utility. sun/tools/jinfo/Basic.sh is a last unstable test among tests listed inhttps://bugs.openjdk.java.net/browse/JDK-6542634 that's why I've chosen to use this bug number instead of creating a new one. bug: https://bugs.openjdk.java.net/browse/JDK-6542634 webrev: http://cr.openjdk.java.net/~ykantser/6542634/webrev.00/ The tests have been run and passed on all basic platforms. Thanks, Katja From jaroslav.bachorik at oracle.com Tue Nov 18 11:20:04 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 18 Nov 2014 12:20:04 +0100 Subject: RFR(S): 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined In-Reply-To: <546B285D.1040505@oracle.com> References: <546B285D.1040505@oracle.com> Message-ID: <546B2B64.3050105@oracle.com> Hi Katja, test/ProblemList.txt - you are adding seemingly unrelated issue here test/sun/tools/jinfo/JInfoHelper.java L68 - processBuilder.command(...) could be moved to L67 and do new ProcessBuilder(launcher.getCommand()) - it communicates the purpose better Cheers, -JB- On 11/18/2014 12:07 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > In this fix I take an opportunity to refactor sun/tools/jinfo/Basic.sh > and to add more tests for jinfo utility. sun/tools/jinfo/Basic.sh is a > last unstable test among tests listed > inhttps://bugs.openjdk.java.net/browse/JDK-6542634 that's why I've > chosen to use this bug number instead of creating a new one. > > bug: https://bugs.openjdk.java.net/browse/JDK-6542634 > webrev: http://cr.openjdk.java.net/~ykantser/6542634/webrev.00/ > > The tests have been run and passed on all basic platforms. > > Thanks, > Katja > From markus.gronlund at oracle.com Tue Nov 18 13:02:45 2014 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Tue, 18 Nov 2014 05:02:45 -0800 (PST) Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <546AF55A.8090203@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> <546AF55A.8090203@oracle.com> Message-ID: <31e5d701-c75f-478b-b4a1-3585c40ba274@default> Hi Ivan, I don't want to you block you from getting this in - I need to get the full story behind all these changes (backtracking now). If I find something that I think we should revisit, we can always do that later. So pls go ahead. Thanks Markus PS. I have some concerns (but will need to get back to you on that after tracing down the exact details)). Do you have a particular test case that you have been working on for these changes? -----Original Message----- From: Ivan Gerasimov Sent: den 18 november 2014 08:30 To: Markus Gr?nlund; David Holmes; Daniel Daugherty Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 Hi Markus! The priority of the exiting thread will be raised for quite a short period of time -- right before the thread finishes exiting. There are two places where the priority is adjusted. Under normal conditions we should never see the first place hit. However, if we do, this means we have a huge number of threads. Raising the priority of one of them is a hint about which thread we want the scheduler to focus on. The second place is a bit different. We have several threads running immediately before ending the process. Some of them are at the exiting path and block exiting of the whole process. Raising the priority of those threads is a way to say we're not interested in all the other threads, as they are going to be terminated anyway. I just noticed that in second scenario it may be appropriate to set the priority of the current thread to the same level as for the exiting threads. This way it'll be given a fair chance to continue if the timeout expires. I also think it should be enough to set the priority level to THREAD_PRIORITY_ABOVE_NORMAL instead of THREAD_PRIORITY_HIGHEST. It will give just +1 to the priority value -- should be enough for the hint. Would you please take a look at the updated webrev: http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ Sincerely yours, Ivan On 17.11.2014 11:33, Markus Gr?nlund wrote: > I agree with David. > > The side effects will be unknown and very hard to debug. > > Is there another way to accomplish the results without manipulating base services? > > Thanks > Markus > > -----Original Message----- > From: David Holmes > Sent: den 17 november 2014 07:40 > To: Ivan Gerasimov; Daniel Daugherty > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev > Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed > in hotspot\src\os\windows\vm\os_windows.cpp: 3844 > > On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >> Thank you Daniel! >> >> Please find the updated webrev with your suggestions incorporated here: >> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >> >> Concerning the thread priority: If the application is of >> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >> THREAD_PRIORITY_HIGHEST will result in its priority value to be only >> 10 (of maximum 31). >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs. >> 85).aspx >> >> >> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >> HIGHEST priority level will have priority value == 15 of 31. >> >> I believe, it should not be too much, and the machine will not become >> busy with only those closing threads. >> However, I hope it would be enough to make them complete faster than >> other threads of the NORMAL priority level withing the same application. > I don't think this is necessary or desirable. Under normal usage we're giving priority to exiting threads and that may disrupt the usual scheduling patterns that applications see. You may posit that it is "harmless" but we can't say that for sure. Nor can we actually know that this will help with this particular bug. I would not add in this new code. > > David > >> Sincerely yours, >> Ivan >> >> >> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>> for exiting threads [win]) caused the warning message to be printed >>>> in some test environments: >>>> ----------- >>>> os_windows.cpp:3844 is in the newly updated >>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>> ----------- >>>> >>>> This has been observed with debug builds on highly loaded systems. >>>> >>>> >>>> To address the issue it is proposed to do three things: >>>> 1) increase the timeout for debug builds, >>>> 2) increase the maximum number of the thread handles to be stored, >>>> 3) rise the priority of the exiting threads, if we need to wait for >>>> them. >>>> >>>> Would you please help review the fix? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>> src/os/windows/vm/os_windows.cpp >>> >>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>> >>> That uses the smaller value for only one build config (PRODUCT). >>> >>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) DEBUG_ONLY(4000) >>> /*1 sec in product, 4 sec in debug*/ >>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>> Please add spaces between the comment delimiters and the >>> comment text. >>> >>> That uses the smaller timeout for only one build config (PRODUCT). >>> >>> line 3836 // Rise the priority... >>> Typo: 'Rise' -> 'Raise' >>> >>> About the general idea of raising the exiting thread's priority, >>> if the exiting thread is looping in some Win* OS code after this >>> point, will raising the priority make the machine unusable? >>> >>> Dan >>> >>> >>>> The fix was tested on all available platforms, with the hotspot >>>> testset. No failures. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> >>> > From yekaterina.kantserova at oracle.com Tue Nov 18 13:05:42 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 18 Nov 2014 14:05:42 +0100 Subject: RFR(S): 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined In-Reply-To: <546B2B64.3050105@oracle.com> References: <546B285D.1040505@oracle.com> <546B2B64.3050105@oracle.com> Message-ID: <546B4426.4000505@oracle.com> Hi Jaroslav, Thanks for the quick review! test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java is added to the ProblemList because it contains this case: 90 private static void testInvalidFlag() throws Exception { 91 OutputAnalyzer output = JInfoHelper.jinfo("-flag", "monkey"); 92 assertNotEquals(output.getExitValue(), 0, "A non-zero exit code should be returned for invalid flag"); 93 } which will fail due to https://bugs.openjdk.java.net/browse/JDK-6734748. I've been thinking about to break it out into a separate class, but then decided to group it together with other flag-tests. What would you recommend? The change for L68 will be in the next review. // Katja On 11/18/2014 12:20 PM, Jaroslav Bachorik wrote: > Hi Katja, > > test/ProblemList.txt - you are adding seemingly unrelated issue here > > test/sun/tools/jinfo/JInfoHelper.java > L68 - processBuilder.command(...) could be moved to L67 and do new > ProcessBuilder(launcher.getCommand()) - it communicates the purpose > better > > Cheers, > > -JB- > > > On 11/18/2014 12:07 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> In this fix I take an opportunity to refactor sun/tools/jinfo/Basic.sh >> and to add more tests for jinfo utility. sun/tools/jinfo/Basic.sh is a >> last unstable test among tests listed >> inhttps://bugs.openjdk.java.net/browse/JDK-6542634 that's why I've >> chosen to use this bug number instead of creating a new one. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-6542634 >> webrev: http://cr.openjdk.java.net/~ykantser/6542634/webrev.00/ >> >> The tests have been run and passed on all basic platforms. >> >> Thanks, >> Katja >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Tue Nov 18 14:38:57 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 18 Nov 2014 15:38:57 +0100 Subject: RFR(S): 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined In-Reply-To: <546B285D.1040505@oracle.com> References: <546B285D.1040505@oracle.com> Message-ID: <546B5A01.8040402@oracle.com> Looks good! Erik Yekaterina Kantserova skrev 2014-11-18 12:07: > Hi, > > Could I please have a review of this fix. > > In this fix I take an opportunity to refactor sun/tools/jinfo/Basic.sh > and to add more tests for jinfo utility. sun/tools/jinfo/Basic.sh is a > last unstable test among tests listed > inhttps://bugs.openjdk.java.net/browse/JDK-6542634 that's why I've > chosen to use this bug number instead of creating a new one. > > bug: https://bugs.openjdk.java.net/browse/JDK-6542634 > webrev: http://cr.openjdk.java.net/~ykantser/6542634/webrev.00/ > > The tests have been run and passed on all basic platforms. > > Thanks, > Katja > From poonam.bajaj at oracle.com Tue Nov 18 14:33:51 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 18 Nov 2014 06:33:51 -0800 Subject: RFR(S): JDK-8065220: Include alternate sa.make file for MacOSX Message-ID: <546B58CF.6070905@oracle.com> Hello, Could I request reviews for this simple change to include alternate sa.make file in make/bsd/makefiles/sa.make: Bug:JDK-8065220: Include alternate sa.make file for MacOSX Webrev: http://cr.openjdk.java.net/~poonam/8065220/webrev.00/ Testing: JPRT Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Nov 18 14:36:09 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 18 Nov 2014 15:36:09 +0100 Subject: RFR(S): 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined In-Reply-To: <546B4426.4000505@oracle.com> References: <546B285D.1040505@oracle.com> <546B2B64.3050105@oracle.com> <546B4426.4000505@oracle.com> Message-ID: <546B5959.7040509@oracle.com> On 11/18/2014 02:05 PM, Yekaterina Kantserova wrote: > Hi Jaroslav, > > Thanks for the quick review! > > test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java is added to the > ProblemList because it contains this case: > > 90 private static void testInvalidFlag() throws Exception { > 91 OutputAnalyzer output = JInfoHelper.jinfo("-flag", "monkey"); > 92 assertNotEquals(output.getExitValue(), 0, "A non-zero exit code should be returned for invalid flag"); > 93 } > > which will fail due to https://bugs.openjdk.java.net/browse/JDK-6734748. > I've been thinking about to break it out into a separate class, but then > decided to group it together with other flag-tests. What would you > recommend? Ok. This sounds reasonable. Let's keep it this way. -JB- > > The change for L68 will be in the next review. > > // Katja > > > > On 11/18/2014 12:20 PM, Jaroslav Bachorik wrote: >> Hi Katja, >> >> test/ProblemList.txt - you are adding seemingly unrelated issue here >> >> test/sun/tools/jinfo/JInfoHelper.java >> L68 - processBuilder.command(...) could be moved to L67 and do new >> ProcessBuilder(launcher.getCommand()) - it communicates the purpose >> better >> >> Cheers, >> >> -JB- >> >> >> On 11/18/2014 12:07 PM, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> In this fix I take an opportunity to refactor sun/tools/jinfo/Basic.sh >>> and to add more tests for jinfo utility. sun/tools/jinfo/Basic.sh is a >>> last unstable test among tests listed >>> inhttps://bugs.openjdk.java.net/browse/JDK-6542634 that's why I've >>> chosen to use this bug number instead of creating a new one. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-6542634 >>> webrev: http://cr.openjdk.java.net/~ykantser/6542634/webrev.00/ >>> >>> The tests have been run and passed on all basic platforms. >>> >>> Thanks, >>> Katja >>> >> > From markus.gronlund at oracle.com Tue Nov 18 14:58:35 2014 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Tue, 18 Nov 2014 06:58:35 -0800 (PST) Subject: RFR(S): JDK-8065220: Include alternate sa.make file for MacOSX In-Reply-To: <546B58CF.6070905@oracle.com> References: <546B58CF.6070905@oracle.com> Message-ID: <00c39416-dbfa-4157-907c-4ba0f1ac6704@default> Hi Poonam, ? Looks good. ? Thanks Markus ? From: Poonam Bajaj Sent: den 18 november 2014 15:34 To: serviceability-dev at openjdk.java.net Subject: RFR(S): JDK-8065220: Include alternate sa.make file for MacOSX ? Hello, Could I request reviews for this simple change to include alternate sa.make file in make/bsd/makefiles/sa.make: Bug:HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8065220" JDK-8065220: Include alternate sa.make file for MacOSX Webrev: http://cr.openjdk.java.net/~poonam/8065220/webrev.00/ Testing: JPRT Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Tue Nov 18 14:57:11 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 18 Nov 2014 15:57:11 +0100 Subject: RFR(S): 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined In-Reply-To: <546B5959.7040509@oracle.com> References: <546B285D.1040505@oracle.com> <546B2B64.3050105@oracle.com> <546B4426.4000505@oracle.com> <546B5959.7040509@oracle.com> Message-ID: <546B5E47.3030001@oracle.com> Jaroslav, Erik, thanks! The new webrev can be found here http://cr.openjdk.java.net/~ykantser/6542634/webrev.01/ // Katja On 11/18/2014 03:36 PM, Jaroslav Bachorik wrote: > On 11/18/2014 02:05 PM, Yekaterina Kantserova wrote: >> Hi Jaroslav, >> >> Thanks for the quick review! >> >> test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java is added to the >> ProblemList because it contains this case: >> >> 90 private static void testInvalidFlag() throws Exception { >> 91 OutputAnalyzer output = JInfoHelper.jinfo("-flag", >> "monkey"); >> 92 assertNotEquals(output.getExitValue(), 0, "A non-zero >> exit code should be returned for invalid flag"); >> 93 } >> >> which will fail due to https://bugs.openjdk.java.net/browse/JDK-6734748. >> I've been thinking about to break it out into a separate class, but then >> decided to group it together with other flag-tests. What would you >> recommend? > > Ok. This sounds reasonable. Let's keep it this way. > > -JB- > >> >> The change for L68 will be in the next review. >> >> // Katja >> >> >> >> On 11/18/2014 12:20 PM, Jaroslav Bachorik wrote: >>> Hi Katja, >>> >>> test/ProblemList.txt - you are adding seemingly unrelated issue here >>> >>> test/sun/tools/jinfo/JInfoHelper.java >>> L68 - processBuilder.command(...) could be moved to L67 and do new >>> ProcessBuilder(launcher.getCommand()) - it communicates the purpose >>> better >>> >>> Cheers, >>> >>> -JB- >>> >>> >>> On 11/18/2014 12:07 PM, Yekaterina Kantserova wrote: >>>> Hi, >>>> >>>> Could I please have a review of this fix. >>>> >>>> In this fix I take an opportunity to refactor sun/tools/jinfo/Basic.sh >>>> and to add more tests for jinfo utility. sun/tools/jinfo/Basic.sh is a >>>> last unstable test among tests listed >>>> inhttps://bugs.openjdk.java.net/browse/JDK-6542634 that's why I've >>>> chosen to use this bug number instead of creating a new one. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6542634 >>>> webrev: http://cr.openjdk.java.net/~ykantser/6542634/webrev.00/ >>>> >>>> The tests have been run and passed on all basic platforms. >>>> >>>> Thanks, >>>> Katja >>>> >>> >> > From erik.gahlin at oracle.com Tue Nov 18 15:17:40 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 18 Nov 2014 16:17:40 +0100 Subject: RFR(S): JDK-8065220: Include alternate sa.make file for MacOSX In-Reply-To: <546B58CF.6070905@oracle.com> References: <546B58CF.6070905@oracle.com> Message-ID: <546B6314.3040909@oracle.com> Looks good Erik Poonam Bajaj skrev 2014-11-18 15:33: > Hello, > > Could I request reviews for this simple change to include alternate > sa.make file in make/bsd/makefiles/sa.make: > > Bug:JDK-8065220: > Include alternate sa.make file for MacOSX > Webrev: http://cr.openjdk.java.net/~poonam/8065220/webrev.00/ > Testing: JPRT > > Thanks, > Poonam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Nov 18 15:15:46 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 18 Nov 2014 16:15:46 +0100 Subject: RFR(S): JDK-8065220: Include alternate sa.make file for MacOSX In-Reply-To: <546B6314.3040909@oracle.com> References: <546B58CF.6070905@oracle.com> <546B6314.3040909@oracle.com> Message-ID: <92409510-3AD7-437B-97F4-B4FF28F9B567@oracle.com> Looks good! /Staffan > On 18 nov 2014, at 16:17, Erik Gahlin wrote: > > Looks good > > Erik > > Poonam Bajaj skrev 2014-11-18 15:33: >> Hello, >> >> Could I request reviews for this simple change to include alternate sa.make file in make/bsd/makefiles/sa.make: >> >> Bug: JDK-8065220: Include alternate sa.make file for MacOSX >> Webrev: http://cr.openjdk.java.net/~poonam/8065220/webrev.00/ >> Testing: JPRT >> >> Thanks, >> Poonam >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Nov 18 15:22:45 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 18 Nov 2014 16:22:45 +0100 Subject: RFR(S): 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined In-Reply-To: <546B5E47.3030001@oracle.com> References: <546B285D.1040505@oracle.com> <546B2B64.3050105@oracle.com> <546B4426.4000505@oracle.com> <546B5959.7040509@oracle.com> <546B5E47.3030001@oracle.com> Message-ID: <546B6445.6070908@oracle.com> Looks good! -JB- On 11/18/2014 03:57 PM, Yekaterina Kantserova wrote: > Jaroslav, Erik, thanks! > > The new webrev can be found here > http://cr.openjdk.java.net/~ykantser/6542634/webrev.01/ > > // Katja > > > On 11/18/2014 03:36 PM, Jaroslav Bachorik wrote: >> On 11/18/2014 02:05 PM, Yekaterina Kantserova wrote: >>> Hi Jaroslav, >>> >>> Thanks for the quick review! >>> >>> test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java is added to the >>> ProblemList because it contains this case: >>> >>> 90 private static void testInvalidFlag() throws Exception { >>> 91 OutputAnalyzer output = JInfoHelper.jinfo("-flag", >>> "monkey"); >>> 92 assertNotEquals(output.getExitValue(), 0, "A non-zero >>> exit code should be returned for invalid flag"); >>> 93 } >>> >>> which will fail due to https://bugs.openjdk.java.net/browse/JDK-6734748. >>> I've been thinking about to break it out into a separate class, but then >>> decided to group it together with other flag-tests. What would you >>> recommend? >> >> Ok. This sounds reasonable. Let's keep it this way. >> >> -JB- >> >>> >>> The change for L68 will be in the next review. >>> >>> // Katja >>> >>> >>> >>> On 11/18/2014 12:20 PM, Jaroslav Bachorik wrote: >>>> Hi Katja, >>>> >>>> test/ProblemList.txt - you are adding seemingly unrelated issue here >>>> >>>> test/sun/tools/jinfo/JInfoHelper.java >>>> L68 - processBuilder.command(...) could be moved to L67 and do new >>>> ProcessBuilder(launcher.getCommand()) - it communicates the purpose >>>> better >>>> >>>> Cheers, >>>> >>>> -JB- >>>> >>>> >>>> On 11/18/2014 12:07 PM, Yekaterina Kantserova wrote: >>>>> Hi, >>>>> >>>>> Could I please have a review of this fix. >>>>> >>>>> In this fix I take an opportunity to refactor sun/tools/jinfo/Basic.sh >>>>> and to add more tests for jinfo utility. sun/tools/jinfo/Basic.sh is a >>>>> last unstable test among tests listed >>>>> inhttps://bugs.openjdk.java.net/browse/JDK-6542634 that's why I've >>>>> chosen to use this bug number instead of creating a new one. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6542634 >>>>> webrev: http://cr.openjdk.java.net/~ykantser/6542634/webrev.00/ >>>>> >>>>> The tests have been run and passed on all basic platforms. >>>>> >>>>> Thanks, >>>>> Katja >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Tue Nov 18 15:27:36 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Nov 2014 08:27:36 -0700 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <546AF55A.8090203@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> <546AF55A.8090203@oracle.com> Message-ID: <546B6568.7040701@oracle.com> > http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ src/os/windows/vm/os_windows.cpp No commments. Thumbs up. Dan On 11/18/14 12:29 AM, Ivan Gerasimov wrote: > Hi Markus! > > The priority of the exiting thread will be raised for quite a short > period of time -- right before the thread finishes exiting. > > There are two places where the priority is adjusted. > > Under normal conditions we should never see the first place hit. > However, if we do, this means we have a huge number of threads. > Raising the priority of one of them is a hint about which thread we > want the scheduler to focus on. > > The second place is a bit different. > We have several threads running immediately before ending the process. > Some of them are at the exiting path and block exiting of the whole > process. > Raising the priority of those threads is a way to say we're not > interested in all the other threads, as they are going to be > terminated anyway. > > I just noticed that in second scenario it may be appropriate to set > the priority of the current thread to the same level as for the > exiting threads. > This way it'll be given a fair chance to continue if the timeout expires. > > I also think it should be enough to set the priority level to > THREAD_PRIORITY_ABOVE_NORMAL instead of THREAD_PRIORITY_HIGHEST. > It will give just +1 to the priority value -- should be enough for the > hint. > > Would you please take a look at the updated webrev: > http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ > > Sincerely yours, > Ivan > > > On 17.11.2014 11:33, Markus Gr?nlund wrote: >> I agree with David. >> >> The side effects will be unknown and very hard to debug. >> >> Is there another way to accomplish the results without manipulating >> base services? >> >> Thanks >> Markus >> >> -----Original Message----- >> From: David Holmes >> Sent: den 17 november 2014 07:40 >> To: Ivan Gerasimov; Daniel Daugherty >> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev >> Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed >> in hotspot\src\os\windows\vm\os_windows.cpp: 3844 >> >> On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >>> Thank you Daniel! >>> >>> Please find the updated webrev with your suggestions incorporated here: >>> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >>> >>> Concerning the thread priority: If the application is of >>> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >>> THREAD_PRIORITY_HIGHEST will result in its priority value to be only >>> 10 (of maximum 31). >>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs. >>> 85).aspx >>> >>> >>> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >>> HIGHEST priority level will have priority value == 15 of 31. >>> >>> I believe, it should not be too much, and the machine will not become >>> busy with only those closing threads. >>> However, I hope it would be enough to make them complete faster than >>> other threads of the NORMAL priority level withing the same >>> application. >> I don't think this is necessary or desirable. Under normal usage >> we're giving priority to exiting threads and that may disrupt the >> usual scheduling patterns that applications see. You may posit that >> it is "harmless" but we can't say that for sure. Nor can we actually >> know that this will help with this particular bug. I would not add in >> this new code. >> >> David >> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>>> Hello! >>>>> >>>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>>> for exiting threads [win]) caused the warning message to be printed >>>>> in some test environments: >>>>> ----------- >>>>> os_windows.cpp:3844 is in the newly updated >>>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>>> ----------- >>>>> >>>>> This has been observed with debug builds on highly loaded systems. >>>>> >>>>> >>>>> To address the issue it is proposed to do three things: >>>>> 1) increase the timeout for debug builds, >>>>> 2) increase the maximum number of the thread handles to be stored, >>>>> 3) rise the priority of the exiting threads, if we need to wait for >>>>> them. >>>>> >>>>> Would you please help review the fix? >>>>> >>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>>> src/os/windows/vm/os_windows.cpp >>>> >>>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>> >>>> That uses the smaller value for only one build config (PRODUCT). >>>> >>>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) >>>> DEBUG_ONLY(4000) >>>> /*1 sec in product, 4 sec in debug*/ >>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>> Please add spaces between the comment delimiters and the comment >>>> text. >>>> >>>> That uses the smaller timeout for only one build config >>>> (PRODUCT). >>>> >>>> line 3836 // Rise the priority... >>>> Typo: 'Rise' -> 'Raise' >>>> >>>> About the general idea of raising the exiting thread's priority, >>>> if the exiting thread is looping in some Win* OS code after this >>>> point, will raising the priority make the machine unusable? >>>> >>>> Dan >>>> >>>> >>>>> The fix was tested on all available platforms, with the hotspot >>>>> testset. No failures. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>> >>>> >> > From chris.plummer at oracle.com Tue Nov 18 22:08:30 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 18 Nov 2014 14:08:30 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <54641ADE.8030504@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> Message-ID: <546BC35E.4070402@oracle.com> Adding core-libs-dev at openjdk.java.net, since one of the changes is in java.c. Chris On 11/12/14 6:43 PM, David Holmes wrote: > Hi Chris, > > Sorry for the delay. > > On 13/11/2014 5:44 AM, Chris Plummer wrote: >> Hi, >> >> I'm still looking for reviewers. > > As the change is to the launcher it needs to be reviewed by the > launcher owner - which I think is serviceability (though also cc'd > Kumar :) ). > > Launcher change, and your rationale, seems okay to me. I'd probably > put the test in to jdk/test/tools/launcher/ though. > > Thanks, > David > >> thanks, >> >> Chris >> >> On 11/7/14 7:53 PM, Chris Plummer wrote: >>> This is an initial review for 6762191. I'm guessing there will be >>> recommendations to fix in a different way, but thought this would be a >>> good time to start the discussion. >>> >>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>> >>> The bug is that if the -Xss size is set to something very small (like >>> 16k), on linux there will be a crash due to overwriting the end of the >>> stack. This happens before hotspot can compute its stack needs and >>> verify that the stack is big enough. >>> >>> It didn't seem viable to move the hotspot stack size check earlier. It >>> depends on too much other work done before that point, and the changes >>> would have been disruptive. The stack size check is currently done in >>> os::init_2(). >>> >>> What is needed is a check before the thread is created. That way we >>> can create a thread with a big enough stack to handle all needs up to >>> the point of the check in os::init_2(). This initial check does not >>> need to be the final check. It just needs to confirm that we have >>> enough stack to get us to the check in os::init_2(). >>> >>> I decided to check in java.c if the -Xss size is too small, and set it >>> to a larger size if it is. I hard coded this size to 32k (I'll explain >>> why 32k later). I suspect this is the part that will result in some >>> debate. If you have better suggestions let me know. If it does stay >>> here, then probably the 32k needs to be a #define, and maybe even an >>> OS porting interface, but I'm not sure where to put it. >>> >>> The reason I chose 32k is because this is big enough for all platforms >>> to get to the stack size check in os::init_2(). It is also smaller >>> than the actual minimum stack size allowed on any platform. 32-bit >>> windows has the smallest requirement at 64k. I add some printfs to >>> print the minimum stack requirement, and then ran a simple JTReg test >>> with every JPRT supported platform to get the results. >>> >>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>> -Xss32k, and -XXss, where is the size from the >>> error message produced by the JVM, such as in the following: >>> >>> $ java -Xss32k -version >>> The stack size specified is too small, Specify at least 100k >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> I ran this test through JPRT on all platforms, and they all pass. >>> >>> One thing to point out is that Windows behaves a bit different than >>> the other platforms. It always rounds the stack size up to a multiple >>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>> 32-bit Windows with C1, 64k is also the minimum requirement, so there >>> is no error produced in this case. However, on 32-bit Windows with C2, >>> 68k is the minimum, so an error is produced since the stack will only >>> be 64k. There is no bug here. It's just a bit confusing. >>> >>> thanks, >>> >>> Chris >> From david.holmes at oracle.com Wed Nov 19 01:47:45 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Nov 2014 11:47:45 +1000 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <54638FA5.5000505@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> <54638012.3010202@oracle.com> <546385BB.3080801@oracle.com> <54638FA5.5000505@oracle.com> Message-ID: <546BF6C1.2090607@oracle.com> In case you are still waiting this all looks fine to me. Thanks, David On 13/11/2014 2:49 AM, Evgeniya Stepanova wrote: > Forgotten copyrights were changed > http://cr.openjdk.java.net/~eistepan/8062536/webrev.04/ > > On 12.11.2014 20:07, Evgeniya Stepanova wrote: >> Hi Bengt, >> >> Please see comments inline >> On 12.11.2014 19:43, Bengt Rutisson wrote: >>> >>> On 2014-11-12 16:21, Evgeniya Stepanova wrote: >>>> Hi everyone! >>>> >>>> Since the decision was made to change only tests which fail because >>>> of conflict for now (skip "selfish" tests), I post new webrev for >>>> jdk part of the JDK-8019361 >>>> : >>>> http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ >>> >>> Thanks for updating the webrev! >>> >>> A couple of comments: >>> >>> MemoryTestAllGC.sh >>> >>> The test is run three times, once with no params, once with >>> ParallelGC and once with CMS. So, I think the @requires should just >>> be vm.gc == "null". Similarly to what was done for PendingAllGC.sh. >>> >> The third run (with CMS) is commented. Without this run UseParallelGC >> is valid option >> #runOne -XX:+UseConcMarkSweepGC MemoryTest 3 >> (http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html) >>> >>> TestInputArgument.sh >>> >>> The changes here seem unrelated to @requires. >>> >> This test was changed after conversation with David Holmes (see >> thread below) >>> >>> EnqueuePollRace.java >>> >>> Can you explain why it is safe to remove -XX:+UseSerialGC for this test? >>> >>> >> This test was modified after conversation with Filipp Zhinkin and >> Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723) >>> JpsHelper.java >>> >>> Can you explain why it is safe to remvoe -XX:+UseParallelGC for this >>> test? >>> >> This test was changed after conversation with Katja Kantserova (see >> thread below), GC flag is just an arbitrary chosen test flag >>> >>> When I use Aurora to check what tests that currently are considered >>> known because of JDK-8019361 I get a pretty long list: >>> >>> http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 >>> >>> Are the tests in webrev.03 the only tests that still fail? Have the >>> others been fixed in other ways? >> There would be 2 more changes in reviews in closed part :) >> >> Thanks, >> Evgeniya Stepanova >>> >>> Thanks, >>> Bengt >>> >>> >>> >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> On 07.11.2014 15:34, Evgeniya Stepanova wrote: >>>>> David, Filipp, Katja >>>>> >>>>> Diff have been updated one more time: >>>>> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >>>>> test/java/lang/ref/EnqueuePollRace.java have been changed >>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>>>> >>>>> Thanks >>>>> >>>>> On 07.11.2014 9:37, David Holmes wrote: >>>>>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>>>>> >>>>>> In: >>>>>> >>>>>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>>>>> >>>>>> the use of the gc options seems incidental - it's just picking two >>>>>> innocuous options to use - similar to the JpsHelper case. You >>>>>> could replace +UseParallelGC with something like >>>>>> +UseFastJNIAccessors (platform independent and normally true). >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>>>>> Thanks a lot! >>>>>>>> >>>>>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>>>>> Hi Katja, >>>>>>>>> >>>>>>>>> Ok, this seems to be a perfect solution. Thank you. I'll change >>>>>>>>> the >>>>>>>>> diff accordingly. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Evgeniya Stepanova >>>>>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>>>>> Hi Dima, >>>>>>>>>> >>>>>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>>>>> Hi Katja, >>>>>>>>>>> >>>>>>>>>>> You are right, there will be no conflict, because test >>>>>>>>>>> ignores any >>>>>>>>>>> external VM flags. >>>>>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>>>>> >>>>>>>>>>> Ignoring external options is bad thing, such "selfish" tests are >>>>>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>>>>> >>>>>>>>>> This particular case is to test the defined flags are shown up as >>>>>>>>>> expected. >>>>>>>>>> >>>>>>>>>> Evgeniya, >>>>>>>>>> >>>>>>>>>> would you mind to change JpsHelper.java instead? >>>>>>>>>> >>>>>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>>>>> @@ -93,7 +93,7 @@ >>>>>>>>>> /** >>>>>>>>>> * VM arguments to start test application with >>>>>>>>>> */ >>>>>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>> "-XX:+PrintGCDetails"}; >>>>>>>>>> /** >>>>>>>>>> * VM flag to start test application with >>>>>>>>>> */ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Katja >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>>>>> options without any risk of bumping into conflict and extend >>>>>>>>>>> area >>>>>>>>>>> of test applicability. >>>>>>>>>>> >>>>>>>>>>> But if you still believe, that @requires is not necessary - it's >>>>>>>>>>> not a problem, tests could be kept as is. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dima >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>> >>>>>>>>>>>> As David has pointed out these jps tests are not testing gc. >>>>>>>>>>>> The >>>>>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. There >>>>>>>>>>>> should not be any conflicts either since these tests are >>>>>>>>>>>> running >>>>>>>>>>>> in driver mode: >>>>>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> * @run driver TestJpsJar >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> which means no flags from above are accepted. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Katja >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> tag added because tests contain string >>>>>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>>>>> >>>>>>>>>>>>> and JpsHelper defines >>>>>>>>>>>>> ... >>>>>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>>>> ... >>>>>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>>>>> } >>>>>>>>>>>>> return testVmArgs; >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag added for >>>>>>>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>>>>>>> tests >>>>>>>>>>>>> passed with this GC, not with another one. Now you will assume >>>>>>>>>>>>> that concrete test passed with Serial GC, but it run only with >>>>>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice >>>>>>>>>>>>> in TC >>>>>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part >>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>>>>> fix: http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when >>>>>>>>>>>>>>> another GC >>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>> outside >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>>>>> >>>>>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Solution: Such tests marked with the jtreg tag "requires" to >>>>>>>>>>>>>>> skip test >>>>>>>>>>>>>>> if there is a conflict >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file >>>>>>>>>>>>>> showing it >>>>>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>>>>> jtreg log? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, >>>>>>>>>>>>>>> -XX:+UseConcMarkSweep and >>>>>>>>>>>>>>> without >>>>>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No tests >>>>>>>>>>>>>>> failed >>>>>>>>>>>>>>> because of the conflict. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> /Evgeniya Stepanova/ >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> /Evgeniya Stepanova/ >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >> >> -- >> /Evgeniya Stepanova/ > > -- > /Evgeniya Stepanova/ From evgeniya.stepanova at oracle.com Wed Nov 19 08:45:32 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Wed, 19 Nov 2014 12:45:32 +0400 Subject: Fwd: Re: RFR: 8062536: [TESTBUG] Conflicting GC combinations in jdk tests In-Reply-To: <546BF6C1.2090607@oracle.com> References: <545B4D0C.2010005@oracle.com> <545B51A1.7080905@oracle.com> <545B4BF6.4040209@oracle.com> <545B7006.5080104@oracle.com> <545B722C.3020406@oracle.com> <545B793D.5000008@oracle.com> <545B8777.6080403@oracle.com> <545C5AB6.6030103@oracle.com> <545CAE30.9010708@oracle.com> <54637AF5.9080600@oracle.com> <54638012.3010202@oracle.com> <546385BB.3080801@oracle.com> <54638FA5.5000505@oracle.com> <546BF6C1.2090607@oracle.com> Message-ID: <546C58AC.3070401@oracle.com> Hi David! Thank you very much for the review! On 19.11.2014 5:47, David Holmes wrote: > In case you are still waiting this all looks fine to me. > > Thanks, > David > > On 13/11/2014 2:49 AM, Evgeniya Stepanova wrote: >> Forgotten copyrights were changed >> http://cr.openjdk.java.net/~eistepan/8062536/webrev.04/ >> >> On 12.11.2014 20:07, Evgeniya Stepanova wrote: >>> Hi Bengt, >>> >>> Please see comments inline >>> On 12.11.2014 19:43, Bengt Rutisson wrote: >>>> >>>> On 2014-11-12 16:21, Evgeniya Stepanova wrote: >>>>> Hi everyone! >>>>> >>>>> Since the decision was made to change only tests which fail because >>>>> of conflict for now (skip "selfish" tests), I post new webrev for >>>>> jdk part of the JDK-8019361 >>>>> : >>>>> http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/ >>>> >>>> Thanks for updating the webrev! >>>> >>>> A couple of comments: >>>> >>>> MemoryTestAllGC.sh >>>> >>>> The test is run three times, once with no params, once with >>>> ParallelGC and once with CMS. So, I think the @requires should just >>>> be vm.gc == "null". Similarly to what was done for PendingAllGC.sh. >>>> >>> The third run (with CMS) is commented. Without this run UseParallelGC >>> is valid option >>> #runOne -XX:+UseConcMarkSweepGC MemoryTest 3 >>> (http://cr.openjdk.java.net/~avstepan/eistepan/8062536/webrev.03/test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh.frames.html) >>> >>>> >>>> TestInputArgument.sh >>>> >>>> The changes here seem unrelated to @requires. >>>> >>> This test was changed after conversation with David Holmes (see >>> thread below) >>>> >>>> EnqueuePollRace.java >>>> >>>> Can you explain why it is safe to remove -XX:+UseSerialGC for this >>>> test? >>>> >>>> >>> This test was modified after conversation with Filipp Zhinkin and >>> Mandy Chung (https://bugs.openjdk.java.net/browse/JDK-8051723) >>>> JpsHelper.java >>>> >>>> Can you explain why it is safe to remvoe -XX:+UseParallelGC for this >>>> test? >>>> >>> This test was changed after conversation with Katja Kantserova (see >>> thread below), GC flag is just an arbitrary chosen test flag >>>> >>>> When I use Aurora to check what tests that currently are considered >>>> known because of JDK-8019361 I get a pretty long list: >>>> >>>> http://aurora.ru.oracle.com/functional/faces/CRRules.xhtml?cr=JDK-8019361 >>>> >>>> >>>> Are the tests in webrev.03 the only tests that still fail? Have the >>>> others been fixed in other ways? >>> There would be 2 more changes in reviews in closed part :) >>> >>> Thanks, >>> Evgeniya Stepanova >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> On 07.11.2014 15:34, Evgeniya Stepanova wrote: >>>>>> David, Filipp, Katja >>>>>> >>>>>> Diff have been updated one more time: >>>>>> java/lang/management/RuntimeMXBean/TestInputArgument.sh and >>>>>> test/java/lang/ref/EnqueuePollRace.java have been changed >>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.02/ >>>>>> >>>>>> Thanks >>>>>> >>>>>> On 07.11.2014 9:37, David Holmes wrote: >>>>>>> On 7/11/2014 12:36 AM, Evgeniya Stepanova wrote: >>>>>>>> New webrev: >>>>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.01/ >>>>>>> >>>>>>> In: >>>>>>> >>>>>>> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh >>>>>>> >>>>>>> the use of the gc options seems incidental - it's just picking two >>>>>>> innocuous options to use - similar to the JpsHelper case. You >>>>>>> could replace +UseParallelGC with something like >>>>>>> +UseFastJNIAccessors (platform independent and normally true). >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> On 06.11.2014 17:35, Yekaterina Kantserova wrote: >>>>>>>>> Thanks a lot! >>>>>>>>> >>>>>>>>> On 11/06/2014 02:05 PM, Evgeniya Stepanova wrote: >>>>>>>>>> Hi Katja, >>>>>>>>>> >>>>>>>>>> Ok, this seems to be a perfect solution. Thank you. I'll change >>>>>>>>>> the >>>>>>>>>> diff accordingly. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Evgeniya Stepanova >>>>>>>>>> On 06.11.2014 16:56, Yekaterina Kantserova wrote: >>>>>>>>>>> Hi Dima, >>>>>>>>>>> >>>>>>>>>>> On 11/06/2014 11:22 AM, Dmitry Fazunenko wrote: >>>>>>>>>>>> Hi Katja, >>>>>>>>>>>> >>>>>>>>>>>> You are right, there will be no conflict, because test >>>>>>>>>>>> ignores any >>>>>>>>>>>> external VM flags. >>>>>>>>>>>> So, adding @requires seems unnecessary here, but... >>>>>>>>>>>> >>>>>>>>>>>> Ignoring external options is bad thing, such "selfish" >>>>>>>>>>>> tests are >>>>>>>>>>>> not applicable for other areas, like GC, compiler, RT. >>>>>>>>>>> >>>>>>>>>>> This particular case is to test the defined flags are shown >>>>>>>>>>> up as >>>>>>>>>>> expected. >>>>>>>>>>> >>>>>>>>>>> Evgeniya, >>>>>>>>>>> >>>>>>>>>>> would you mind to change JpsHelper.java instead? >>>>>>>>>>> >>>>>>>>>>> +++ b/test/sun/tools/jps/JpsHelper.java >>>>>>>>>>> @@ -93,7 +93,7 @@ >>>>>>>>>>> /** >>>>>>>>>>> * VM arguments to start test application with >>>>>>>>>>> */ >>>>>>>>>>> - public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>> + public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>> "-XX:+PrintGCDetails"}; >>>>>>>>>>> /** >>>>>>>>>>> * VM flag to start test application with >>>>>>>>>>> */ >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Katja >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> @requires will allow to modify tests to include external vm >>>>>>>>>>>> options without any risk of bumping into conflict and extend >>>>>>>>>>>> area >>>>>>>>>>>> of test applicability. >>>>>>>>>>>> >>>>>>>>>>>> But if you still believe, that @requires is not necessary - >>>>>>>>>>>> it's >>>>>>>>>>>> not a problem, tests could be kept as is. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dima >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 06.11.2014 16:27, Yekaterina Kantserova wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>>> >>>>>>>>>>>>> As David has pointed out these jps tests are not testing gc. >>>>>>>>>>>>> The >>>>>>>>>>>>> -XX:+UseParallelGC is just an arbitrary chosen test flag. >>>>>>>>>>>>> There >>>>>>>>>>>>> should not be any conflicts either since these tests are >>>>>>>>>>>>> running >>>>>>>>>>>>> in driver mode: >>>>>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> * @run driver TestJpsJar >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> which means no flags from above are accepted. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Katja >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/06/2014 11:05 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> tag added because tests contain string >>>>>>>>>>>>>> cmd.addAll(JpsHelper.getVmArgs()); >>>>>>>>>>>>>> >>>>>>>>>>>>>> and JpsHelper defines >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> public static final String[] VM_ARGS = {"-Xmx512m", >>>>>>>>>>>>>> "-XX:+UseParallelGC"}; >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> public static List getVmArgs() throws IOException { >>>>>>>>>>>>>> if (testVmArgs == null) { >>>>>>>>>>>>>> testVmArgs = new ArrayList<>(); >>>>>>>>>>>>>> testVmArgs.addAll(Arrays.asList(VM_ARGS)); >>>>>>>>>>>>>> testVmArgs.add("-XX:Flags=" + >>>>>>>>>>>>>> getVmFlagsFile().getAbsolutePath()); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> return testVmArgs; >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tests itself wouldn't fail if we use another GC, tag >>>>>>>>>>>>>> added for >>>>>>>>>>>>>> cleanup-if we use for example SerialGC we must be sure that >>>>>>>>>>>>>> tests >>>>>>>>>>>>>> passed with this GC, not with another one. Now you will >>>>>>>>>>>>>> assume >>>>>>>>>>>>>> that concrete test passed with Serial GC, but it run only >>>>>>>>>>>>>> with >>>>>>>>>>>>>> Parallel GC. Plus there is no any sense to run test twice >>>>>>>>>>>>>> in TC >>>>>>>>>>>>>> (with different GC, since it use only Parallel) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>>> On 06.11.2014 6:20, David Holmes wrote: >>>>>>>>>>>>>>> Hi Evgeniya, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6/11/2014 1:33 AM, Evgeniya Stepanova wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review changes for 8062536, the OpenJDK/jdk part >>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>> JDK-8019361 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062536 >>>>>>>>>>>>>>>> fix: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/8062536/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Problem: Some tests explicitly set GC and fail when >>>>>>>>>>>>>>>> another GC >>>>>>>>>>>>>>>> is set >>>>>>>>>>>>>>>> outside >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't see why you have done this for the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> test/sun/tools/jps/TestJps*.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tests. They don't set any GC flags. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Solution: Such tests marked with the jtreg tag >>>>>>>>>>>>>>>> "requires" to >>>>>>>>>>>>>>>> skip test >>>>>>>>>>>>>>>> if there is a conflict >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just wondering: Does a skipped test get a .jtr file >>>>>>>>>>>>>>> showing it >>>>>>>>>>>>>>> was skipped; or does it only appear in the higher-level >>>>>>>>>>>>>>> jtreg log? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tested locally with different GC flags (-XX:+UseG1GC, >>>>>>>>>>>>>>>> -XX:+UseParallelGC, -XX:+UseSerialGC, >>>>>>>>>>>>>>>> -XX:+UseConcMarkSweep and >>>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>> any GC flag). Tests are being excluded as expected. No >>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>> failed >>>>>>>>>>>>>>>> because of the conflict. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Evgeniya Stepanova >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> // >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> /Evgeniya Stepanova/ >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> /Evgeniya Stepanova/ >>>>>> >>>>>> -- >>>>>> /Evgeniya Stepanova/ >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>>> >>> >>> -- >>> /Evgeniya Stepanova/ >> >> -- >> /Evgeniya Stepanova/ -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Nov 19 08:49:10 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 19 Nov 2014 00:49:10 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <546BC35E.4070402@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> Message-ID: <546C5986.6010500@oracle.com> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k references, and also moved the test from hotspot/test/runtime to jdk/test/tools/launcher as David requested. That required some adjustments to the test script, since test_env.sh does not exist in jdk/test, so I had to pull in the bits I needed into the script. http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ I still need to rerun through JPRT. I'll do so once there are no more suggested changes. thanks, Chris On 11/18/14 2:08 PM, Chris Plummer wrote: > Adding core-libs-dev at openjdk.java.net, since one of the changes is in > java.c. > > Chris > > On 11/12/14 6:43 PM, David Holmes wrote: >> Hi Chris, >> >> Sorry for the delay. >> >> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>> Hi, >>> >>> I'm still looking for reviewers. >> >> As the change is to the launcher it needs to be reviewed by the >> launcher owner - which I think is serviceability (though also cc'd >> Kumar :) ). >> >> Launcher change, and your rationale, seems okay to me. I'd probably >> put the test in to jdk/test/tools/launcher/ though. >> >> Thanks, >> David >> >>> thanks, >>> >>> Chris >>> >>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>> This is an initial review for 6762191. I'm guessing there will be >>>> recommendations to fix in a different way, but thought this would be a >>>> good time to start the discussion. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>> >>>> The bug is that if the -Xss size is set to something very small (like >>>> 16k), on linux there will be a crash due to overwriting the end of the >>>> stack. This happens before hotspot can compute its stack needs and >>>> verify that the stack is big enough. >>>> >>>> It didn't seem viable to move the hotspot stack size check earlier. It >>>> depends on too much other work done before that point, and the changes >>>> would have been disruptive. The stack size check is currently done in >>>> os::init_2(). >>>> >>>> What is needed is a check before the thread is created. That way we >>>> can create a thread with a big enough stack to handle all needs up to >>>> the point of the check in os::init_2(). This initial check does not >>>> need to be the final check. It just needs to confirm that we have >>>> enough stack to get us to the check in os::init_2(). >>>> >>>> I decided to check in java.c if the -Xss size is too small, and set it >>>> to a larger size if it is. I hard coded this size to 32k (I'll explain >>>> why 32k later). I suspect this is the part that will result in some >>>> debate. If you have better suggestions let me know. If it does stay >>>> here, then probably the 32k needs to be a #define, and maybe even an >>>> OS porting interface, but I'm not sure where to put it. >>>> >>>> The reason I chose 32k is because this is big enough for all platforms >>>> to get to the stack size check in os::init_2(). It is also smaller >>>> than the actual minimum stack size allowed on any platform. 32-bit >>>> windows has the smallest requirement at 64k. I add some printfs to >>>> print the minimum stack requirement, and then ran a simple JTReg test >>>> with every JPRT supported platform to get the results. >>>> >>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>> -Xss32k, and -XXss, where is the size from the >>>> error message produced by the JVM, such as in the following: >>>> >>>> $ java -Xss32k -version >>>> The stack size specified is too small, Specify at least 100k >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> I ran this test through JPRT on all platforms, and they all pass. >>>> >>>> One thing to point out is that Windows behaves a bit different than >>>> the other platforms. It always rounds the stack size up to a multiple >>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>> 32-bit Windows with C1, 64k is also the minimum requirement, so there >>>> is no error produced in this case. However, on 32-bit Windows with C2, >>>> 68k is the minimum, so an error is produced since the stack will only >>>> be 64k. There is no bug here. It's just a bit confusing. >>>> >>>> thanks, >>>> >>>> Chris >>> > From serguei.spitsyn at oracle.com Wed Nov 19 08:54:48 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 19 Nov 2014 00:54:48 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <546C5986.6010500@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> Message-ID: <546C5AD8.2090701@oracle.com> Reviewed Thanks, Serguei On 11/19/14 12:49 AM, Chris Plummer wrote: > I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k > references, and also moved the test from hotspot/test/runtime to > jdk/test/tools/launcher as David requested. That required some > adjustments to the test script, since test_env.sh does not exist in > jdk/test, so I had to pull in the bits I needed into the script. > > http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ > > I still need to rerun through JPRT. I'll do so once there are no more > suggested changes. > > thanks, > > Chris > > On 11/18/14 2:08 PM, Chris Plummer wrote: >> Adding core-libs-dev at openjdk.java.net, since one of the changes is in >> java.c. >> >> Chris >> >> On 11/12/14 6:43 PM, David Holmes wrote: >>> Hi Chris, >>> >>> Sorry for the delay. >>> >>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>> Hi, >>>> >>>> I'm still looking for reviewers. >>> >>> As the change is to the launcher it needs to be reviewed by the >>> launcher owner - which I think is serviceability (though also cc'd >>> Kumar :) ). >>> >>> Launcher change, and your rationale, seems okay to me. I'd probably >>> put the test in to jdk/test/tools/launcher/ though. >>> >>> Thanks, >>> David >>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>> This is an initial review for 6762191. I'm guessing there will be >>>>> recommendations to fix in a different way, but thought this would >>>>> be a >>>>> good time to start the discussion. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>> >>>>> The bug is that if the -Xss size is set to something very small (like >>>>> 16k), on linux there will be a crash due to overwriting the end of >>>>> the >>>>> stack. This happens before hotspot can compute its stack needs and >>>>> verify that the stack is big enough. >>>>> >>>>> It didn't seem viable to move the hotspot stack size check >>>>> earlier. It >>>>> depends on too much other work done before that point, and the >>>>> changes >>>>> would have been disruptive. The stack size check is currently done in >>>>> os::init_2(). >>>>> >>>>> What is needed is a check before the thread is created. That way we >>>>> can create a thread with a big enough stack to handle all needs up to >>>>> the point of the check in os::init_2(). This initial check does not >>>>> need to be the final check. It just needs to confirm that we have >>>>> enough stack to get us to the check in os::init_2(). >>>>> >>>>> I decided to check in java.c if the -Xss size is too small, and >>>>> set it >>>>> to a larger size if it is. I hard coded this size to 32k (I'll >>>>> explain >>>>> why 32k later). I suspect this is the part that will result in some >>>>> debate. If you have better suggestions let me know. If it does stay >>>>> here, then probably the 32k needs to be a #define, and maybe even an >>>>> OS porting interface, but I'm not sure where to put it. >>>>> >>>>> The reason I chose 32k is because this is big enough for all >>>>> platforms >>>>> to get to the stack size check in os::init_2(). It is also smaller >>>>> than the actual minimum stack size allowed on any platform. 32-bit >>>>> windows has the smallest requirement at 64k. I add some printfs to >>>>> print the minimum stack requirement, and then ran a simple JTReg test >>>>> with every JPRT supported platform to get the results. >>>>> >>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>> -Xss32k, and -XXss, where is the size from the >>>>> error message produced by the JVM, such as in the following: >>>>> >>>>> $ java -Xss32k -version >>>>> The stack size specified is too small, Specify at least 100k >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> I ran this test through JPRT on all platforms, and they all pass. >>>>> >>>>> One thing to point out is that Windows behaves a bit different than >>>>> the other platforms. It always rounds the stack size up to a multiple >>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so there >>>>> is no error produced in this case. However, on 32-bit Windows with >>>>> C2, >>>>> 68k is the minimum, so an error is produced since the stack will only >>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>> >> > From david.holmes at oracle.com Wed Nov 19 10:12:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Nov 2014 20:12:42 +1000 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <546C5986.6010500@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> Message-ID: <546C6D1A.8050903@oracle.com> On 19/11/2014 6:49 PM, Chris Plummer wrote: > I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k > references, and also moved the test from hotspot/test/runtime to > jdk/test/tools/launcher as David requested. That required some > adjustments to the test script, since test_env.sh does not exist in > jdk/test, so I had to pull in the bits I needed into the script. Is there a reason this needs a shell script instead of using the testlibrary tools to launch the VM and check the output? Sorry that should have been mentioned much earlier. David > http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ > > I still need to rerun through JPRT. I'll do so once there are no more > suggested changes. > > thanks, > > Chris > > On 11/18/14 2:08 PM, Chris Plummer wrote: >> Adding core-libs-dev at openjdk.java.net, since one of the changes is in >> java.c. >> >> Chris >> >> On 11/12/14 6:43 PM, David Holmes wrote: >>> Hi Chris, >>> >>> Sorry for the delay. >>> >>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>> Hi, >>>> >>>> I'm still looking for reviewers. >>> >>> As the change is to the launcher it needs to be reviewed by the >>> launcher owner - which I think is serviceability (though also cc'd >>> Kumar :) ). >>> >>> Launcher change, and your rationale, seems okay to me. I'd probably >>> put the test in to jdk/test/tools/launcher/ though. >>> >>> Thanks, >>> David >>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>> This is an initial review for 6762191. I'm guessing there will be >>>>> recommendations to fix in a different way, but thought this would be a >>>>> good time to start the discussion. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>> >>>>> The bug is that if the -Xss size is set to something very small (like >>>>> 16k), on linux there will be a crash due to overwriting the end of the >>>>> stack. This happens before hotspot can compute its stack needs and >>>>> verify that the stack is big enough. >>>>> >>>>> It didn't seem viable to move the hotspot stack size check earlier. It >>>>> depends on too much other work done before that point, and the changes >>>>> would have been disruptive. The stack size check is currently done in >>>>> os::init_2(). >>>>> >>>>> What is needed is a check before the thread is created. That way we >>>>> can create a thread with a big enough stack to handle all needs up to >>>>> the point of the check in os::init_2(). This initial check does not >>>>> need to be the final check. It just needs to confirm that we have >>>>> enough stack to get us to the check in os::init_2(). >>>>> >>>>> I decided to check in java.c if the -Xss size is too small, and set it >>>>> to a larger size if it is. I hard coded this size to 32k (I'll explain >>>>> why 32k later). I suspect this is the part that will result in some >>>>> debate. If you have better suggestions let me know. If it does stay >>>>> here, then probably the 32k needs to be a #define, and maybe even an >>>>> OS porting interface, but I'm not sure where to put it. >>>>> >>>>> The reason I chose 32k is because this is big enough for all platforms >>>>> to get to the stack size check in os::init_2(). It is also smaller >>>>> than the actual minimum stack size allowed on any platform. 32-bit >>>>> windows has the smallest requirement at 64k. I add some printfs to >>>>> print the minimum stack requirement, and then ran a simple JTReg test >>>>> with every JPRT supported platform to get the results. >>>>> >>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>> -Xss32k, and -XXss, where is the size from the >>>>> error message produced by the JVM, such as in the following: >>>>> >>>>> $ java -Xss32k -version >>>>> The stack size specified is too small, Specify at least 100k >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> I ran this test through JPRT on all platforms, and they all pass. >>>>> >>>>> One thing to point out is that Windows behaves a bit different than >>>>> the other platforms. It always rounds the stack size up to a multiple >>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so there >>>>> is no error produced in this case. However, on 32-bit Windows with C2, >>>>> 68k is the minimum, so an error is produced since the stack will only >>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>> >> > From markus.gronlund at oracle.com Wed Nov 19 14:28:00 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 19 Nov 2014 06:28:00 -0800 (PST) Subject: RFR(S): 8065361: Fixup headers and definitions for INCLUDE_TRACE Message-ID: Greetings, ? Kindly asking for reviews for the following changeset to clean up the usage of the INCLUDE_TRACE define: ? Bug: https://bugs.openjdk.java.net/browse/JDK-8065361 Webrev: http://cr.openjdk.java.net/~mgronlun/8065361/webrev01/ ? Description: #include "utilities/macros.hpp" for every compilation unit using INCLUDE_TRACE. Header include guards comments updated to C++ style. ? Thanks in advance Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Wed Nov 19 14:37:19 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 19 Nov 2014 15:37:19 +0100 Subject: RFR(S): 8065361: Fixup headers and definitions for INCLUDE_TRACE In-Reply-To: References: Message-ID: <546CAB1F.5030104@oracle.com> On 2014-11-19 15:28, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for reviews for the following changeset to clean up the > usage of the INCLUDE_TRACE define: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065361 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8065361/webrev01/ > > > Description: > > #include ?utilities/macros.hpp? for every compilation unit using > INCLUDE_TRACE. Header include guards comments updated to C++ style. > Looks good. Thanks, StefanK > Thanks in advance > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Nov 19 14:55:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 19 Nov 2014 15:55:58 +0100 Subject: RFR(S): 8065361: Fixup headers and definitions for INCLUDE_TRACE In-Reply-To: References: Message-ID: Looks good! Thanks, /Staffan > On 19 nov 2014, at 15:28, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for reviews for the following changeset to clean up the usage of the INCLUDE_TRACE define: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065361 > Webrev: http://cr.openjdk.java.net/~mgronlun/8065361/webrev01/ > > Description: > #include ?utilities/macros.hpp? for every compilation unit using INCLUDE_TRACE. Header include guards comments updated to C++ style. > > Thanks in advance > Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Wed Nov 19 15:02:09 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 19 Nov 2014 07:02:09 -0800 (PST) Subject: RFR(S): 8065361: Fixup headers and definitions for INCLUDE_TRACE In-Reply-To: References: Message-ID: <8a9cdebe-1841-47ee-b6c3-35269d80b4f6@default> Thanks Stefan and Staffan for reviewing! ? /Markus ? From: Staffan Larsen Sent: den 19 november 2014 15:56 To: Markus Gr?nlund Cc: serviceability-dev at openjdk.java.net; Stefan Karlsson Subject: Re: RFR(S): 8065361: Fixup headers and definitions for INCLUDE_TRACE ? Looks good! ? Thanks, /Staffan ? ? On 19 nov 2014, at 15:28, Markus Gr?nlund wrote: ? Greetings, ? Kindly asking for reviews for the following changeset to clean up the usage of the INCLUDE_TRACE define: ? Bug:?https://bugs.openjdk.java.net/browse/JDK-8065361 Webrev:?http://cr.openjdk.java.net/~mgronlun/8065361/webrev01/ ? Description: #include "utilities/macros.hpp" for every compilation unit using INCLUDE_TRACE. Header include guards comments updated to C++ style. ? Thanks in advance Markus ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Nov 19 15:52:11 2014 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 19 Nov 2014 07:52:11 -0800 Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault In-Reply-To: <546C6D1A.8050903@oracle.com> References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com> <54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com> <546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com> Message-ID: <546CBCAB.7040101@oracle.com> On 11/19/14 2:12 AM, David Holmes wrote: > On 19/11/2014 6:49 PM, Chris Plummer wrote: >> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k >> references, and also moved the test from hotspot/test/runtime to >> jdk/test/tools/launcher as David requested. That required some >> adjustments to the test script, since test_env.sh does not exist in >> jdk/test, so I had to pull in the bits I needed into the script. > > Is there a reason this needs a shell script instead of using the > testlibrary tools to launch the VM and check the output? Not that I'm aware of. I guess I just really didn't look at what it would take to make it all in java. I'll have a look at java examples and convert it. Chris > > Sorry that should have been mentioned much earlier. > > David > > >> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ >> >> I still need to rerun through JPRT. I'll do so once there are no more >> suggested changes. >> >> thanks, >> >> Chris >> >> On 11/18/14 2:08 PM, Chris Plummer wrote: >>> Adding core-libs-dev at openjdk.java.net, since one of the changes is in >>> java.c. >>> >>> Chris >>> >>> On 11/12/14 6:43 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> Sorry for the delay. >>>> >>>> On 13/11/2014 5:44 AM, Chris Plummer wrote: >>>>> Hi, >>>>> >>>>> I'm still looking for reviewers. >>>> >>>> As the change is to the launcher it needs to be reviewed by the >>>> launcher owner - which I think is serviceability (though also cc'd >>>> Kumar :) ). >>>> >>>> Launcher change, and your rationale, seems okay to me. I'd probably >>>> put the test in to jdk/test/tools/launcher/ though. >>>> >>>> Thanks, >>>> David >>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 11/7/14 7:53 PM, Chris Plummer wrote: >>>>>> This is an initial review for 6762191. I'm guessing there will be >>>>>> recommendations to fix in a different way, but thought this would >>>>>> be a >>>>>> good time to start the discussion. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191 >>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/ >>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/ >>>>>> >>>>>> The bug is that if the -Xss size is set to something very small >>>>>> (like >>>>>> 16k), on linux there will be a crash due to overwriting the end >>>>>> of the >>>>>> stack. This happens before hotspot can compute its stack needs and >>>>>> verify that the stack is big enough. >>>>>> >>>>>> It didn't seem viable to move the hotspot stack size check >>>>>> earlier. It >>>>>> depends on too much other work done before that point, and the >>>>>> changes >>>>>> would have been disruptive. The stack size check is currently >>>>>> done in >>>>>> os::init_2(). >>>>>> >>>>>> What is needed is a check before the thread is created. That way we >>>>>> can create a thread with a big enough stack to handle all needs >>>>>> up to >>>>>> the point of the check in os::init_2(). This initial check does not >>>>>> need to be the final check. It just needs to confirm that we have >>>>>> enough stack to get us to the check in os::init_2(). >>>>>> >>>>>> I decided to check in java.c if the -Xss size is too small, and >>>>>> set it >>>>>> to a larger size if it is. I hard coded this size to 32k (I'll >>>>>> explain >>>>>> why 32k later). I suspect this is the part that will result in some >>>>>> debate. If you have better suggestions let me know. If it does stay >>>>>> here, then probably the 32k needs to be a #define, and maybe even an >>>>>> OS porting interface, but I'm not sure where to put it. >>>>>> >>>>>> The reason I chose 32k is because this is big enough for all >>>>>> platforms >>>>>> to get to the stack size check in os::init_2(). It is also smaller >>>>>> than the actual minimum stack size allowed on any platform. 32-bit >>>>>> windows has the smallest requirement at 64k. I add some printfs to >>>>>> print the minimum stack requirement, and then ran a simple JTReg >>>>>> test >>>>>> with every JPRT supported platform to get the results. >>>>>> >>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k, >>>>>> -Xss32k, and -XXss, where is the size from the >>>>>> error message produced by the JVM, such as in the following: >>>>>> >>>>>> $ java -Xss32k -version >>>>>> The stack size specified is too small, Specify at least 100k >>>>>> Error: Could not create the Java Virtual Machine. >>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> I ran this test through JPRT on all platforms, and they all pass. >>>>>> >>>>>> One thing to point out is that Windows behaves a bit different than >>>>>> the other platforms. It always rounds the stack size up to a >>>>>> multiple >>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On >>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so >>>>>> there >>>>>> is no error produced in this case. However, on 32-bit Windows >>>>>> with C2, >>>>>> 68k is the minimum, so an error is produced since the stack will >>>>>> only >>>>>> be 64k. There is no bug here. It's just a bit confusing. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>> >>> >> From staffan.friberg at oracle.com Wed Nov 19 16:23:26 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Wed, 19 Nov 2014 17:23:26 +0100 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <545B6F58.2000907@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> <545B4986.1050700@oracle.com> <545B5520.7010407@oracle.com> <545B70D2.9080008@oracle.com> <545B6F58.2000907@oracle.com> Message-ID: <546CC3FE.7070105@oracle.com> Hi, Erik and Tomas asked me to separate the G1 changes which was pushed separately in JDK-8064473. Erik also had some further comments offline that I have taken care of. Here is the new webrev, cr.openjdk.java.net/~sfriberg/8055845/webrev.06 Thanks, Staffan On 11/06/2014 01:53 PM, Bengt Rutisson wrote: > > > On 2014-11-06 14:00, Staffan Friberg wrote: >> Good catch, fixed. >> >> // Too large; allocate the object individually. >> obj = sp->par_allocate(word_sz); >> if (obj != NULL) { >> gc_tracer()->report_promotion_outside_plab_event(old, word_sz, age, >> false); >> } >> >> Please let me know if anyone wants a full new webrev with this. > > > Looks good. Reviewed. > > Bengt > >> >> Thanks, >> Staffan >> >> >> On 11/06/2014 12:01 PM, Bengt Rutisson wrote: >>> >>> Hi Staffan, >>> >>> On 2014-11-06 11:12, Staffan Friberg wrote: >>>> Hi, >>>> >>>> After further off list discussion it was decided to keep the >>>> gc_tracer in par_promote as is. >>>> >>>> I have uploaded a new webrev, >>>> http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05 >>>> >>>> The main change here is a rewrite of the G1 code which is cleaner >>>> and also reuses the read age. By sending the markOop down through >>>> the call we can now trust the read age and do not need to reread it >>>> when incrementing which improves the YC performance slightly as it >>>> avoids the rather complex bit extraction. >>> >>> >>> Looks good to me. One detail in parNewGeneration.cpp: >>> >>> 274 } else { >>> 275 // Too large; allocate the object individually. >>> 276 gc_tracer()->report_promotion_outside_plab_event(old, word_sz, >>> age, false); >>> 277 obj = sp->par_allocate(word_sz); >>> 278 } >>> >>> Seems like par_allocate() return NULL. Maybe we should check that >>> before reporting the event. Similarly to what you do in the other >>> GCs, for example G1: >>> >>> g1Allocator.cpp >>> >>> 141 obj = _g1h->par_allocate_during_gc(purpose, word_sz, context); >>> 142 if (obj != NULL >>> 143 && >>> _g1h->_gc_tracer_stw->should_report_promotion_outside_plab_event()) { >>> 144 bool tenured = >>> _g1h->heap_region_containing_raw(obj)->is_old(); >>> 145 _g1h->_gc_tracer_stw->report_promotion_outside_plab_event(old, >>> word_sz, >>> 146 age, tenured); >>> 147 } >>> >>> Thanks, >>> Bengt >>> >>> >>> >>>> >>>> Cheers, >>>> Staffan >>>> >>>> On 09/15/2014 02:06 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi Staffan, >>>>> >>>>> psPromotionManager.inline.hpp >>>>> >>>>> I think the PSPromotionManager::copy_to_survivor_space() might >>>>> send multiple events. If the allocation to the young gen fails we >>>>> will fall through to do an old gen allocation. But we send the >>>>> events before we realize that the allocation has failed, i.e. >>>>> new_obj is NULL. >>>>> >>>>> I talked to Erik a bit about how to handle the gc_tracer in >>>>> par_promote. He'll get back to you with some thoughts on that. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> On 2014-09-06 00:20, Staffan Friberg wrote: >>>>>> Hi, >>>>>> >>>>>> I have uploaded a new webrev here, >>>>>> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >>>>>> >>>>>> It contains several changes >>>>>> >>>>>> - Split event into two events (PromoteObjectInNewPLAB, >>>>>> PromoteObjectOutsidePLAB) >>>>>> - Moved events to "vm/gc/detailed/PromoteObject..." >>>>>> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >>>>>> - Not sure if the way I do it with passing the >>>>>> ParNewTracer is the best solution, please let me know if you have >>>>>> an idea how to improve it >>>>>> - Simplified the G1 code to avoid sending age and having a >>>>>> single call site >>>>>> - Fixed so that the generated event has size information in >>>>>> bytes rather than words >>>>>> >>>>>> Thanks for offline comments and suggestions from Dmitry and Thomas. >>>>>> >>>>>> Cheers, >>>>>> Staffan >>>>>> >>>>>> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>>>>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net >>>>>>>> somewhere in this thread, I'm adding it back) >>>>>>>> >>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>> Hi Erik, >>>>>>>>> >>>>>>>>> Thanks for the comments. >>>>>>>>>> - Aren't the events for promotion to the tenured generation >>>>>>>>>> (SerialOld) >>>>>>>>>> and the CMS generation missing? >>>>>>>>> The reason for leaving out these two, Serial completely and CMS >>>>>>>>> promotion, was due to that neither as far as I understand make >>>>>>>>> use of >>>>>>>>> PLABs. >>>>>>>> >>>>>>>> I might be wrong here, but looking at the function >>>>>>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it >>>>>>>> looks to me like SerialOld is using PLABs when ParNew is >>>>>>>> promoting objects from young to old. >>>>>>>> >>>>>>>> As for CMS, looking at >>>>>>>> ConcurrentMarkSweepGeneration::par_promote (in >>>>>>>> concurrentMarkSweepGeneration.cpp) it seems like each >>>>>>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace >>>>>>>> Local Allocation Buffer) that is a thread-local allocation >>>>>>>> buffer. See compactibleFreeListSpace.{hpp,cpp} for more details. >>>>>>>> >>>>>>>> Given this, I think we should add events for Serial and CMS as >>>>>>>> well. >>>>>>>> >>>>>>> >>>>>>> Ok I see what you mean with CMS, basically the equivalent to >>>>>>> getting a PLAB would be when we refill the CFLS_LAB in the alloc >>>>>>> function. It still does the allocation to a small memory (~ size >>>>>>> of object) area from the freelist, but at least we did extra >>>>>>> work to refill the local CFLS_LAB. Need to do some analysis to >>>>>>> see how often we refill so the overhead doesn't get too high. >>>>>>> The only issue I run into is how I can in a nice way get access >>>>>>> to the ParNewTracer from ParNewGeneration to call the report >>>>>>> function. Let's sync up next week and see how it can be solved. >>>>>>> >>>>>>> The tenured GC requires something similar to be supported, >>>>>>> however since ParNewGC is deprecated for usage without CMS in >>>>>>> JDK 8 we might want to skip that combination. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>> - Would it make sense to differentiate, either by separate >>>>>>>>>> events or by >>>>>>>>>> a field in a event, between promotions to to-space and to >>>>>>>>>> the old >>>>>>>>>> generation? >>>>>>>>>> - The are two events for TLAB allocations, >>>>>>>>>> java/object_alloc_in_new_TLAB and >>>>>>>>>> java/object_alloc_outside_TLAB. >>>>>>>>>> What do you think about using two events for PLAB >>>>>>>>>> allocations as well: >>>>>>>>>> - java/object_alloc_in_new_PLAB >>>>>>>>>> - java/object_alloc_outside_PLAB >>>>>>>>> I think this is a matter of taste and probably how similar we >>>>>>>>> want the >>>>>>>>> event to be to the existing allocation event. I personally >>>>>>>>> prefer a >>>>>>>>> single event but if the GC team and serviceability team feel >>>>>>>>> it would be >>>>>>>>> better to have two I can certainly rewrite. The reason for me >>>>>>>>> preferring >>>>>>>>> a single event is just ease of analysis, you can easily filter >>>>>>>>> a list of >>>>>>>>> events on a field, it is harder to merge two different events >>>>>>>>> with >>>>>>>>> different fields and work with them in an straight forward >>>>>>>>> fashion. >>>>>>>>> >>>>>>>>> Any general preference for having a single or multiple events? >>>>>>>> >>>>>>>> I would prefer to have two events in this case and try to >>>>>>>> follow the existing allocation events as much as possible (both >>>>>>>> in naming and in style). Keeping the tenured field (I missed it >>>>>>>> the first time I read the patch) is good. >>>>>>>> >>>>>>> Yes, tenured would be independent of having two events, only >>>>>>> PLAB size and directAllocation would be affected when having two >>>>>>> event types. >>>>>>> >>>>>>> *Erik Gahlin*, any preference from your end? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>> - In PSPromotionManager, instead of utilizing the C++ >>>>>>>>>> friendship with >>>>>>>>>> PSScavenge, should we add a getter function for the gc_tracer? >>>>>>>>> Created a getter function. >>>>>>>> >>>>>>>> Thanks! If you make report_promotion_sample const, then the >>>>>>>> getter can return a const ParallelScavengeTracer*, right? >>>>>>>> >>>>>>> Done >>>>>>> >>>>>>> //Staffan >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Nov 19 18:33:15 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 19 Nov 2014 19:33:15 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <546A82AE.6010703@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> Message-ID: Hi Maynard, I just wanted to let you know that I'm still working on fixing the bogus entries in the stack trace. I'm pretty sure they are related to inlining. If you run your test program with "-XX:+PrintCompilation -XX:+PrintInlining -XX:CICompilerCount=1" you'll get the following output: .. 10954 5 % test::run_test @ 59 (99 bytes) @ 75 java.lang.String::getChars (62 bytes) inline (hot) @ 58 java.lang.System::arraycopy (0 bytes) (intrinsic) @ 87 test::get_my_chars (86 bytes) inline (hot) @ 6 java.lang.String::getChars (62 bytes) inline (hot) @ 58 java.lang.System::arraycopy (0 bytes) (intrinsic) @ 38 java.lang.String:: (62 bytes) inline (hot) @ 1 java.lang.Object:: (1 bytes) inline (hot) @ 55 java.util.Arrays::copyOfRange (63 bytes) too big @ 47 java.lang.StringBuilder:: (7 bytes) inline (hot) @ 52 java.lang.StringBuilder::append (8 bytes) executed < MinInliningThreshold times @ 57 java.lang.StringBuilder::append (8 bytes) executed < MinInliningThreshold times @ 62 java.lang.StringBuilder::append (8 bytes) executed < MinInliningThreshold times @ 65 java.lang.StringBuilder::toString (17 bytes) executed < MinInliningThreshold times @ 79 java.lang.String::length (6 bytes) inline (hot) @ 82 java.io.OutputStreamWriter::write (11 bytes) executed < MinInliningThreshold times .. The stack trace I get from jstack looks as follows: Thread 4448: (state = IN_JAVA) - test.get_my_chars(int, int, char[], java.lang.String, long) @bci=43, line=15 (Compiled frame; information may be imprecise) - test.run_test() @bci=87, line=35 (Compiled frame) - java.lang.String.getChars(int, int, char[], int) @bci=58, line=814 (Compiled frame) - test.run_test() @bci=75, line=34 (Compiled frame) >From a system perspective 'test::run_test' is one native frame, because 'test::run_test' inlines all the other functions reported above. HotSpot has special functionality to detect and walk these inlined methods (so called "virtual frames" or "vframe"s). For some reason this vframe walking doesn't seem to work in the agent. In gdb, when calling "ps()" at the same point where I created the above core file I'll get the following stack trace: (gdb) call ps() "Executing ps" for thread: "main" #1 prio=5 os_prio=0 tid=0x00003fffb0010800 nid=0x1160 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_Java Thread: 0x00003fffb0010800 [0x1160] State: _running _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_Java (guessing starting frame id=0x3fffb66ddc60 based on current fp) C frame (sp=0x00003fffb66ddad0 unextended sp=0x00003fffb66ddad0, fp=0x00003fffb66ddc60, real_fp=0x00003fffb66ddc60, pc=0x000000001000067c) 1 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) test.get_my_chars(test.java:16) 2 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) test.run_test(test.java:35) 3 - frame( sp=0x00003fffb66ddd60, unextended_sp=0x00003fffb66ddd60, fp=0x00003fffb66dde60, pc=0x00003fffa000f518) test.main(test.java:56) I'll keep you informed once I fixed the problem (I'll also look into the .opd issue afterwards). Regards, Volker On Tue, Nov 18, 2014 at 12:20 AM, Maynard Johnson wrote: > On 11/17/2014 01:21 PM, Volker Simonis wrote: >> On Mon, Nov 17, 2014 at 6:59 PM, Maynard Johnson wrote: >>> On 11/17/2014 10:20 AM, Volker Simonis wrote: >>>> Hi Maynard, >>>> >>>> I'm currently looking at your changes. At first glance they look good. >>>> >>>> I could open a simple core file which contained both, interpreted and >>>> compiled frames: >>>> >>>> $ jstack ./images/j2sdk-image/bin/java core.7034 >>>> ... >>>> Thread 7035: (state = IN_VM) >>>> - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) >>>> - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) >>>> - Crash.doIt() @bci=45, line=23 (Compiled frame) >>>> - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >>>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >>>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >>>> - java.lang.reflect.Method.invoke(java.lang.Object, >>>> java.lang.Object[]) @bci=56, line=498 (Interpreted frame) >>>> - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) >>>> >>>> The one thing that doesn't currently work is "jstack -m" (i.e. "mixed >>>> mode" for java and native frames). Are you aware of this? >>> Hi, Volker, >>> Yeah, I knew about this problem and forgot to mention it in my patch posting. I started >>> looking at it this morning, and so far, I have at least fixed the UnmappedAddressException. >>> But now I'm getting different results on little endian vs big endian ppc64 systems. >>> On BE, I either get no symbol names (i.e., "?????") or wrong symbol names. On LE, >>> I seem to get correct symbol names for the first symbol (either __pthread_cond_wait >>> or __pthread_cond_timedwait) and the last symbol (start_thread) of each stack, but >>> everything in between is "?????". >>> >> >> Maybe this is related to the fact that we have function descriptors on >> BE and simple function pointers on LE. You may have a look at the >> elf-decoder for ppc64 to find some more information. > > Yes, indeed. With the following patch, the mixed mode option works fine on ppc64 little endian, > but not on big endian: > > Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java > =================================================================== > --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java > +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java > @@ -60,14 +60,15 @@ final public class LinuxPPC64CFrame exte > return null; > } > > - Address nextSP = sp.getAddressAt( PPC64ThreadContext.SP * address_size + PPC64_STACK_BIAS); > + Address nextSP = sp.getAddressAt(0); > if (nextSP == null) { > return null; > } > - Address nextPC = sp.getAddressAt(PPC64ThreadContext.PC * address_size + PPC64_STACK_BIAS); > + Address nextPC = sp.getAddressAt(2 * address_size); > if (nextPC == null) { > return null; > } > + > return new LinuxPPC64CFrame(dbg, nextSP, nextPC,address_size); > } > > ------------------------------------------------- > > I see that ppc64 fixups were made in the hotspot utilities (by you) about a year ago > (http://cr.openjdk.java.net/~simonis/webrevs/8019929.v3/). We obviously need something > similar in the hotspot agent native code that implements the JNI call 'lookupByAddress0'. > I hacked the build_symtab_internal() function in hotspot/agent/src/os/linux/symtab.c and > see that the symbol "offset" we're getting is really the address of the symbol's opd. > I'm not sure where to start to fix this, so if you have any suggestions, I'm all ears. :-) > > Thanks. > -Maynard >> >>>> >>>> Regarding your "test.java" example - how do you use it? >>>> >>>> If I just attach with jstack to the Java process which runs >>>> "test.java" I get the correct stack trace of all threads. But I think >>>> that's actual no SA-functionality but a VM-feature (the same that can >>>> be triggered by sending kill -SIGQUIT to java process). >>>> >>>> If I attach with "jstack -F" I see the problems you mentioned. First I >>>> didn't saw any frame at all which confused me but then I also saw the >>>> two cases mentioned by you. I'll need to have a closer look what >>>> happens. >>> >>> I was just running the 'test' java app and, in another session, killing it with SIGSEGV. >>> To be honest, I wasn't aware of the 'jstack -F' option. >>> >> >> Another possibility I've just found out is to create a core from gdb >> with the 'generate-core-file' command. You can than still inspect the >> original program in gdb while debugging how jstack is working on the >> core file. >> >>> -Maynard >>> >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> >>>> On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: >>>>> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: >>>>> >>>>> OS/CPU combination linux/ppc64 not yet supported >>>>> >>>>> I will post a patch set that adds this support. The patch set consists of the following patches: >>>>> >>>>> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files >>>>> >>>>> PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files >>>>> >>>>> These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. >>>>> >>>>> ------------ >>>>> Open issues: >>>>> ------------ >>>>> 1) The jstack tool does not print a stack entry for the 'main()' method of the Java >>>>> workload (attached) under test. For example: >>>>> >>>>> (Note: Addresses and method signatures elided for brevity.) >>>>> >>>>> Thread 24358: (state = IN_JAVA, current Java SP = null >>>>> ) >>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>> ==> (Expect an entry for test.main() here) >>>>> >>>>> 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: >>>>> >>>>> Thread 24779: (state = IN_JAVA, current Java SP = null >>>>> ) >>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) >>>>> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) >>>>> >>>>> Again, the 'test.main' method is missing, but there's also the anomaly of the >>>>> test.run_test' method showing up twice in the stack, implying that it is called >>>>> by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test >>>>> does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- >>>>> but these are totally distinct call graphs. Somehow, we are seeing these two distinct >>>>> stacks in the core file, which seems impossible. >>>>> >>>>> --------- >>>>> >>>>> Any help offered on these two open issues would be greatly appreciated. >>>>> >>>>> -Maynard >>>> >>> >> > From ygaevsky at azulsystems.com Wed Nov 19 22:11:19 2014 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Wed, 19 Nov 2014 22:11:19 +0000 Subject: RFR(XS) 6364329 jstat displays "invalid argument count" with usage Message-ID: Hello. Please see below a small fix for integration into JDK 9: $ hg diff diff --git a/src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java b/src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java --- a/src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java +++ b/src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java @@ -141,8 +141,9 @@ public Arguments(String[] args) throws IllegalArgumentException { int argc = 0; - if (args.length < 1) { - throw new IllegalArgumentException("invalid argument count"); + if (args.length == 0) { + help = true; + return; } if ((args[0].compareTo("-?") == 0) Thanks, -Yuri From volker.simonis at gmail.com Thu Nov 20 11:03:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Nov 2014 12:03:14 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> Message-ID: Hy Maynard, I've just realized that in your patch the two directory patterns $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_ppc64/*.java and $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/ppc64/*.java are absent from "make/sa.files". This of course breaks incremental builds. Regards, Volker diff -r 6f35dca1949c make/sa.files --- a/make/sa.files Mon Nov 17 14:47:41 2014 +0100 +++ b/make/sa.files Thu Nov 20 11:58:52 2014 +0100 @@ -94,12 +94,14 @@ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_amd64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_x86/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_sparc/*.java \ +$(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_ppc64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/posix/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_amd64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_sparc/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_x86/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/sparc/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/x86/*.java \ +$(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/ppc64/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/jcore/*.java \ $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/soql/*.java \ On Wed, Nov 19, 2014 at 7:33 PM, Volker Simonis wrote: > Hi Maynard, > > I just wanted to let you know that I'm still working on fixing the > bogus entries in the stack trace. I'm pretty sure they are related to > inlining. If you run your test program with "-XX:+PrintCompilation > -XX:+PrintInlining -XX:CICompilerCount=1" you'll get the following > output: > > .. > 10954 5 % test::run_test @ 59 (99 bytes) > @ 75 java.lang.String::getChars (62 > bytes) inline (hot) > @ 58 java.lang.System::arraycopy (0 > bytes) (intrinsic) > @ 87 test::get_my_chars (86 bytes) inline (hot) > @ 6 java.lang.String::getChars (62 > bytes) inline (hot) > @ 58 java.lang.System::arraycopy (0 > bytes) (intrinsic) > @ 38 java.lang.String:: (62 > bytes) inline (hot) > @ 1 java.lang.Object:: (1 > bytes) inline (hot) > @ 55 java.util.Arrays::copyOfRange > (63 bytes) too big > @ 47 java.lang.StringBuilder:: > (7 bytes) inline (hot) > @ 52 java.lang.StringBuilder::append > (8 bytes) executed < MinInliningThreshold times > @ 57 java.lang.StringBuilder::append > (8 bytes) executed < MinInliningThreshold times > @ 62 java.lang.StringBuilder::append > (8 bytes) executed < MinInliningThreshold times > @ 65 java.lang.StringBuilder::toString > (17 bytes) executed < MinInliningThreshold times > @ 79 java.lang.String::length (6 > bytes) inline (hot) > @ 82 java.io.OutputStreamWriter::write > (11 bytes) executed < MinInliningThreshold times > .. > > The stack trace I get from jstack looks as follows: > > Thread 4448: (state = IN_JAVA) > - test.get_my_chars(int, int, char[], java.lang.String, long) > @bci=43, line=15 (Compiled frame; information may be imprecise) > - test.run_test() @bci=87, line=35 (Compiled frame) > - java.lang.String.getChars(int, int, char[], int) @bci=58, line=814 > (Compiled frame) > - test.run_test() @bci=75, line=34 (Compiled frame) > > From a system perspective 'test::run_test' is one native frame, > because 'test::run_test' inlines all the other functions reported > above. HotSpot has special functionality to detect and walk these > inlined methods (so called "virtual frames" or "vframe"s). For some > reason this vframe walking doesn't seem to work in the agent. In gdb, > when calling "ps()" at the same point where I created the above core > file I'll get the following stack trace: > > (gdb) call ps() > > "Executing ps" > for thread: "main" #1 prio=5 os_prio=0 tid=0x00003fffb0010800 > nid=0x1160 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_in_Java > Thread: 0x00003fffb0010800 [0x1160] State: _running _has_called_back > 0 _at_poll_safepoint 0 > JavaThread state: _thread_in_Java > > (guessing starting frame id=0x3fffb66ddc60 based on current fp) > C frame (sp=0x00003fffb66ddad0 unextended sp=0x00003fffb66ddad0, > fp=0x00003fffb66ddc60, real_fp=0x00003fffb66ddc60, > pc=0x000000001000067c) > 1 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, > fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) > test.get_my_chars(test.java:16) > 2 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, > fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) > test.run_test(test.java:35) > 3 - frame( sp=0x00003fffb66ddd60, unextended_sp=0x00003fffb66ddd60, > fp=0x00003fffb66dde60, pc=0x00003fffa000f518) > test.main(test.java:56) > > I'll keep you informed once I fixed the problem (I'll also look into > the .opd issue afterwards). > > Regards, > Volker > > > On Tue, Nov 18, 2014 at 12:20 AM, Maynard Johnson wrote: >> On 11/17/2014 01:21 PM, Volker Simonis wrote: >>> On Mon, Nov 17, 2014 at 6:59 PM, Maynard Johnson wrote: >>>> On 11/17/2014 10:20 AM, Volker Simonis wrote: >>>>> Hi Maynard, >>>>> >>>>> I'm currently looking at your changes. At first glance they look good. >>>>> >>>>> I could open a simple core file which contained both, interpreted and >>>>> compiled frames: >>>>> >>>>> $ jstack ./images/j2sdk-image/bin/java core.7034 >>>>> ... >>>>> Thread 7035: (state = IN_VM) >>>>> - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) >>>>> - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) >>>>> - Crash.doIt() @bci=45, line=23 (Compiled frame) >>>>> - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >>>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >>>>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >>>>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >>>>> - java.lang.reflect.Method.invoke(java.lang.Object, >>>>> java.lang.Object[]) @bci=56, line=498 (Interpreted frame) >>>>> - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) >>>>> >>>>> The one thing that doesn't currently work is "jstack -m" (i.e. "mixed >>>>> mode" for java and native frames). Are you aware of this? >>>> Hi, Volker, >>>> Yeah, I knew about this problem and forgot to mention it in my patch posting. I started >>>> looking at it this morning, and so far, I have at least fixed the UnmappedAddressException. >>>> But now I'm getting different results on little endian vs big endian ppc64 systems. >>>> On BE, I either get no symbol names (i.e., "?????") or wrong symbol names. On LE, >>>> I seem to get correct symbol names for the first symbol (either __pthread_cond_wait >>>> or __pthread_cond_timedwait) and the last symbol (start_thread) of each stack, but >>>> everything in between is "?????". >>>> >>> >>> Maybe this is related to the fact that we have function descriptors on >>> BE and simple function pointers on LE. You may have a look at the >>> elf-decoder for ppc64 to find some more information. >> >> Yes, indeed. With the following patch, the mixed mode option works fine on ppc64 little endian, >> but not on big endian: >> >> Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >> =================================================================== >> --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >> +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >> @@ -60,14 +60,15 @@ final public class LinuxPPC64CFrame exte >> return null; >> } >> >> - Address nextSP = sp.getAddressAt( PPC64ThreadContext.SP * address_size + PPC64_STACK_BIAS); >> + Address nextSP = sp.getAddressAt(0); >> if (nextSP == null) { >> return null; >> } >> - Address nextPC = sp.getAddressAt(PPC64ThreadContext.PC * address_size + PPC64_STACK_BIAS); >> + Address nextPC = sp.getAddressAt(2 * address_size); >> if (nextPC == null) { >> return null; >> } >> + >> return new LinuxPPC64CFrame(dbg, nextSP, nextPC,address_size); >> } >> >> ------------------------------------------------- >> >> I see that ppc64 fixups were made in the hotspot utilities (by you) about a year ago >> (http://cr.openjdk.java.net/~simonis/webrevs/8019929.v3/). We obviously need something >> similar in the hotspot agent native code that implements the JNI call 'lookupByAddress0'. >> I hacked the build_symtab_internal() function in hotspot/agent/src/os/linux/symtab.c and >> see that the symbol "offset" we're getting is really the address of the symbol's opd. >> I'm not sure where to start to fix this, so if you have any suggestions, I'm all ears. :-) >> >> Thanks. >> -Maynard >>> >>>>> >>>>> Regarding your "test.java" example - how do you use it? >>>>> >>>>> If I just attach with jstack to the Java process which runs >>>>> "test.java" I get the correct stack trace of all threads. But I think >>>>> that's actual no SA-functionality but a VM-feature (the same that can >>>>> be triggered by sending kill -SIGQUIT to java process). >>>>> >>>>> If I attach with "jstack -F" I see the problems you mentioned. First I >>>>> didn't saw any frame at all which confused me but then I also saw the >>>>> two cases mentioned by you. I'll need to have a closer look what >>>>> happens. >>>> >>>> I was just running the 'test' java app and, in another session, killing it with SIGSEGV. >>>> To be honest, I wasn't aware of the 'jstack -F' option. >>>> >>> >>> Another possibility I've just found out is to create a core from gdb >>> with the 'generate-core-file' command. You can than still inspect the >>> original program in gdb while debugging how jstack is working on the >>> core file. >>> >>>> -Maynard >>>> >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> >>>>> On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: >>>>>> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: >>>>>> >>>>>> OS/CPU combination linux/ppc64 not yet supported >>>>>> >>>>>> I will post a patch set that adds this support. The patch set consists of the following patches: >>>>>> >>>>>> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files >>>>>> >>>>>> PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files >>>>>> >>>>>> These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. >>>>>> >>>>>> ------------ >>>>>> Open issues: >>>>>> ------------ >>>>>> 1) The jstack tool does not print a stack entry for the 'main()' method of the Java >>>>>> workload (attached) under test. For example: >>>>>> >>>>>> (Note: Addresses and method signatures elided for brevity.) >>>>>> >>>>>> Thread 24358: (state = IN_JAVA, current Java SP = null >>>>>> ) >>>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>>> ==> (Expect an entry for test.main() here) >>>>>> >>>>>> 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: >>>>>> >>>>>> Thread 24779: (state = IN_JAVA, current Java SP = null >>>>>> ) >>>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>>> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) >>>>>> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) >>>>>> >>>>>> Again, the 'test.main' method is missing, but there's also the anomaly of the >>>>>> test.run_test' method showing up twice in the stack, implying that it is called >>>>>> by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test >>>>>> does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- >>>>>> but these are totally distinct call graphs. Somehow, we are seeing these two distinct >>>>>> stacks in the core file, which seems impossible. >>>>>> >>>>>> --------- >>>>>> >>>>>> Any help offered on these two open issues would be greatly appreciated. >>>>>> >>>>>> -Maynard >>>>> >>>> >>> >> From ivan.gerasimov at oracle.com Thu Nov 20 12:51:18 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 20 Nov 2014 15:51:18 +0300 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <546B6568.7040701@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> <546AF55A.8090203@oracle.com> <546B6568.7040701@oracle.com> Message-ID: <546DE3C6.5050200@oracle.com> Thank you Daniel! David, are you still Okay with the updated webrev? Comparing to the previous one, I've added setting the priority of the current thread at the line 3880 and changed the priority level to from HIGHEST to ABOVE_NORMAL. Sincerely yours, Ivan On 18.11.2014 18:27, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ > > src/os/windows/vm/os_windows.cpp > No commments. > > Thumbs up. > > Dan > > > On 11/18/14 12:29 AM, Ivan Gerasimov wrote: >> Hi Markus! >> >> The priority of the exiting thread will be raised for quite a short >> period of time -- right before the thread finishes exiting. >> >> There are two places where the priority is adjusted. >> >> Under normal conditions we should never see the first place hit. >> However, if we do, this means we have a huge number of threads. >> Raising the priority of one of them is a hint about which thread we >> want the scheduler to focus on. >> >> The second place is a bit different. >> We have several threads running immediately before ending the process. >> Some of them are at the exiting path and block exiting of the whole >> process. >> Raising the priority of those threads is a way to say we're not >> interested in all the other threads, as they are going to be >> terminated anyway. >> >> I just noticed that in second scenario it may be appropriate to set >> the priority of the current thread to the same level as for the >> exiting threads. >> This way it'll be given a fair chance to continue if the timeout >> expires. >> >> I also think it should be enough to set the priority level to >> THREAD_PRIORITY_ABOVE_NORMAL instead of THREAD_PRIORITY_HIGHEST. >> It will give just +1 to the priority value -- should be enough for >> the hint. >> >> Would you please take a look at the updated webrev: >> http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> On 17.11.2014 11:33, Markus Gr?nlund wrote: >>> I agree with David. >>> >>> The side effects will be unknown and very hard to debug. >>> >>> Is there another way to accomplish the results without manipulating >>> base services? >>> >>> Thanks >>> Markus >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: den 17 november 2014 07:40 >>> To: Ivan Gerasimov; Daniel Daugherty >>> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev >>> Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed >>> in hotspot\src\os\windows\vm\os_windows.cpp: 3844 >>> >>> On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >>>> Thank you Daniel! >>>> >>>> Please find the updated webrev with your suggestions incorporated >>>> here: >>>> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >>>> >>>> Concerning the thread priority: If the application is of >>>> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >>>> THREAD_PRIORITY_HIGHEST will result in its priority value to be only >>>> 10 (of maximum 31). >>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs. >>>> 85).aspx >>>> >>>> >>>> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >>>> HIGHEST priority level will have priority value == 15 of 31. >>>> >>>> I believe, it should not be too much, and the machine will not become >>>> busy with only those closing threads. >>>> However, I hope it would be enough to make them complete faster than >>>> other threads of the NORMAL priority level withing the same >>>> application. >>> I don't think this is necessary or desirable. Under normal usage >>> we're giving priority to exiting threads and that may disrupt the >>> usual scheduling patterns that applications see. You may posit that >>> it is "harmless" but we can't say that for sure. Nor can we actually >>> know that this will help with this particular bug. I would not add >>> in this new code. >>> >>> David >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>>>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>>>> Hello! >>>>>> >>>>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>>>> for exiting threads [win]) caused the warning message to be printed >>>>>> in some test environments: >>>>>> ----------- >>>>>> os_windows.cpp:3844 is in the newly updated >>>>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>>>> ----------- >>>>>> >>>>>> This has been observed with debug builds on highly loaded systems. >>>>>> >>>>>> >>>>>> To address the issue it is proposed to do three things: >>>>>> 1) increase the timeout for debug builds, >>>>>> 2) increase the maximum number of the thread handles to be stored, >>>>>> 3) rise the priority of the exiting threads, if we need to wait for >>>>>> them. >>>>>> >>>>>> Would you please help review the fix? >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>>>> src/os/windows/vm/os_windows.cpp >>>>> >>>>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>> >>>>> That uses the smaller value for only one build config (PRODUCT). >>>>> >>>>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) >>>>> DEBUG_ONLY(4000) >>>>> /*1 sec in product, 4 sec in debug*/ >>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>> Please add spaces between the comment delimiters and the comment >>>>> text. >>>>> >>>>> That uses the smaller timeout for only one build config >>>>> (PRODUCT). >>>>> >>>>> line 3836 // Rise the priority... >>>>> Typo: 'Rise' -> 'Raise' >>>>> >>>>> About the general idea of raising the exiting thread's priority, >>>>> if the exiting thread is looping in some Win* OS code after this >>>>> point, will raising the priority make the machine unusable? >>>>> >>>>> Dan >>>>> >>>>> >>>>>> The fix was tested on all available platforms, with the hotspot >>>>>> testset. No failures. >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>> >>>>> >>> >> > > > From maynardj at us.ibm.com Thu Nov 20 18:05:01 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Thu, 20 Nov 2014 12:05:01 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> Message-ID: <546E2D4D.7010103@us.ibm.com> On 11/20/2014 05:03 AM, Volker Simonis wrote: > Hy Maynard, > > I've just realized that in your patch the two directory patterns > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_ppc64/*.java and > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/ppc64/*.java are absent from > "make/sa.files". This of course breaks incremental builds. Nice, thank you. I was wondering why incremental build didn't work. I had resorted to using a build script that did the following: rm build/linux-ppc64-normal-server-release/hotspot/linux_ppc64_compiler2/product/../generated/sa-jdi.jar make all JOBS=24 make install -Maynard > > Regards, > Volker > > > diff -r 6f35dca1949c make/sa.files > --- a/make/sa.files Mon Nov 17 14:47:41 2014 +0100 > +++ b/make/sa.files Thu Nov 20 11:58:52 2014 +0100 > @@ -94,12 +94,14 @@ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_amd64/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_x86/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_sparc/*.java \ > +$(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_ppc64/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/posix/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_amd64/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_sparc/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_x86/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/sparc/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/x86/*.java \ > +$(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/ppc64/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/jcore/*.java \ > $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/soql/*.java \ > > On Wed, Nov 19, 2014 at 7:33 PM, Volker Simonis > wrote: >> Hi Maynard, >> >> I just wanted to let you know that I'm still working on fixing the >> bogus entries in the stack trace. I'm pretty sure they are related to >> inlining. If you run your test program with "-XX:+PrintCompilation >> -XX:+PrintInlining -XX:CICompilerCount=1" you'll get the following >> output: >> >> .. >> 10954 5 % test::run_test @ 59 (99 bytes) >> @ 75 java.lang.String::getChars (62 >> bytes) inline (hot) >> @ 58 java.lang.System::arraycopy (0 >> bytes) (intrinsic) >> @ 87 test::get_my_chars (86 bytes) inline (hot) >> @ 6 java.lang.String::getChars (62 >> bytes) inline (hot) >> @ 58 java.lang.System::arraycopy (0 >> bytes) (intrinsic) >> @ 38 java.lang.String:: (62 >> bytes) inline (hot) >> @ 1 java.lang.Object:: (1 >> bytes) inline (hot) >> @ 55 java.util.Arrays::copyOfRange >> (63 bytes) too big >> @ 47 java.lang.StringBuilder:: >> (7 bytes) inline (hot) >> @ 52 java.lang.StringBuilder::append >> (8 bytes) executed < MinInliningThreshold times >> @ 57 java.lang.StringBuilder::append >> (8 bytes) executed < MinInliningThreshold times >> @ 62 java.lang.StringBuilder::append >> (8 bytes) executed < MinInliningThreshold times >> @ 65 java.lang.StringBuilder::toString >> (17 bytes) executed < MinInliningThreshold times >> @ 79 java.lang.String::length (6 >> bytes) inline (hot) >> @ 82 java.io.OutputStreamWriter::write >> (11 bytes) executed < MinInliningThreshold times >> .. >> >> The stack trace I get from jstack looks as follows: >> >> Thread 4448: (state = IN_JAVA) >> - test.get_my_chars(int, int, char[], java.lang.String, long) >> @bci=43, line=15 (Compiled frame; information may be imprecise) >> - test.run_test() @bci=87, line=35 (Compiled frame) >> - java.lang.String.getChars(int, int, char[], int) @bci=58, line=814 >> (Compiled frame) >> - test.run_test() @bci=75, line=34 (Compiled frame) >> >> From a system perspective 'test::run_test' is one native frame, >> because 'test::run_test' inlines all the other functions reported >> above. HotSpot has special functionality to detect and walk these >> inlined methods (so called "virtual frames" or "vframe"s). For some >> reason this vframe walking doesn't seem to work in the agent. In gdb, >> when calling "ps()" at the same point where I created the above core >> file I'll get the following stack trace: >> >> (gdb) call ps() >> >> "Executing ps" >> for thread: "main" #1 prio=5 os_prio=0 tid=0x00003fffb0010800 >> nid=0x1160 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_in_Java >> Thread: 0x00003fffb0010800 [0x1160] State: _running _has_called_back >> 0 _at_poll_safepoint 0 >> JavaThread state: _thread_in_Java >> >> (guessing starting frame id=0x3fffb66ddc60 based on current fp) >> C frame (sp=0x00003fffb66ddad0 unextended sp=0x00003fffb66ddad0, >> fp=0x00003fffb66ddc60, real_fp=0x00003fffb66ddc60, >> pc=0x000000001000067c) >> 1 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, >> fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) >> test.get_my_chars(test.java:16) >> 2 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, >> fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) >> test.run_test(test.java:35) >> 3 - frame( sp=0x00003fffb66ddd60, unextended_sp=0x00003fffb66ddd60, >> fp=0x00003fffb66dde60, pc=0x00003fffa000f518) >> test.main(test.java:56) >> >> I'll keep you informed once I fixed the problem (I'll also look into >> the .opd issue afterwards). >> >> Regards, >> Volker >> >> >> On Tue, Nov 18, 2014 at 12:20 AM, Maynard Johnson wrote: >>> On 11/17/2014 01:21 PM, Volker Simonis wrote: >>>> On Mon, Nov 17, 2014 at 6:59 PM, Maynard Johnson wrote: >>>>> On 11/17/2014 10:20 AM, Volker Simonis wrote: >>>>>> Hi Maynard, >>>>>> >>>>>> I'm currently looking at your changes. At first glance they look good. >>>>>> >>>>>> I could open a simple core file which contained both, interpreted and >>>>>> compiled frames: >>>>>> >>>>>> $ jstack ./images/j2sdk-image/bin/java core.7034 >>>>>> ... >>>>>> Thread 7035: (state = IN_VM) >>>>>> - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) >>>>>> - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) >>>>>> - Crash.doIt() @bci=45, line=23 (Compiled frame) >>>>>> - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >>>>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >>>>>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >>>>>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >>>>>> - java.lang.reflect.Method.invoke(java.lang.Object, >>>>>> java.lang.Object[]) @bci=56, line=498 (Interpreted frame) >>>>>> - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) >>>>>> >>>>>> The one thing that doesn't currently work is "jstack -m" (i.e. "mixed >>>>>> mode" for java and native frames). Are you aware of this? >>>>> Hi, Volker, >>>>> Yeah, I knew about this problem and forgot to mention it in my patch posting. I started >>>>> looking at it this morning, and so far, I have at least fixed the UnmappedAddressException. >>>>> But now I'm getting different results on little endian vs big endian ppc64 systems. >>>>> On BE, I either get no symbol names (i.e., "?????") or wrong symbol names. On LE, >>>>> I seem to get correct symbol names for the first symbol (either __pthread_cond_wait >>>>> or __pthread_cond_timedwait) and the last symbol (start_thread) of each stack, but >>>>> everything in between is "?????". >>>>> >>>> >>>> Maybe this is related to the fact that we have function descriptors on >>>> BE and simple function pointers on LE. You may have a look at the >>>> elf-decoder for ppc64 to find some more information. >>> >>> Yes, indeed. With the following patch, the mixed mode option works fine on ppc64 little endian, >>> but not on big endian: >>> >>> Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >>> =================================================================== >>> --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >>> +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >>> @@ -60,14 +60,15 @@ final public class LinuxPPC64CFrame exte >>> return null; >>> } >>> >>> - Address nextSP = sp.getAddressAt( PPC64ThreadContext.SP * address_size + PPC64_STACK_BIAS); >>> + Address nextSP = sp.getAddressAt(0); >>> if (nextSP == null) { >>> return null; >>> } >>> - Address nextPC = sp.getAddressAt(PPC64ThreadContext.PC * address_size + PPC64_STACK_BIAS); >>> + Address nextPC = sp.getAddressAt(2 * address_size); >>> if (nextPC == null) { >>> return null; >>> } >>> + >>> return new LinuxPPC64CFrame(dbg, nextSP, nextPC,address_size); >>> } >>> >>> ------------------------------------------------- >>> >>> I see that ppc64 fixups were made in the hotspot utilities (by you) about a year ago >>> (http://cr.openjdk.java.net/~simonis/webrevs/8019929.v3/). We obviously need something >>> similar in the hotspot agent native code that implements the JNI call 'lookupByAddress0'. >>> I hacked the build_symtab_internal() function in hotspot/agent/src/os/linux/symtab.c and >>> see that the symbol "offset" we're getting is really the address of the symbol's opd. >>> I'm not sure where to start to fix this, so if you have any suggestions, I'm all ears. :-) >>> >>> Thanks. >>> -Maynard >>>> >>>>>> >>>>>> Regarding your "test.java" example - how do you use it? >>>>>> >>>>>> If I just attach with jstack to the Java process which runs >>>>>> "test.java" I get the correct stack trace of all threads. But I think >>>>>> that's actual no SA-functionality but a VM-feature (the same that can >>>>>> be triggered by sending kill -SIGQUIT to java process). >>>>>> >>>>>> If I attach with "jstack -F" I see the problems you mentioned. First I >>>>>> didn't saw any frame at all which confused me but then I also saw the >>>>>> two cases mentioned by you. I'll need to have a closer look what >>>>>> happens. >>>>> >>>>> I was just running the 'test' java app and, in another session, killing it with SIGSEGV. >>>>> To be honest, I wasn't aware of the 'jstack -F' option. >>>>> >>>> >>>> Another possibility I've just found out is to create a core from gdb >>>> with the 'generate-core-file' command. You can than still inspect the >>>> original program in gdb while debugging how jstack is working on the >>>> core file. >>>> >>>>> -Maynard >>>>> >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: >>>>>>> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: >>>>>>> >>>>>>> OS/CPU combination linux/ppc64 not yet supported >>>>>>> >>>>>>> I will post a patch set that adds this support. The patch set consists of the following patches: >>>>>>> >>>>>>> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files >>>>>>> >>>>>>> PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files >>>>>>> >>>>>>> These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. >>>>>>> >>>>>>> ------------ >>>>>>> Open issues: >>>>>>> ------------ >>>>>>> 1) The jstack tool does not print a stack entry for the 'main()' method of the Java >>>>>>> workload (attached) under test. For example: >>>>>>> >>>>>>> (Note: Addresses and method signatures elided for brevity.) >>>>>>> >>>>>>> Thread 24358: (state = IN_JAVA, current Java SP = null >>>>>>> ) >>>>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>>>> ==> (Expect an entry for test.main() here) >>>>>>> >>>>>>> 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: >>>>>>> >>>>>>> Thread 24779: (state = IN_JAVA, current Java SP = null >>>>>>> ) >>>>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>>>> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) >>>>>>> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) >>>>>>> >>>>>>> Again, the 'test.main' method is missing, but there's also the anomaly of the >>>>>>> test.run_test' method showing up twice in the stack, implying that it is called >>>>>>> by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test >>>>>>> does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- >>>>>>> but these are totally distinct call graphs. Somehow, we are seeing these two distinct >>>>>>> stacks in the core file, which seems impossible. >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Any help offered on these two open issues would be greatly appreciated. >>>>>>> >>>>>>> -Maynard >>>>>> >>>>> >>>> >>> > From kevin.walls at oracle.com Thu Nov 20 18:38:08 2014 From: kevin.walls at oracle.com (KEVIN WALLS) Date: Thu, 20 Nov 2014 18:38:08 +0000 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. In-Reply-To: <5380E426.5080904@oracle.com> References: <5370E26B.3030509@oracle.com> <537B3921.2090402@oracle.com> <352D5134-6A27-4257-AC6A-9EF041288830@oracle.com> <5380E426.5080904@oracle.com> Message-ID: <546E3510.3010606@oracle.com> Hi, I'm resurrecting this thread to revisit this testcase, the one that fails if not in an environment where an SA attach is permitted (which is linux systems with 1 in /proc/sys/kernel/yama/ptrace_scope, and mac systems as a non-root user). There are times when we want to check if an SA attach is likely to work, so in the following webrev I've put that in the testlibrary. In doing this I now realise that heap dumping with jmap/sa is broken, as reported in: https://bugs.openjdk.java.net/browse/JDK-8044416 I won't remove the @ignore in this change, but it would make sense to me to do the fix below, including backporting to places where jmap -F still works. webrev http://cr.openjdk.java.net/~kevinw/8039995/webrev.01/ bug https://bugs.openjdk.java.net/browse/JDK-8039995 Thanks Kevin On 24/05/2014 19:25, Kevin Walls wrote: > > Thanks Peter, and thanks Dmitry - > > So another thread on this has started about why such a test runs in an > environment that can't expected to attach to its own processes anyway: > seems that some test systems permit that, and some run as a user that > can't necessarily expect to have that ability. > > (Dmitry I'm not sure about exiting with that error value? If that's > something people are meant to know about I have missed it. But the > test would fail if jmap didn't create the heap dump file, i.e. if it > fails but doesn't exit with the right code.) > > For the moment I'll wait on that other information for whether this > needs to be fixed in the test... > > Thanks! > Kevin > > > > > On 23/05/14 12:00, Peter Allwin wrote: >> Looks good to me! >> >> >> Thanks for looking at this Kevin, >> /peter >> >> On 20 May 2014, at 13:14, Kevin Walls wrote: >> >>> Hi - any comments? 8-) >>> >>> On 12/05/14 16:02, Kevin Walls wrote >>>> Hi, >>>> >>>> I'd like to get a review of this test change. It assumed that jmap >>>> would have permission to run on a process that the test itself >>>> created, but this is not necessarily the case. >>>> >>>> Here I'm considering it OK to skip (pass) the test where jmap fails >>>> to attach. The test itself was not platform-specific and as long >>>> as we have other platforms where jmap step will work, we are >>>> testing for this problem. >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8039995 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ >>>> >>>> Thanks >>>> Kevin > From david.holmes at oracle.com Mon Nov 24 05:07:19 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 Nov 2014 15:07:19 +1000 Subject: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 In-Reply-To: <546DE3C6.5050200@oracle.com> References: <5465F711.9090605@oracle.com> <54668EAF.9070807@oracle.com> <546915DF.7080106@oracle.com> <54699845.5010901@oracle.com> <546AF55A.8090203@oracle.com> <546B6568.7040701@oracle.com> <546DE3C6.5050200@oracle.com> Message-ID: <5472BD07.6050405@oracle.com> On 20/11/2014 10:51 PM, Ivan Gerasimov wrote: > Thank you Daniel! > > David, are you still Okay with the updated webrev? Yes. Thanks, David > Comparing to the previous one, I've added setting the priority of the > current thread at the line 3880 and changed the priority level to > from HIGHEST to ABOVE_NORMAL. > > Sincerely yours, > Ivan > > On 18.11.2014 18:27, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> No commments. >> >> Thumbs up. >> >> Dan >> >> >> On 11/18/14 12:29 AM, Ivan Gerasimov wrote: >>> Hi Markus! >>> >>> The priority of the exiting thread will be raised for quite a short >>> period of time -- right before the thread finishes exiting. >>> >>> There are two places where the priority is adjusted. >>> >>> Under normal conditions we should never see the first place hit. >>> However, if we do, this means we have a huge number of threads. >>> Raising the priority of one of them is a hint about which thread we >>> want the scheduler to focus on. >>> >>> The second place is a bit different. >>> We have several threads running immediately before ending the process. >>> Some of them are at the exiting path and block exiting of the whole >>> process. >>> Raising the priority of those threads is a way to say we're not >>> interested in all the other threads, as they are going to be >>> terminated anyway. >>> >>> I just noticed that in second scenario it may be appropriate to set >>> the priority of the current thread to the same level as for the >>> exiting threads. >>> This way it'll be given a fair chance to continue if the timeout >>> expires. >>> >>> I also think it should be enough to set the priority level to >>> THREAD_PRIORITY_ABOVE_NORMAL instead of THREAD_PRIORITY_HIGHEST. >>> It will give just +1 to the priority value -- should be enough for >>> the hint. >>> >>> Would you please take a look at the updated webrev: >>> http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 17.11.2014 11:33, Markus Gr?nlund wrote: >>>> I agree with David. >>>> >>>> The side effects will be unknown and very hard to debug. >>>> >>>> Is there another way to accomplish the results without manipulating >>>> base services? >>>> >>>> Thanks >>>> Markus >>>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: den 17 november 2014 07:40 >>>> To: Ivan Gerasimov; Daniel Daugherty >>>> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev >>>> Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed >>>> in hotspot\src\os\windows\vm\os_windows.cpp: 3844 >>>> >>>> On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: >>>>> Thank you Daniel! >>>>> >>>>> Please find the updated webrev with your suggestions incorporated >>>>> here: >>>>> http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ >>>>> >>>>> Concerning the thread priority: If the application is of >>>>> NORMAL_PRIORITY_CLASS, then setting the thread's priority level to >>>>> THREAD_PRIORITY_HIGHEST will result in its priority value to be only >>>>> 10 (of maximum 31). >>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs. >>>>> 85).aspx >>>>> >>>>> >>>>> And if the process is HIGH_PRIORITY_CLASS, then the tread with the >>>>> HIGHEST priority level will have priority value == 15 of 31. >>>>> >>>>> I believe, it should not be too much, and the machine will not become >>>>> busy with only those closing threads. >>>>> However, I hope it would be enough to make them complete faster than >>>>> other threads of the NORMAL priority level withing the same >>>>> application. >>>> I don't think this is necessary or desirable. Under normal usage >>>> we're giving priority to exiting threads and that may disrupt the >>>> usual scheduling patterns that applications see. You may posit that >>>> it is "harmless" but we can't say that for sure. Nor can we actually >>>> know that this will help with this particular bug. I would not add >>>> in this new code. >>>> >>>> David >>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 15.11.2014 2:22, Daniel D. Daugherty wrote: >>>>>> On 11/14/14 5:35 AM, Ivan Gerasimov wrote: >>>>>>> Hello! >>>>>>> >>>>>>> The recent fix for JDK-8059533 ((process) Make exiting process wait >>>>>>> for exiting threads [win]) caused the warning message to be printed >>>>>>> in some test environments: >>>>>>> ----------- >>>>>>> os_windows.cpp:3844 is in the newly updated >>>>>>> os::win32::exit_process_or_thread(Ept what, int exit_code) >>>>>>> ----------- >>>>>>> >>>>>>> This has been observed with debug builds on highly loaded systems. >>>>>>> >>>>>>> >>>>>>> To address the issue it is proposed to do three things: >>>>>>> 1) increase the timeout for debug builds, >>>>>>> 2) increase the maximum number of the thread handles to be stored, >>>>>>> 3) rise the priority of the exiting threads, if we need to wait for >>>>>>> them. >>>>>>> >>>>>>> Would you please help review the fix? >>>>>>> >>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064694 >>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8064694/0/webrev/ >>>>>> src/os/windows/vm/os_windows.cpp >>>>>> >>>>>> line 3784: #define MAX_EXIT_HANDLES NOT_DEBUG(32) DEBUG_ONLY(128) >>>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>>> >>>>>> That uses the smaller value for only one build config (PRODUCT). >>>>>> >>>>>> line 3785: #define EXIT_TIMEOUT NOT_DEBUG(1000) >>>>>> DEBUG_ONLY(4000) >>>>>> /*1 sec in product, 4 sec in debug*/ >>>>>> Instead of NOT_DEBUG can you use PRODUCT_ONLY? >>>>>> Instead of DEBUG_ONLY can you used NOT_PRODUCT? >>>>>> Please add spaces between the comment delimiters and the comment >>>>>> text. >>>>>> >>>>>> That uses the smaller timeout for only one build config >>>>>> (PRODUCT). >>>>>> >>>>>> line 3836 // Rise the priority... >>>>>> Typo: 'Rise' -> 'Raise' >>>>>> >>>>>> About the general idea of raising the exiting thread's priority, >>>>>> if the exiting thread is looping in some Win* OS code after this >>>>>> point, will raising the priority make the machine unusable? >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> The fix was tested on all available platforms, with the hotspot >>>>>>> testset. No failures. >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>> >>>>>> >>>> >>> >> >> >> > From volker.simonis at gmail.com Tue Nov 25 18:40:48 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 25 Nov 2014 19:40:48 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <546E2D4D.7010103@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> Message-ID: Hi Maynard, so here finally comes my version of your change. I've tested 'jstack' with no, '-F' and '-m' flags on PIDs and core files on BigEndian Linux/PPC64 and it seems to work quite stable now. I've also done some basic tests with 'jmap' with no, '-histo' and '-F' flags and 'jinfo'. All together I think that this change is now ripe for integration. You can find a webrev with all the changes baked together into one patch at: http://cr.openjdk.java.net/~simonis/webrevs/8049716/ Besides some minor fixes I've completely removed the LR-register from the PPC64 frame class because I think that it is not needed (we also don't have it in the corresponding HotSpot code. And I've added the parsing and usage of the Elf function descriptor section (i.e. the '.opd' section) for resolving native function names. I think this should not impact Little Endian PPC64 because they shouldn't have an '.opd' section but of course it would be good if you could test the new version on ppc64le. If you have any ideas for improvements please add them to the current patch and create a new webrev (if you have problems with that just send me the changes and I'll do it for you). Finally, please send out a new RFR to ppc-aix-port-dev at openjdk.java.net and serviceability-dev at openjdk.java.net so that we can finally get this reviewed and integrated (again, I can help out uploading the webrev if you can't do that). Thanks a lot for your contribution and best regards, Volker On Thu, Nov 20, 2014 at 7:05 PM, Maynard Johnson wrote: > On 11/20/2014 05:03 AM, Volker Simonis wrote: >> Hy Maynard, >> >> I've just realized that in your patch the two directory patterns >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_ppc64/*.java and >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/ppc64/*.java are absent from >> "make/sa.files". This of course breaks incremental builds. > Nice, thank you. I was wondering why incremental build didn't work. > I had resorted to using a build script that did the following: > rm build/linux-ppc64-normal-server-release/hotspot/linux_ppc64_compiler2/product/../generated/sa-jdi.jar > make all JOBS=24 > make install > > -Maynard > >> >> Regards, >> Volker >> >> >> diff -r 6f35dca1949c make/sa.files >> --- a/make/sa.files Mon Nov 17 14:47:41 2014 +0100 >> +++ b/make/sa.files Thu Nov 20 11:58:52 2014 +0100 >> @@ -94,12 +94,14 @@ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_amd64/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_x86/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_sparc/*.java \ >> +$(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/linux_ppc64/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/posix/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_amd64/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_sparc/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/solaris_x86/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/sparc/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/x86/*.java \ >> +$(AGENT_SRC_DIR)/sun/jvm/hotspot/runtime/ppc64/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/jcore/*.java \ >> $(AGENT_SRC_DIR)/sun/jvm/hotspot/tools/soql/*.java \ >> >> On Wed, Nov 19, 2014 at 7:33 PM, Volker Simonis >> wrote: >>> Hi Maynard, >>> >>> I just wanted to let you know that I'm still working on fixing the >>> bogus entries in the stack trace. I'm pretty sure they are related to >>> inlining. If you run your test program with "-XX:+PrintCompilation >>> -XX:+PrintInlining -XX:CICompilerCount=1" you'll get the following >>> output: >>> >>> .. >>> 10954 5 % test::run_test @ 59 (99 bytes) >>> @ 75 java.lang.String::getChars (62 >>> bytes) inline (hot) >>> @ 58 java.lang.System::arraycopy (0 >>> bytes) (intrinsic) >>> @ 87 test::get_my_chars (86 bytes) inline (hot) >>> @ 6 java.lang.String::getChars (62 >>> bytes) inline (hot) >>> @ 58 java.lang.System::arraycopy (0 >>> bytes) (intrinsic) >>> @ 38 java.lang.String:: (62 >>> bytes) inline (hot) >>> @ 1 java.lang.Object:: (1 >>> bytes) inline (hot) >>> @ 55 java.util.Arrays::copyOfRange >>> (63 bytes) too big >>> @ 47 java.lang.StringBuilder:: >>> (7 bytes) inline (hot) >>> @ 52 java.lang.StringBuilder::append >>> (8 bytes) executed < MinInliningThreshold times >>> @ 57 java.lang.StringBuilder::append >>> (8 bytes) executed < MinInliningThreshold times >>> @ 62 java.lang.StringBuilder::append >>> (8 bytes) executed < MinInliningThreshold times >>> @ 65 java.lang.StringBuilder::toString >>> (17 bytes) executed < MinInliningThreshold times >>> @ 79 java.lang.String::length (6 >>> bytes) inline (hot) >>> @ 82 java.io.OutputStreamWriter::write >>> (11 bytes) executed < MinInliningThreshold times >>> .. >>> >>> The stack trace I get from jstack looks as follows: >>> >>> Thread 4448: (state = IN_JAVA) >>> - test.get_my_chars(int, int, char[], java.lang.String, long) >>> @bci=43, line=15 (Compiled frame; information may be imprecise) >>> - test.run_test() @bci=87, line=35 (Compiled frame) >>> - java.lang.String.getChars(int, int, char[], int) @bci=58, line=814 >>> (Compiled frame) >>> - test.run_test() @bci=75, line=34 (Compiled frame) >>> >>> From a system perspective 'test::run_test' is one native frame, >>> because 'test::run_test' inlines all the other functions reported >>> above. HotSpot has special functionality to detect and walk these >>> inlined methods (so called "virtual frames" or "vframe"s). For some >>> reason this vframe walking doesn't seem to work in the agent. In gdb, >>> when calling "ps()" at the same point where I created the above core >>> file I'll get the following stack trace: >>> >>> (gdb) call ps() >>> >>> "Executing ps" >>> for thread: "main" #1 prio=5 os_prio=0 tid=0x00003fffb0010800 >>> nid=0x1160 runnable [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> JavaThread state: _thread_in_Java >>> Thread: 0x00003fffb0010800 [0x1160] State: _running _has_called_back >>> 0 _at_poll_safepoint 0 >>> JavaThread state: _thread_in_Java >>> >>> (guessing starting frame id=0x3fffb66ddc60 based on current fp) >>> C frame (sp=0x00003fffb66ddad0 unextended sp=0x00003fffb66ddad0, >>> fp=0x00003fffb66ddc60, real_fp=0x00003fffb66ddc60, >>> pc=0x000000001000067c) >>> 1 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, >>> fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) >>> test.get_my_chars(test.java:16) >>> 2 - frame( sp=0x00003fffb66ddc60, unextended_sp=0x00003fffb66ddc60, >>> fp=0x00003fffb66ddd60, pc=0x00003fffa0159d58) >>> test.run_test(test.java:35) >>> 3 - frame( sp=0x00003fffb66ddd60, unextended_sp=0x00003fffb66ddd60, >>> fp=0x00003fffb66dde60, pc=0x00003fffa000f518) >>> test.main(test.java:56) >>> >>> I'll keep you informed once I fixed the problem (I'll also look into >>> the .opd issue afterwards). >>> >>> Regards, >>> Volker >>> >>> >>> On Tue, Nov 18, 2014 at 12:20 AM, Maynard Johnson wrote: >>>> On 11/17/2014 01:21 PM, Volker Simonis wrote: >>>>> On Mon, Nov 17, 2014 at 6:59 PM, Maynard Johnson wrote: >>>>>> On 11/17/2014 10:20 AM, Volker Simonis wrote: >>>>>>> Hi Maynard, >>>>>>> >>>>>>> I'm currently looking at your changes. At first glance they look good. >>>>>>> >>>>>>> I could open a simple core file which contained both, interpreted and >>>>>>> compiled frames: >>>>>>> >>>>>>> $ jstack ./images/j2sdk-image/bin/java core.7034 >>>>>>> ... >>>>>>> Thread 7035: (state = IN_VM) >>>>>>> - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) >>>>>>> - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) >>>>>>> - Crash.doIt() @bci=45, line=23 (Compiled frame) >>>>>>> - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, >>>>>>> java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) >>>>>>> - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, >>>>>>> java.lang.Object[]) @bci=100, line=62 (Interpreted frame) >>>>>>> - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, >>>>>>> java.lang.Object[]) @bci=6, line=43 (Interpreted frame) >>>>>>> - java.lang.reflect.Method.invoke(java.lang.Object, >>>>>>> java.lang.Object[]) @bci=56, line=498 (Interpreted frame) >>>>>>> - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) >>>>>>> >>>>>>> The one thing that doesn't currently work is "jstack -m" (i.e. "mixed >>>>>>> mode" for java and native frames). Are you aware of this? >>>>>> Hi, Volker, >>>>>> Yeah, I knew about this problem and forgot to mention it in my patch posting. I started >>>>>> looking at it this morning, and so far, I have at least fixed the UnmappedAddressException. >>>>>> But now I'm getting different results on little endian vs big endian ppc64 systems. >>>>>> On BE, I either get no symbol names (i.e., "?????") or wrong symbol names. On LE, >>>>>> I seem to get correct symbol names for the first symbol (either __pthread_cond_wait >>>>>> or __pthread_cond_timedwait) and the last symbol (start_thread) of each stack, but >>>>>> everything in between is "?????". >>>>>> >>>>> >>>>> Maybe this is related to the fact that we have function descriptors on >>>>> BE and simple function pointers on LE. You may have a look at the >>>>> elf-decoder for ppc64 to find some more information. >>>> >>>> Yes, indeed. With the following patch, the mixed mode option works fine on ppc64 little endian, >>>> but not on big endian: >>>> >>>> Index: jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >>>> =================================================================== >>>> --- jdk9-dev.orig/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >>>> +++ jdk9-dev/hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java >>>> @@ -60,14 +60,15 @@ final public class LinuxPPC64CFrame exte >>>> return null; >>>> } >>>> >>>> - Address nextSP = sp.getAddressAt( PPC64ThreadContext.SP * address_size + PPC64_STACK_BIAS); >>>> + Address nextSP = sp.getAddressAt(0); >>>> if (nextSP == null) { >>>> return null; >>>> } >>>> - Address nextPC = sp.getAddressAt(PPC64ThreadContext.PC * address_size + PPC64_STACK_BIAS); >>>> + Address nextPC = sp.getAddressAt(2 * address_size); >>>> if (nextPC == null) { >>>> return null; >>>> } >>>> + >>>> return new LinuxPPC64CFrame(dbg, nextSP, nextPC,address_size); >>>> } >>>> >>>> ------------------------------------------------- >>>> >>>> I see that ppc64 fixups were made in the hotspot utilities (by you) about a year ago >>>> (http://cr.openjdk.java.net/~simonis/webrevs/8019929.v3/). We obviously need something >>>> similar in the hotspot agent native code that implements the JNI call 'lookupByAddress0'. >>>> I hacked the build_symtab_internal() function in hotspot/agent/src/os/linux/symtab.c and >>>> see that the symbol "offset" we're getting is really the address of the symbol's opd. >>>> I'm not sure where to start to fix this, so if you have any suggestions, I'm all ears. :-) >>>> >>>> Thanks. >>>> -Maynard >>>>> >>>>>>> >>>>>>> Regarding your "test.java" example - how do you use it? >>>>>>> >>>>>>> If I just attach with jstack to the Java process which runs >>>>>>> "test.java" I get the correct stack trace of all threads. But I think >>>>>>> that's actual no SA-functionality but a VM-feature (the same that can >>>>>>> be triggered by sending kill -SIGQUIT to java process). >>>>>>> >>>>>>> If I attach with "jstack -F" I see the problems you mentioned. First I >>>>>>> didn't saw any frame at all which confused me but then I also saw the >>>>>>> two cases mentioned by you. I'll need to have a closer look what >>>>>>> happens. >>>>>> >>>>>> I was just running the 'test' java app and, in another session, killing it with SIGSEGV. >>>>>> To be honest, I wasn't aware of the 'jstack -F' option. >>>>>> >>>>> >>>>> Another possibility I've just found out is to create a core from gdb >>>>> with the 'generate-core-file' command. You can than still inspect the >>>>> original program in gdb while debugging how jstack is working on the >>>>> core file. >>>>> >>>>>> -Maynard >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson wrote: >>>>>>>> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file, they fail with the following runtime exception: >>>>>>>> >>>>>>>> OS/CPU combination linux/ppc64 not yet supported >>>>>>>> >>>>>>>> I will post a patch set that adds this support. The patch set consists of the following patches: >>>>>>>> >>>>>>>> PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with core files >>>>>>>> >>>>>>>> PATCH 2/2: New PPC64 class files (and updates to generic files) to support linux/ppc64 Hotspot SA with core files >>>>>>>> >>>>>>>> These two patches apply cleanly to a November 13 pull of the jdk9-dev upstream sources. >>>>>>>> >>>>>>>> ------------ >>>>>>>> Open issues: >>>>>>>> ------------ >>>>>>>> 1) The jstack tool does not print a stack entry for the 'main()' method of the Java >>>>>>>> workload (attached) under test. For example: >>>>>>>> >>>>>>>> (Note: Addresses and method signatures elided for brevity.) >>>>>>>> >>>>>>>> Thread 24358: (state = IN_JAVA, current Java SP = null >>>>>>>> ) >>>>>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>>>>> ==> (Expect an entry for test.main() here) >>>>>>>> >>>>>>>> 2) The jstack tool sometimes prints what appears to be two complete stacks for the Java workload. For example: >>>>>>>> >>>>>>>> Thread 24779: (state = IN_JAVA, current Java SP = null >>>>>>>> ) >>>>>>>> - java.lang.String.getChars(...) @bci=58, line=814, pc=..., Method*=... (Compiled frame; ... imprecise) >>>>>>>> - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled frame) >>>>>>>> - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... (Compiled frame) >>>>>>>> - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled frame) >>>>>>>> >>>>>>>> Again, the 'test.main' method is missing, but there's also the anomaly of the >>>>>>>> test.run_test' method showing up twice in the stack, implying that it is called >>>>>>>> by 'test.get_my_chars' at line 15. But that that is not accurate. In fact, run_test >>>>>>>> does call String.getChars at line 33 *and* it calls test.get_my_chars at line 34 -- >>>>>>>> but these are totally distinct call graphs. Somehow, we are seeing these two distinct >>>>>>>> stacks in the core file, which seems impossible. >>>>>>>> >>>>>>>> --------- >>>>>>>> >>>>>>>> Any help offered on these two open issues would be greatly appreciated. >>>>>>>> >>>>>>>> -Maynard >>>>>>> >>>>>> >>>>> >>>> >> > From serguei.spitsyn at oracle.com Wed Nov 26 08:59:56 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Nov 2014 00:59:56 -0800 Subject: RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings Message-ID: <5475968C.40800@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8008678 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ Summary: The pseudo-strings are currently not supported in reconstitution of constant pool. This is an explanation from John Rose about what the pseudo-strings are: "We still need "live" oop constants pre-linked into the constant pool of bytecodes which implement some method handles. We use the anonymous class pseudo-string feature for that. The relevant code is here: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java These oops are what "pseudo-strings" are. The odd name refers to the fact that, even though they are random oops, they appear in the constant pool where one would expect (because of class file syntax) to find a string." ... If you really wanted to reconstitute a class file for an anonymous class, and if that class has oop patching (pseudo-strings), you would need either to (a) reconstitute the patches array handed to Unsafe.defineAnonymousClass, or (b) accept whatever odd strings were there first, as an approximation. The "odd strings" are totally insignificant, and are typically something like "CONSTANT_PLACEHOLDER_42" (see java/lang/invoke/InvokerBytecodeGenerator.java)." Reconstitution of the ConstantPool is needed for both the JVMTI GetConstantPool() and RetransformClasses(). Finally, it goes to the ConstantPool::copy_cpool_bytes(). The problem is that a pseudo-string is a patched string that does not have a reference to the string symbol anymore: unresolved_string_at(idx) == NULL The fix is to create and fill in a map from JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index to be able to restore this assotiation in the JvmtiConstantPoolReconstituter. Testing: Run: - java/lang/instrument tests - new jtreg test (see webrev) that was written by Filipp Zhinkin Thanks, Serguei From jaroslav.bachorik at oracle.com Wed Nov 26 12:57:49 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 26 Nov 2014 13:57:49 +0100 Subject: RFR 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object Message-ID: <5475CE4D.5010705@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 Webrev: http://cr.openjdk.java.net/~jbachorik/8064441/webrev.00 The test fails because of System.out.println() may induce unexpected locking. The solution is to use an already existing LockFreeLogManager library class to collect the logs in the lock-free manner and print the logs only after all the test code has been run. Thanks, -JB- From jaroslav.bachorik at oracle.com Wed Nov 26 13:23:50 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 26 Nov 2014 14:23:50 +0100 Subject: RFR 8065783: DCMD parser fails to recognize one character argument when it's positioned last Message-ID: <5475D466.2070807@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8065783 Webrev: http://cr.openjdk.java.net/~jbachorik/8065783/webrev.00 Currently, the DCMD parser fails to recognize the trailing one character long arguments. This is caused by the parser ignoring the last character when immediately following a delimiter char. The fix itself consists of checking whether the last character is indeed a delimiter char (src/share/vm/services/diagnosticFramework.cpp#68). The rest of the patch deals with testing - the WhiteBox support needs to be enhanced to handle DCMD arguments (currently only options) and custom delimiters (currently only comma). Thanks, -JB- From erik.gahlin at oracle.com Wed Nov 26 13:44:49 2014 From: erik.gahlin at or