<reachable-objects> set description tag doesn't work

[motravo]

As far as I can tell, the <reachable-objects> set description tag does not do what the documentation says it should do.

For example, with the following application:

Code: Select all

public class Test {
    Integer my_int;
    public static void main( String args[] ) throws Exception {
        Test test = new Test();
        test.my_int = new Integer( 3 );
        Thread.sleep(10000000); // allow time for YJP memory snapshot
    }
}

I take the memory snapshot, and then choose "Memory->Predefined Set..." and select a set defined as:

Code: Select all

<reachable-objects>
  <from>
    <objects class="Test" />
  </from>
  <object-filter>
    <objects class="*" />
  </object-filter>
  <field-filter>
    <class name="Test">
      <allowed field="my_int" />
    </class>
  </field-filter>
</reachable-objects>

According to the documentation, I should read this set as "all objects reachable through the my_int field of a Test object".

However, the resulting set contains 0 objects of type java.lang.Integer.

Basically, the <reachable-objects> tag should be simplified, YJP should implement it correctly, and the documentation should be changed to accurately describe what it does.

[/code]

[motravo]

This is with YJP 5.0.3.

[Anton Katilin]

Hi,

There's indeed a bug in field filter processing. The maintanance release 5.0.4 will contain the fix. It will be available today or tomorrow.

Basically, the <reachable-objects> tag should be simplified

Any suggestions are welcome.


Best regards,
Anton

[motravo]

Wow...amazing turnaround time!

Regarding simplification, here was my original set:

Code: Select all

<reachable-objects> 
  <from> 
    <objects class="Test" /> 
  </from> 
  <object-filter> 
    <objects class="*" /> 
  </object-filter> 
  <field-filter> 
    <class name="Test"> 
      <allowed field="my_int" /> 
    </class> 
  </field-filter> 
</reachable-objects>

First, isn't the <object-filter> element completely redundant? If I want to filter by Integer objects, then I should just do:

Code: Select all

<and>
  <objects class="java.lang.Integer" /> 
  <reachable-objects> 
    <from> 
      <objects class="Test" /> 
    </from> 
    <field-filter> 
      <class name="Test"> 
        <allowed field="my_int" /> 
      </class> 
    </field-filter> 
  </reachable-objects>
</and>

Second, the <field-filter> should be optional, since, most of the time, I just want <reachable-objects> to look somewhat like <retained-objects>. For "the set of objects reachable from Test (including Test)":

Code: Select all

  <reachable-objects> 
    <from> 
      <objects class="Test" /> 
    </from> 
  </reachable-objects>

Then, the documentation should be clearer about <field-filter>. Does the filter keep only the elements that are directly referred to by the specified field of the specified class? Or elements for which there is some path of references that goes through the specified field of the specified class? Or elements for which there is some path of references from the <from> set that goes through the specified field of the specified class?

Thanks!

[Anton Katilin]

object-filter is not redundant.

It is intended to limit objects that constitute the reachable tree. In general case, if there's a sequence like A -> B -> A, then applying of object filter that allows only A is not the same as further applying of 'or'.

I agree that it is convenient to use "transparent" filters by default, i.e. 'object-filter' if omitted should allow objects of any class, and 'field-filter' should allow any references. I'll add corresponding request, as well as to clarify the docs.

[motravo]

I don't follow what you mean about <object-filter>.

I would use <and>, not <or>.

In your example,
Using an <object-filter> to filter on A would return instances of A.
Using <and> (without <object-filter>) would return instance of A.
What's the difference?

[Anton Katilin]

Yes, my mistake, please read <and> instead of <or>

If there's a sequence A -> B -> A, with <object-filter> only the first A will be returned, because the second A is reachable through B that is not allowed. If there's no <object-filter>, further <and> will return both A. In some cases this is important, e.g. there's an example called "Lost UI" - the formula wouldn't be correct if there was no <object-filter>. Anyway, since this is a tricky issue, the best is to allow by default <object-filter> for simplier cases.

By the way, 5.0.4 is available now for download.