RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Daniil Titov daniil.x.titov at oracle.com
Tue Jul 17 21:55:35 UTC 2018


Hi Serguei,

The test starts the event handler (nsk.share.jdi.EventHandler) and then iterates several times calling testSourceFilter() method passing there different parameters.  The testSourceFilter() method does the following:
      1.  creates a ClassPrepareRequest object
      2. registers new ClassPrepareEventListener
      3. sends a command to debuggee to a load test class 
      4. waits till the debuggee performed the command
      5. removes ClassPrepareEventListener
      6. checks if a ClassPrepareEvent was received
 

Upon its start the EventHandler creates a default list of events listeners. The last listener in this list handles unexpected events (that are events not processed by the previous listeners)

cat -n  test/hotspot/jtreg/vmTestbase/nsk/share/jdi/EventHandler.java
  /**
   251	     * This method sets up default listeners.
   252	     */
   253	    private void createDefaultListeners() {
   254	        /**
   255	         * This listener catches up all unexpected events.
   256	         *
   257	         */
   258	        addListener(
   259	                new EventListener() {
   260	                    public boolean eventReceived(Event event) {
   261	                        log.complain("EventHandler>  Unexpected event: " + event.getClass().getName());
   262	                        unexpectedEventCaught = true;
   263	                        return true;
   264	                    }
   265	                }
   266	        );
   267	

On step 2 above the ClassPrepareEventListener is added at the head of the list of the listeners. It handles ClassPrepareEvents and prevents the next listeners from being invoked by returning "true" from its eventReceived(Event) method. 

With Graal turned on after step 1 the JVMTI compiler thread starts sending class prepare events for classes it compiles. If any of such event is dispatched after step 5 (when ClassPrepareEventListener  is removed) there is no any registered listeners to handle it and this event is handled by the "unexpected events listener" (see above) that marks the test as failed. 

That is why DefaultClassPrepareEventListener is needed: to process ClassPrepare events dispatched after ClassPrepareEventListener  is unregistered inside testSourceFilter() method.

Please see below the new webrev with the changes you suggested.

Webrev: http://cr.openjdk.java.net/~dtitov/8204695/webrev.02/


Thanks!

Best regards,
Daniil


From: "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com>
Date: Tuesday, July 17, 2018 at 1:34 PM
To: Daniil Titov <daniil.x.titov at oracle.com>, "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>
Subject: Re: RFR 8204695: [Graal] vmTestbase/nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002/addSourceNameFilter002.java fails

Hi Daniil,

Not sure, I fully understand the fix.
So, let's start from some questions.

Why the DefaultClassPrepareEventListener is needed?
Is it not enough to filter out the other threads in the
ClassPrepareEventListener.eventReceived() method ?
 243         eventHandler.startListening();
 244         // Add a listener to handle class prepared events fired by other ( e.g. compiler) threads.
 245         // The listener should be added after the event listener is started to ensure that it called before
 246         // the default event listener that handles unexpected events.
 247         eventHandler.addListener(new DefaultClassPrepareEventListener());

  It is still not clear why the default listener is added
  after the listening is started but not before.
  If the default listener is really needed then could you, please,
  split the lines above and L129, L160 to make a little bit shorter?
  
  I'd also suggest to replace "class prepared events" at L244
  with "ClassPrepare event" or "class prepare event".
  There is also an unneeded space in the "( e.g. compiler)".

Thanks,
Serguei


On 7/17/18 01:20, Daniil Titov wrote:
Please review the change that fix the JDI test when running with Graal.

The problem here is that the test verifies that a class prepare event is generated when the target VM loads a specific test class, but with Graal turned on additional class prepare events are generated by the compiler threads. The test doesn't expect them and fails. The fix ensures that additional class prepare events are ignored by the test and properly handled.

Bug: https://bugs.openjdk.java.net/browse/JDK-8204695 
Webrev: http://cr.openjdk.java.net/~dtitov/8204695/webrev.01/

Thanks!
--Daniil









More information about the serviceability-dev mailing list