Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "MemoryAnalyzer/OQL"

(SELECT DISTINCT)
(Sub SELECT with select items)
Line 104: Line 104:
  
 
The outer select processes the result of the sub-select row by row, with a single RowMap `Map` object representing the row. The key/value pairs are the sub-select items with the sub-select column names as the keys. If the keys are standard identifiers, i.e. generally alpha-numeric then attribute processing can be used as `v.s` rather than having to to `v.get("s2")` which can still be used, perhaps for column names with spaces.
 
The outer select processes the result of the sub-select row by row, with a single RowMap `Map` object representing the row. The key/value pairs are the sub-select items with the sub-select column names as the keys. If the keys are standard identifiers, i.e. generally alpha-numeric then attribute processing can be used as `v.s` rather than having to to `v.get("s2")` which can still be used, perhaps for column names with spaces.
 +
 +
The whole sub-select continues to return a `CustomTableResultSet` which is an `IResultTable` but this has been enhanced to also be a `List` of `RowMap` items. It is quite hard to operate in OQL on the whole result as if it is supplied to an outer select then the `Iterable` nature means it will be processed row by row.
 +
 +
<code>SELECT * FROM OBJECTS ( SELECT s, s.value AS val FROM java.lang.String s ) v</code>
 +
Shows the whole table as a list
 +
<code>SELECT eval((SELECT * FROM OBJECTS ( SELECT s, s.value AS val FROM java.lang.String s ) v))[3] FROM OBJECTS 0</code>
 +
Processes the whole table as a select item.

Revision as of 04:49, 18 November 2019

Object Query Language

Object Query Language is an SQL like language used by Memory Analyzer for exploring a heap dump.

Simple

SELECT * FROM java.lang.String

Displays all String objects as a tree.

SELECT s as String,s.value as "characters" FROM java.lang.String s

Displays all String objects as a table.

SELECT s as String,s.value as "characters", inbounds(s),inbounds(s).@length FROM java.lang.String s

String                          |characters                                 |inbounds(s)| inbounds(s).@length
--------------------------------------------------------------------------------------------------------------
java.lang.String [id=0x22e58820]|char[] [id=0x22e60f50;length=16;size=48]   |[I@620f7a39|                   1
java.lang.String [id=0x22e59150]|char[] [id=0x22e62ff0;length=6;size=24]    |[I@1f7b8d59|                   1
java.lang.String [id=0x22e5b560]|char[] [id=0x22e6b730;length=537;size=1088]|[I@28551755|                   1
--------------------------------------------------------------------------------------------------------------

There are two sorts of objects encountered with OQL, IObject which represent Java objects in the snapshot and regular Java objects generated by OQL processing.

java.lang.String [id=0x22e58820] is a IInstance representing a String from the snapshot.

char[] [id=0x22e60f50;length=16;size=48] is an IPrimitiveArray representing a character array from the snapshot.

[I@620f7a39 is a regular Java integer array holding a several of ints which are the object IDs Memory Analyzer uses to represent IObjects in the snapshot.


OQL (Memory Analyzer) versus SQL (MAT/Calcite)

As well as the built-in OQL, there is an extension plug-in for MAT called MAT Calcite which adds SQL processing

Topic OQL SQL
General syntax SELECT s FROM java.lang.String s SELECT s.this FROM "java.lang.String" s
Built-in functions SELECT toString(s), classof(s), s.@objectAddress, s.@usedHeapSize, s.@retainedHeapSize FROM java.lang.String s SELECT toString(s.this),getType(s.this),getAddress(s.this),shallowSize(s.this),retainedSize(s.this) FROM "java.lang.String" s
More functions SELECT h, h[0:-1].size(), h.table, h.table.@length, h.modCount, h.getField("modCount") FROM java.util.HashMap h SELECT h.this,getSize(h.this),h.this['table'],length(h.this['table']), h.this['modCount'], getField(h.this,'modCount') FROM "java.util.HashMap" h

Enhancements in November 2019

Various updates and enhancements have been made to OQL under 552879: OQL enhancements for sub-selects, maps, context providers, DISTINCT. These are available from snapshot builds for testing and are subject to change. Please comment on the bug, forum or development mailing list

SELECT DISTINCT

`DISTINCT` used to just operate on the results of a query if it returned objects rather than general select items.

SELECT DISTINCT OBJECTS classof(s) FROM "java.lang..S*" s

SELECT * FROM OBJECTS "java.lang.S.*"

`DISTINCT` now also operates on SELECTs with select items. It uses the whole row considered as a list as the item to be considered as distinct. It also uses the optimization that the input FROM items are also considered as being distinct (either as ints/IObjects or more general `FROM` items).

SELECT DISTINCT classof(s) FROM "java.lang..S*" s

Sub SELECT with select items

sub-selects were permitted where the sub-select returned an object list.

SELECT v, v.@length FROM OBJECTS ( SELECT OBJECTS s.value FROM java.lang.String s ) v

sub-selects are now permitted which have select items.

SELECT v,v.s,v.val FROM OBJECTS ( SELECT s,s.value as val FROM java.lang.String s ) v

Row                                                                                |Object                          |Array
--------------------------------------------------------------------------------------------------------------------------------------------------------------
{s=java.lang.String [id=0x26ba8a30], val=char[] [id=0x26ba8a48;length=14;size=40]} |java.lang.String [id=0x26ba8a30]|char[] [id=0x26ba8a48;length=14;size=40]
{s=java.lang.String [id=0x26ba8998], val=char[] [id=0x26ba89b0;length=56;size=128]}|java.lang.String [id=0x26ba8998]|char[] [id=0x26ba89b0;length=56;size=128]
{s=java.lang.String [id=0x26ba8160], val=char[] [id=0x26ba8178;length=56;size=128]}|java.lang.String [id=0x26ba8160]|char[] [id=0x26ba8178;length=56;size=128]
{s=java.lang.String [id=0x26b9d390], val=char[] [id=0x26b9d3a8;length=15;size=48]} |java.lang.String [id=0x26b9d390]|char[] [id=0x26b9d3a8;length=15;size=48]
{s=java.lang.String [id=0x26b9d358], val=char[] [id=0x26b9d370;length=8;size=32]}  |java.lang.String [id=0x26b9d358]|char[] [id=0x26b9d370;length=8;size=32]
--------------------------------------------------------------------------------------------------------------------------------------------------------------

The outer select processes the result of the sub-select row by row, with a single RowMap `Map` object representing the row. The key/value pairs are the sub-select items with the sub-select column names as the keys. If the keys are standard identifiers, i.e. generally alpha-numeric then attribute processing can be used as `v.s` rather than having to to `v.get("s2")` which can still be used, perhaps for column names with spaces.

The whole sub-select continues to return a `CustomTableResultSet` which is an `IResultTable` but this has been enhanced to also be a `List` of `RowMap` items. It is quite hard to operate in OQL on the whole result as if it is supplied to an outer select then the `Iterable` nature means it will be processed row by row.

SELECT * FROM OBJECTS ( SELECT s, s.value AS val FROM java.lang.String s ) v Shows the whole table as a list SELECT eval((SELECT * FROM OBJECTS ( SELECT s, s.value AS val FROM java.lang.String s ) v))[3] FROM OBJECTS 0 Processes the whole table as a select item.

Back to the top