From carusso at redhat.com  Thu Aug  1 10:52:45 2019
From: carusso at redhat.com (Carmine Vincenzo Russo)
Date: Thu, 1 Aug 2019 12:52:45 +0200
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
Message-ID: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>

Hi,

The attached patch addresses the issue JMC-5473[0] in which a search
feature for the Automated Analysis Result Table was lacking.

In ResultOverview.java, I added the text component and a simple layout to
give the page more consistency when the table is displayed.
I also produced ResultOverviewTest.java to test if the table has
components, the search feature operates, and two more to check if the
behaviour is what we expect with a nonsense search and a specific search.

A side note, since there were no tests for the Automated Analysis Result, I
had to add the tab in JfrUi and allow the record analysis in two other
classes, OldRecordingsVerificationTest.java and JfrRecordingTest.java,
because they go through all the tabs listed in JfrUi during their tests.

How does it look?

Regards,
Carmine

[0] https://bugs.openjdk.java.net/browse/JMC-5473

-- 
Carmine Vincenzo Russo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5473-0.patch
Type: text/x-patch
Size: 13758 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190801/38ee1eca/5473-0.patch>

From jkang at redhat.com  Thu Aug  1 14:16:05 2019
From: jkang at redhat.com (Jie Kang)
Date: Thu, 1 Aug 2019 10:16:05 -0400
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
Message-ID: <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>

On Thu, Aug 1, 2019 at 6:53 AM Carmine Vincenzo Russo
<carusso at redhat.com> wrote:
>
> Hi,
>
> The attached patch addresses the issue JMC-5473[0] in which a search
> feature for the Automated Analysis Result Table was lacking.
>
> In ResultOverview.java, I added the text component and a simple layout to
> give the page more consistency when the table is displayed.
> I also produced ResultOverviewTest.java to test if the table has
> components, the search feature operates, and two more to check if the
> behaviour is what we expect with a nonsense search and a specific search.
>
> A side note, since there were no tests for the Automated Analysis Result, I
> had to add the tab in JfrUi and allow the record analysis in two other
> classes, OldRecordingsVerificationTest.java and JfrRecordingTest.java,
> because they go through all the tabs listed in JfrUi during their tests.
>
> How does it look?

Hi Carmine,

Thanks for doing this; the tests are appreciated! I have some issues
to address below:

diff --git a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/R
esultOverview.java
b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/ov
erview/ResultOverview.java
--- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
erview.java
+++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
erview.java
[...]
-
+

* Whitespace additions like the example shown above should be removed;
there are others in the patch.

-                       Map<Result, DataPageDescriptor> map = createResultMap();
+                       GridLayout layout = new GridLayout(1, true);
+                       this.form.getBody().setLayout(layout);
+                       text = new Text(form.getBody(), SWT.BORDER |
SWT.HORIZONTAL | SWT.SEARCH | SWT.RESIZE);
+                       text.setLayoutData(new GridData(SWT.FILL,
SWT.DEFAULT, true, false));
+                       text.setMessage(Messages.ResultOverview_SEARCH_TABLE);
+                       text.setToolTipText(Messages.ResultOverview_SEARCH_BAR);
+                       Map<Result, DataPageDescriptor> map =
createResultMap(text.getText());
                        table = new ResultTableUi(form, toolkit,
editor, loadedState, map);
+                       ModifyListener listener = new ModifyListener() {
+                               @Override
+                               public void modifyText(ModifyEvent e) {
+                                       Map<Result,
DataPageDescriptor> map = createResultMap(text.getText());
+                                       table.updateInput(map);
+                               }
+                       };
+                       text.addModifyListener(listener);
                }
* The additions to the Table UI done above should occur in the Table
UI code, rather than in the overview which is managing the HTML UI and
the Table UI, ie. the above should be within ResultTableUi.java

* When switching to the Table and then back to the HTML, the resulting
view is strange; see the linked image [1]. This may have to do with
how the form's layout is modified by your addition. This form is the
parent for the ResultTableUi. I would add children to it with custom
layouts, but I would not modify the 'parent' layout itself.

https://imgur.com/a/nS1m2T2


Regards,

>
> Regards,
> Carmine
>
> [0] https://bugs.openjdk.java.net/browse/JMC-5473
>
> --
> Carmine Vincenzo Russo

From carusso at redhat.com  Thu Aug  1 14:24:11 2019
From: carusso at redhat.com (Carmine Vincenzo Russo)
Date: Thu, 1 Aug 2019 16:24:11 +0200
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
Message-ID: <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>

Hi Jie,

Thanks for pointing out these errors, I'll fix them and get back with an
updated version.

Thanks,
Carmine

On Thu, Aug 1, 2019 at 4:16 PM Jie Kang <jkang at redhat.com> wrote:

> On Thu, Aug 1, 2019 at 6:53 AM Carmine Vincenzo Russo
> <carusso at redhat.com> wrote:
> >
> > Hi,
> >
> > The attached patch addresses the issue JMC-5473[0] in which a search
> > feature for the Automated Analysis Result Table was lacking.
> >
> > In ResultOverview.java, I added the text component and a simple layout to
> > give the page more consistency when the table is displayed.
> > I also produced ResultOverviewTest.java to test if the table has
> > components, the search feature operates, and two more to check if the
> > behaviour is what we expect with a nonsense search and a specific search.
> >
> > A side note, since there were no tests for the Automated Analysis
> Result, I
> > had to add the tab in JfrUi and allow the record analysis in two other
> > classes, OldRecordingsVerificationTest.java and JfrRecordingTest.java,
> > because they go through all the tabs listed in JfrUi during their tests.
> >
> > How does it look?
>
> Hi Carmine,
>
> Thanks for doing this; the tests are appreciated! I have some issues
> to address below:
>
> diff --git
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/R
> esultOverview.java
>
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/ov
> erview/ResultOverview.java
> ---
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> erview.java
> +++
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> erview.java
> [...]
> -
> +
>
> * Whitespace additions like the example shown above should be removed;
> there are others in the patch.
>
> -                       Map<Result, DataPageDescriptor> map =
> createResultMap();
> +                       GridLayout layout = new GridLayout(1, true);
> +                       this.form.getBody().setLayout(layout);
> +                       text = new Text(form.getBody(), SWT.BORDER |
> SWT.HORIZONTAL | SWT.SEARCH | SWT.RESIZE);
> +                       text.setLayoutData(new GridData(SWT.FILL,
> SWT.DEFAULT, true, false));
> +
>  text.setMessage(Messages.ResultOverview_SEARCH_TABLE);
> +
>  text.setToolTipText(Messages.ResultOverview_SEARCH_BAR);
> +                       Map<Result, DataPageDescriptor> map =
> createResultMap(text.getText());
>                         table = new ResultTableUi(form, toolkit,
> editor, loadedState, map);
> +                       ModifyListener listener = new ModifyListener() {
> +                               @Override
> +                               public void modifyText(ModifyEvent e) {
> +                                       Map<Result,
> DataPageDescriptor> map = createResultMap(text.getText());
> +                                       table.updateInput(map);
> +                               }
> +                       };
> +                       text.addModifyListener(listener);
>                 }
> * The additions to the Table UI done above should occur in the Table
> UI code, rather than in the overview which is managing the HTML UI and
> the Table UI, ie. the above should be within ResultTableUi.java
>
> * When switching to the Table and then back to the HTML, the resulting
> view is strange; see the linked image [1]. This may have to do with
> how the form's layout is modified by your addition. This form is the
> parent for the ResultTableUi. I would add children to it with custom
> layouts, but I would not modify the 'parent' layout itself.
>
> https://imgur.com/a/nS1m2T2
>
>
> Regards,
>
> >
> > Regards,
> > Carmine
> >
> > [0] https://bugs.openjdk.java.net/browse/JMC-5473
> >
> > --
> > Carmine Vincenzo Russo
>


-- 
Carmine Vincenzo Russo

From jmatsuok at redhat.com  Fri Aug  2 19:25:50 2019
From: jmatsuok at redhat.com (Joshua Matsuoka)
Date: Fri, 2 Aug 2019 15:25:50 -0400
Subject: Review Request for JMC-5923: Add allocation pressure column to
 stacktrace view
In-Reply-To: <CAN4WuHa-SY0Bi8Xfkjc8CToDFb-C=gmZVBCwRCBv=y2HFB5EZg@mail.gmail.com>
References: <CAN4WuHYqvhOZcOSu5gL51GOWA4fVuSvPU7K_xT0-ayBEWcForQ@mail.gmail.com>
 <CAN4WuHa-SY0Bi8Xfkjc8CToDFb-C=gmZVBCwRCBv=y2HFB5EZg@mail.gmail.com>
Message-ID: <CAGLrAXNtO-8=+1VnSd31HTPHtSzXz5EbTOHijNZ3yV3bWaSHEw@mail.gmail.com>

Hi Salman,

The changes look good to me, a few notes though

a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
+++
b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
@@ -435,6 +435,7 @@ public class Messages extends NLS {
  public static String SELECT_RANGE_WIZARD_TEXT;
  public static String SELECT_RANGE_WIZARD_TITLE;
  public static String SELECT_RANGE_WIZARD_TO_MUCH_SELECTED_WARNING;

s/TO_MUCH_SELECTED/TOO_MUCH_SELECTED, although that typo was there prior to
these changes, it still would be good to fix

It would also be good to have a test for these changes to make sure that
they get calculated correctly.

Nice Work!

Cheers,

- Josh


On Fri, Jul 26, 2019 at 10:15 AM Salman Siddiqui <sasiddiq at redhat.com>
wrote:

> Hi all,
>
> Here is a webrev for the patch:
> https://cr.openjdk.java.net/~aptmac/JMC-5923/webrev.00/
>
> Thanks,
> Salman
>
> On Thu, Jul 25, 2019 at 9:42 PM Salman Siddiqui <sasiddiq at redhat.com>
> wrote:
>
> > Hi all,
> >
> > Here is patch that adds a column to the stacktrace view to display
> > normalized allocation pressure. The allocation pressure is a ratio of the
> > size of the allocations of a particular class to the size of total
> > allocations from that stacktrace frame.
> >
> > Also, as per suggestion from Marcus, I have normalized the count that is
> > displayed in the stacktrace view (this is similar to what is already
> being
> > displayed in the tool tip for the count).
> >
> > JIRA issue: https://bugs.openjdk.java.net/browse/JMC-5923
> > Related GitHub issue: https://github.com/JDKMissionControl/jmc/issues/6
> >
> > Patch is below.
> >
> > Thanks,
> > Salman
> >
> >
> > diff --git
> >
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> >
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> > index 7b576f3..cd8234a 100644
> > ---
> >
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> > +++
> >
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> > @@ -435,6 +435,7 @@ public class Messages extends NLS {
> >   public static String SELECT_RANGE_WIZARD_TEXT;
> >   public static String SELECT_RANGE_WIZARD_TITLE;
> >   public static String SELECT_RANGE_WIZARD_TO_MUCH_SELECTED_WARNING;
> > + public static String STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME;
> >   public static String STACKTRACE_VIEW_COUNT_COLUMN_NAME;
> >   public static String STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY;
> >   public static String STACKTRACE_VIEW_FRAME_GROUP_CHOOSE;
> > diff --git
> >
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> >
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> > index 2b51e80..9d96016 100644
> > ---
> >
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> > +++
> >
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> > @@ -92,10 +92,16 @@ import org.eclipse.ui.part.ViewPart;
> >  import org.openjdk.jmc.common.IDisplayable;
> >  import org.openjdk.jmc.common.IMCFrame;
> >  import org.openjdk.jmc.common.IState;
> > +import org.openjdk.jmc.common.collection.IteratorToolkit;
> >  import org.openjdk.jmc.common.collection.SimpleArray;
> > +import org.openjdk.jmc.common.item.IItem;
> >  import org.openjdk.jmc.common.item.IItemCollection;
> > +import org.openjdk.jmc.common.item.IItemFilter;
> > +import org.openjdk.jmc.common.item.ItemFilters;
> >  import org.openjdk.jmc.common.unit.UnitLookup;
> >  import org.openjdk.jmc.common.util.StateToolkit;
> > +import org.openjdk.jmc.flightrecorder.jdk.JdkAggregators;
> > +import org.openjdk.jmc.flightrecorder.jdk.JdkFilters;
> >  import org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator;
> >  import
> >
> org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator.FrameCategorization;
> >  import
> org.openjdk.jmc.flightrecorder.stacktrace.StacktraceFormatToolkit;
> > @@ -181,7 +187,7 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   private static final Color COUNT_COLOR = SWTColorToolkit.getColor(new
> > RGB(100, 200, 100));
> >   private static final String SIBLINGS_IMG_KEY = "siblingsColor";
> > //$NON-NLS-1$
> >   private static final Color SIBLINGS_COUNT_COLOR =
> > SWTColorToolkit.getColor(new RGB(170, 250, 170));
> > - private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150};
> > + private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150, 150};
> >   private static final String THREAD_ROOT_KEY = "threadRootAtTop";
> > //$NON-NLS-1$
> >   private static final String FRAME_OPTIMIZATION_KEY =
> > "distinguishFramesByOptimization"; //$NON-NLS-1$
> >   private static final String FRAME_CATEGORIZATION_KEY =
> > "distinguishFramesCategorization"; //$NON-NLS-1$
> > @@ -491,7 +497,7 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   new StacktraceViewToolTipSupport(viewer);
> >   MCContextMenuManager mm =
> > MCContextMenuManager.create(viewer.getControl());
> >   CopySelectionAction copyAction = new CopySelectionAction(viewer,
> > - FormatToolkit.selectionFormatter(stackTraceLabelProvider,
> > countLabelProvider));
> > + FormatToolkit.selectionFormatter(stackTraceLabelProvider,
> > countLabelProvider, allocPressureLabelProvider));
> >   InFocusHandlerActivator.install(viewer.getControl(), copyAction);
> >   mm.appendToGroup(MCContextMenuManager.GROUP_EDIT, copyAction);
> >   mm.appendToGroup(MCContextMenuManager.GROUP_EDIT,
> > CopySettings.getInstance().createContributionItem());
> > @@ -515,6 +521,8 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   .setLabelProvider(stackTraceLabelProvider);
> >   buildColumn(viewer, Messages.STACKTRACE_VIEW_COUNT_COLUMN_NAME,
> > SWT.RIGHT, columnWidths[1])
> >   .setLabelProvider(countLabelProvider);
> > + buildColumn(viewer,
> Messages.STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME,
> > SWT.RIGHT, columnWidths[2])
> > + .setLabelProvider(allocPressureLabelProvider);
> >
> >   PlatformUI.getWorkbench().getHelpSystem().setHelp(viewer.getControl(),
> > HELP_CONTEXT_ID);
> >
> > @@ -731,7 +739,13 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   private final ColumnLabelProvider countLabelProvider = new
> > ColumnLabelProvider() {
> >   @Override
> >   public String getText(Object element) {
> > - return Integer.toString(((StacktraceFrame) element).getItemCount());
> > + // display normalized count (percentage of total count)
> > + StacktraceFrame frame = (StacktraceFrame) element;
> > + Fork rootFork = getRootFork(frame.getBranch().getParentFork());
> > + int itemCount = frame.getItemCount();
> > + int totalCount = rootFork.getItemsInFork();
> > + return UnitLookup.PERCENT_UNITY.quantity(itemCount / (double)
> totalCount)
> > + .displayUsing(IDisplayable.AUTO);
> >   }
> >
> >   @Override
> > @@ -756,6 +770,31 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   }
> >   };
> >
> > + private final ColumnLabelProvider allocPressureLabelProvider = new
> > ColumnLabelProvider() {
> > + @Override
> > + public String getText(Object element) {
> > + StacktraceFrame frame = (StacktraceFrame) element;
> > +
> > + SimpleArray<IItem> items = frame.getItems();
> > + Branch branch = frame.getBranch();
> > + SimpleArray<IItem> allItems = new
> > SimpleArray<IItem>(branch.getFirstFrame().getItems().elements());
> > + for (StacktraceFrame f: branch.getTailFrames()) {
> > + allItems.addAll(f.getItems().elements());
> > + }
> > +
> > + IItemCollection itemsCollection =
> > ItemCollectionToolkit.build(IteratorToolkit.toList(items.iterator(),
> > items.size()).stream());
> > + IItemCollection allItemsCollection =
> > ItemCollectionToolkit.build(IteratorToolkit.toList(allItems.iterator(),
> > items.size()).stream());
> > +
> > + try {
> > + Double itemsAlloc =
> >
> itemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue();
> > + Double allItemsAlloc =
> >
> allItemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue();
> > + return String.format("%.1f %%", (itemsAlloc / allItemsAlloc ) * 100);
> > + } catch (NullPointerException e) { // ALLOCATION_TOTAL is only
> available
> > in Memory page
> > + return "";
> > + }
> > + }
> > + };
> > +
> >   private final ColumnLabelProvider stackTraceLabelProvider = new
> > ColumnLabelProvider() {
> >
> >   @Override
> > diff --git
> >
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> >
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> > index cd954bd..96ce600 100644
> > ---
> >
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> > +++
> >
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> > @@ -418,6 +418,7 @@ STORED_SELECTIONS_SIZE_UNPARSABLE=Number of stored
> > selections to keep: {0}
> >  STORE_SELECTION_ACTION=Store Selection
> >  STORE_AND_ACTIVATE_SELECTION_ACTION=Store and Set As Focused Selection
> >
> > +STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME=Allocation Pressure
> >  STACKTRACE_VIEW_COUNT_COLUMN_NAME=Count
> >  STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY=Distinguish Frames By
> >  STACKTRACE_VIEW_FRAME_GROUP_CHOOSE=Choose Frame Group
> >
> >
> >
>

From florian.david at datadoghq.com  Sun Aug  4 16:12:11 2019
From: florian.david at datadoghq.com (Florian David)
Date: Sun, 4 Aug 2019 18:12:11 +0200
Subject: Review request for JM-6544: Add support to parse Java internal
 version of Zulu JVM
Message-ID: <CADm1rcYi1FiA6b+GkujhWw8OG+_5gO5fdOoBHiJKRRX2_hb-QQ@mail.gmail.com>

Hi,


Please find attached a patch to solve an error that arise when parsing Zulu
internal version [0]. I also added a test with a representative set of Java
internal versions of the Zulu JVM, even if it's far from covering every
single case.


Regards,

Florian


[0] https://bugs.openjdk.java.net/browse/JMC-6544

From florian.david at datadoghq.com  Mon Aug  5 08:31:25 2019
From: florian.david at datadoghq.com (Florian David)
Date: Mon, 5 Aug 2019 10:31:25 +0200
Subject: Review request for JM-6544: Add support to parse Java internal
 version of Zulu JVM
In-Reply-To: <CADm1rcYi1FiA6b+GkujhWw8OG+_5gO5fdOoBHiJKRRX2_hb-QQ@mail.gmail.com>
References: <CADm1rcYi1FiA6b+GkujhWw8OG+_5gO5fdOoBHiJKRRX2_hb-QQ@mail.gmail.com>
Message-ID: <CADm1rcaQ_y5GXQypfZXi1dErdkWst7E02tBbuf8fnB=6orRppg@mail.gmail.com>

I have been told that the patch was removed from the previous mail.
Please find a web review instead:

JIRA: https://bugs.openjdk.java.net/browse/JMC-6544
Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6544/webrev.0/

On Sun, Aug 4, 2019 at 6:12 PM Florian David <florian.david at datadoghq.com>
wrote:

> Hi,
>
>
> Please find attached a patch to solve an error that arise when parsing
> Zulu internal version [0]. I also added a test with a representative set of
> Java internal versions of the Zulu JVM, even if it's far from covering
> every single case.
>
>
> Regards,
>
> Florian
>
>
> [0] https://bugs.openjdk.java.net/browse/JMC-6544
>
>
>
>

From neugens at redhat.com  Mon Aug  5 08:45:31 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 5 Aug 2019 10:45:31 +0200
Subject: Review request for JM-6544: Add support to parse Java internal
 version of Zulu JVM
In-Reply-To: <CADm1rcaQ_y5GXQypfZXi1dErdkWst7E02tBbuf8fnB=6orRppg@mail.gmail.com>
References: <CADm1rcYi1FiA6b+GkujhWw8OG+_5gO5fdOoBHiJKRRX2_hb-QQ@mail.gmail.com>
 <CADm1rcaQ_y5GXQypfZXi1dErdkWst7E02tBbuf8fnB=6orRppg@mail.gmail.com>
Message-ID: <4ff6f1a4-d421-fa67-7607-8a36f3c78792@redhat.com>

On 05/08/2019 10:31, Florian David wrote:
> I have been told that the patch was removed from the previous mail.
> Please find a web review instead:
> 
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6544
> Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6544/webrev.0/

Hi Florian,

To be honest, I already expressed concerns about this
FlightRecordingSupportRule, I don't think it's a good idea to make JMC
know every single java vendor out there in the world.

I would rather prefer such patches are either internal to vendors and
not exposed in the upstream project, but more generally we should rework
this mechanisms in order to be vendor-agnostic rather than add more
special cases.

Cheers,
Mario

> On Sun, Aug 4, 2019 at 6:12 PM Florian David <florian.david at datadoghq.com>
> wrote:
> 
>> Hi,
>>
>>
>> Please find attached a patch to solve an error that arise when parsing
>> Zulu internal version [0]. I also added a test with a representative set of
>> Java internal versions of the Zulu JVM, even if it's far from covering
>> every single case.
>>
>>
>> Regards,
>>
>> Florian
>>
>>
>> [0] https://bugs.openjdk.java.net/browse/JMC-6544
>>
>>
>>
>>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From hdafgard at gmail.com  Mon Aug  5 16:43:35 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Mon, 5 Aug 2019 18:43:35 +0200
Subject: Review request for JM-6544: Add support to parse Java internal
 version of Zulu JVM
In-Reply-To: <4ff6f1a4-d421-fa67-7607-8a36f3c78792@redhat.com>
References: <CADm1rcYi1FiA6b+GkujhWw8OG+_5gO5fdOoBHiJKRRX2_hb-QQ@mail.gmail.com>
 <CADm1rcaQ_y5GXQypfZXi1dErdkWst7E02tBbuf8fnB=6orRppg@mail.gmail.com>
 <4ff6f1a4-d421-fa67-7607-8a36f3c78792@redhat.com>
Message-ID: <CADFkdVQ9qt_m1o1xG2JJO7wpMpc3o+3pQeN2g5R_teKWR3_ZbQ@mail.gmail.com>

Hi all,

I think that this is a more involved discussion that should definitely be
had. Originally we only built JMC to support known JDKs built by Oracle
where we could be assumed to know enough details about the features of each
version to depend on only version numbers to decide whether to check for
certain behaviours in the rules. This is in e.g. the String Deduplication
rule and the Code Cache rule, they're already depending on vendor, albeit
implicitly.

To fix this properly we could perhaps build some support in the core JMC
APIs for checking Java Vendor and allowing downstream implementations to
react to different vendors, rather than just to which JDK version is used.
We would then have to replace all references to RulesToolkit.getJavaVersion
used for determining runtime features with both checks for vendor and
version.

Regardless, we should still fix this issue and after looking through usages
of the JavaVersion methods I've found that most of them check for a
potential null return value and only two don't (and they both have implicit
vendor dependencies). So the best fix is probably to add null checks to the
FlightRecordingSupportRule:113 with a N/A result and the
CodeCachePageUI:294.


Cheers,
Henrik Dafg?rd


On Mon, 5 Aug 2019 at 10:46, Mario Torre <neugens at redhat.com> wrote:

> On 05/08/2019 10:31, Florian David wrote:
> > I have been told that the patch was removed from the previous mail.
> > Please find a web review instead:
> >
> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6544
> > Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6544/webrev.0/
>
> Hi Florian,
>
> To be honest, I already expressed concerns about this
> FlightRecordingSupportRule, I don't think it's a good idea to make JMC
> know every single java vendor out there in the world.
>
> I would rather prefer such patches are either internal to vendors and
> not exposed in the upstream project, but more generally we should rework
> this mechanisms in order to be vendor-agnostic rather than add more
> special cases.
>
> Cheers,
> Mario
>
> > On Sun, Aug 4, 2019 at 6:12 PM Florian David <
> florian.david at datadoghq.com>
> > wrote:
> >
> >> Hi,
> >>
> >>
> >> Please find attached a patch to solve an error that arise when parsing
> >> Zulu internal version [0]. I also added a test with a representative
> set of
> >> Java internal versions of the Zulu JVM, even if it's far from covering
> >> every single case.
> >>
> >>
> >> Regards,
> >>
> >> Florian
> >>
> >>
> >> [0] https://bugs.openjdk.java.net/browse/JMC-6544
> >>
> >>
> >>
> >>
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From florian.david at datadoghq.com  Tue Aug  6 09:12:15 2019
From: florian.david at datadoghq.com (Florian David)
Date: Tue, 6 Aug 2019 11:12:15 +0200
Subject: Review request for JM-6544: Add support to parse Java internal
 version of Zulu JVM
In-Reply-To: <CADFkdVQ9qt_m1o1xG2JJO7wpMpc3o+3pQeN2g5R_teKWR3_ZbQ@mail.gmail.com>
References: <CADm1rcYi1FiA6b+GkujhWw8OG+_5gO5fdOoBHiJKRRX2_hb-QQ@mail.gmail.com>
 <CADm1rcaQ_y5GXQypfZXi1dErdkWst7E02tBbuf8fnB=6orRppg@mail.gmail.com>
 <4ff6f1a4-d421-fa67-7607-8a36f3c78792@redhat.com>
 <CADFkdVQ9qt_m1o1xG2JJO7wpMpc3o+3pQeN2g5R_teKWR3_ZbQ@mail.gmail.com>
Message-ID: <CADm1rcbsRhHRkUAeVaPJq+Bt0kxb_T_LDDQDqAK+a4URh=rNmA@mail.gmail.com>

Thanks for your feedback, I understand the pain of having to maintain
different vendors version in the upstream project. As Henrik wrote, having
a long-term solution for this would involve a longer discussion.

Meanwhile, we can still fix this issue with the solution mentioned above
and having a correct error message reported to the user, providing a better
understanding than just a NPE.

Here is the updated patch:
JIRA: https://bugs.openjdk.java.net/browse/JMC-6544
Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6544/webrev.1/

Thanks,
Florian



On Mon, Aug 5, 2019 at 6:44 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:

> Hi all,
>
> I think that this is a more involved discussion that should definitely be
> had. Originally we only built JMC to support known JDKs built by Oracle
> where we could be assumed to know enough details about the features of each
> version to depend on only version numbers to decide whether to check for
> certain behaviours in the rules. This is in e.g. the String Deduplication
> rule and the Code Cache rule, they're already depending on vendor, albeit
> implicitly.
>
> To fix this properly we could perhaps build some support in the core JMC
> APIs for checking Java Vendor and allowing downstream implementations to
> react to different vendors, rather than just to which JDK version is used.
> We would then have to replace all references to RulesToolkit.getJavaVersion
> used for determining runtime features with both checks for vendor and
> version.
>
> Regardless, we should still fix this issue and after looking through usages
> of the JavaVersion methods I've found that most of them check for a
> potential null return value and only two don't (and they both have implicit
> vendor dependencies). So the best fix is probably to add null checks to the
> FlightRecordingSupportRule:113 with a N/A result and the
> CodeCachePageUI:294.
>
>
> Cheers,
> Henrik Dafg?rd
>
>
> On Mon, 5 Aug 2019 at 10:46, Mario Torre <neugens at redhat.com> wrote:
>
> > On 05/08/2019 10:31, Florian David wrote:
> > > I have been told that the patch was removed from the previous mail.
> > > Please find a web review instead:
> > >
> > > JIRA: https://bugs.openjdk.java.net/browse/JMC-6544
> > > Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6544/webrev.0/
> >
> > Hi Florian,
> >
> > To be honest, I already expressed concerns about this
> > FlightRecordingSupportRule, I don't think it's a good idea to make JMC
> > know every single java vendor out there in the world.
> >
> > I would rather prefer such patches are either internal to vendors and
> > not exposed in the upstream project, but more generally we should rework
> > this mechanisms in order to be vendor-agnostic rather than add more
> > special cases.
> >
> > Cheers,
> > Mario
> >
> > > On Sun, Aug 4, 2019 at 6:12 PM Florian David <
> > florian.david at datadoghq.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >>
> > >> Please find attached a patch to solve an error that arise when parsing
> > >> Zulu internal version [0]. I also added a test with a representative
> > set of
> > >> Java internal versions of the Zulu JVM, even if it's far from covering
> > >> every single case.
> > >>
> > >>
> > >> Regards,
> > >>
> > >> Florian
> > >>
> > >>
> > >> [0] https://bugs.openjdk.java.net/browse/JMC-6544
> > >>
> > >>
> > >>
> > >>
> >
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >
>

From florian.david at datadoghq.com  Tue Aug  6 12:40:36 2019
From: florian.david at datadoghq.com (Florian David)
Date: Tue, 6 Aug 2019 14:40:36 +0200
Subject: Review request for JMC-6548: Duplicated Flags rule somewhat naive
Message-ID: <CADm1rcba5KwfScvsbXf6qUiPZCB4i=57cCLrdZd5qPH4ODRYKw@mail.gmail.com>

Hi,

Please find attached a webrev to solve JMC-6548.

I have also corrected a small bug on line 123 (String[] split =
fullArgument.split("[=:]",
2);). In case fullArgument contains more than one ':' (for instance
"-javaagent:C:/mypath"), split[1] does not contain the exact option
argument (in this case only "C"), which could give inconsistent results.

JIRA: https://bugs.openjdk.java.net/browse/JMC-6548
Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6548/webrev.0/

Thanks,
Florian

From kdobson at redhat.com  Tue Aug  6 15:26:36 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Tue, 6 Aug 2019 11:26:36 -0400
Subject: Review Request for JMC-6467
In-Reply-To: <CAOsn=kqfV5fO1feNpxvN1wgoOgYPj2ajAfLZ2cuQFO5H3=3OSA@mail.gmail.com>
References: <CADFkdVRi2AnJeDwQeoBMTBFHNDyKDA6WBc3rYuA5GKPOungL_Q@mail.gmail.com>
 <CAOsn=kpKkBXfYMY5e9mS-Yqe5xoJ147m5_SLk16aeb3=6__MLg@mail.gmail.com>
 <CADFkdVSQ2eg-jk-n79Vg=029ZZYGnKs1_Dk6p9fm7FPu2fJrmw@mail.gmail.com>
 <CAOsn=kqcgJSon16dm-Dw85x8BVWBE9We5+=g4RH7vmiVp_90kQ@mail.gmail.com>
 <CAOsn=kqfV5fO1feNpxvN1wgoOgYPj2ajAfLZ2cuQFO5H3=3OSA@mail.gmail.com>
Message-ID: <CADPaBqkBTerZAppWsO1N_+s2NOUWQeX77UnZ3=fGAxBR9Bkgsg@mail.gmail.com>

Hi Henrik,

I tested it out and the functionality all looks good the only issue I found
was it was missing some of the Shenandoah states which cause some things to
break, I've added them in the webrev below.

I do have a couple comments regarding the UI:

1. It doesn't seem necessary for the legend names to be an editable text
box, I can't foresee any use for this and it's more likely to cause
confusion.
2. The Region Visualizer is unlikely to ever be able to be rendered for
Shenandoah due to the number of regions, I wonder if it might make sense
for the default chart to be more like a stack chart showing the total
distribution (i.e. 20% Empty Uncommitted 40% Regular 40% Trash) or
something of that nature. Any changes to the region visualizer are best for
another patch but it would be worth considering.

Webrev: http://cr.openjdk.java.net/~kdobson/JMC-6467/webrev/

Cheers,

Ken Dobson

On Wed, Jul 31, 2019 at 3:44 PM Alex Macdonald <almacdon at redhat.com> wrote:

> Hi Henrik,
>
> On Tue, Jul 30, 2019 at 11:04 AM Alex Macdonald <almacdon at redhat.com>
> wrote:
>
> > Hi Henrik,
> >
> > On Tue, Jul 30, 2019 at 7:45 AM Henrik Dafg?rd <hdafgard at gmail.com>
> wrote:
> >
> >> Hi Alex,
> >>
> >> Thanks for finding this, the issue seems to be that I mis-typed the type
> >> string for Jdk.ShenandoahRegionStateChange as
> >> Jdk.ShenandoahRegionTypeChange. Fixing that solved the NPEs.
> >>
> >> Updated Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.1/
> >>
> >>
> > Hm, it looks like I'm still encountering the same problem as before. It
> > wasn't that branch of the if-statement in G1Constants which was running
> > into problems (but good a typo was caught), but rather the one above it:
> >
> > [..]
> > } else if
> >
> (type.getIdentifier().equals(JdkTypeIDs.GC_SHENANDOAH_HEAP_REGION_INFORMATION))
> > {
> >   return REGION_STATE.getAccessor(type);
> > }
> > [..]
> >
> > The returned value here is null for me. When I take a look at the passed
> > type object it is correctly a jdk.ShenandoahHeapRegionInformation,
> however
> > the state attribute looks like:
> >
> > type.m_accessors[2] = Attribute(state,
> >
> Linear(number))=org.openjdk.jmc.common.unit.StructContentType$AccessorEntry at 5b32e0b1
> >
> > but the REGION_STATE is looking for PLAIN_TEXT ("text"), which is a
> > mismatch.
> >
> > For reference here's the stack trace that gets displayed in the jfr
> editor
> > page:
> >
> > java.lang.NullPointerException
> >   at
> >
> org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.createRegionList(G1Page.java:443)
> >   at
> >
> org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.setUpHeapDumps(G1Page.java:454)
> >   at
> >
> org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.<init>(G1Page.java:218)
> >   at
> org.openjdk.jmc.flightrecorder.ext.g1.G1Page.display(G1Page.java:586)
> >   at
> >
> org.openjdk.jmc.flightrecorder.ui.JfrEditor.displayPage(JfrEditor.java:232)
> >   at
> >
> org.openjdk.jmc.flightrecorder.ui.JfrEditor.navigateTo(JfrEditor.java:216)
> >   at
> >
> org.openjdk.jmc.flightrecorder.ui.JfrOutlinePage.selectionChanged(JfrOutlinePage.java:449)
> >
>
> My mistake, it looks like the recording I've been using may be irrelevant
> because it was using a work-in-progress implementation of the shenandoah
> events rather than the final ones. Ken has supplied me a newer shenandoah
> recording and the page is visible and working now.
>
> As for some minor nits:
> There are a handful of empty spaces/tabs that can be cleaned up:
> - ColorMap (9)
> - G1Page (4)
> - TypeIDs (2)
>
> Also the page name has been generalized from "G1 Heap Layout", would now
> also be a good time to update the other instances of g1* throughout the
> extension?
>
>
> > Cheers,
> >> Henrik Dafg?rd
> >>
> >>
> >> On Mon, 29 Jul 2019 at 18:03, Alex Macdonald <almacdon at redhat.com>
> wrote:
> >>
> >>> Hi Henrik,
> >>>
> >>> On Thu, Jul 25, 2019 at 1:37 PM Henrik Dafg?rd <hdafgard at gmail.com>
> >>> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Please review this request for generalizing the G1 Heap Layout page.
> The
> >>>> pages.xml file that contains the new default color values could use
> one
> >>>> or
> >>>> two suggestions for Shenandoah events, if anyone has particular
> >>>> suggestions
> >>>> for default color values there.
> >>>>
> >>>
> >>> I've applied the patch and tried to open the Heap Layout page, however
> >>> I'm running into a NPE when G1Page.createRegionList() [0] is adding
> items
> >>> to "allRegions".
> >>>
> >>> For type jdk.ShenandoahHeapRegionInformation, the "typeAccessor"
> >>> variable [1] is coming back null, which ultimately causes an NPE when
> >>> trying to to retrieve a value from it [2]. Taking a bit of a deeper
> look
> >>> there seems to be a mismatch between the structure of REGION_STATE and
> what
> >>> I'm observing in the list of accessors. G1Constants is looking for
> (state,
> >>> Type(text)), however the actual value of the key involving state is
> (state,
> >>> Linear(number)). To quickly test I was able to retrieve a value using
> >>> attr("state", "State", NUMBER), however this doesn't match the return
> type
> >>> of customAccessor().
> >>>
> >>> I only have one shenandoah jfr file that I've been using, if you aren't
> >>> experiencing this exception would you be able to provide a basic jfr
> file
> >>> for verifying the behaviour?
> >>>
> >>> [0]
> >>>
> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l442
> >>> [1]
> >>>
> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l453
> >>> [2]
> >>>
> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l458
> >>>
> >>>
> >>>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6467
> >>>> Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.0/
> >>>>
> >>>>
> >>>> Cheers,
> >>>> Henrik Dafg?rd
> >>>>
> >>>
> >>> Cheers,
> >>>
> >>> Alex
> >>>
> >>
>

From hdafgard at gmail.com  Tue Aug  6 15:52:57 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Tue, 6 Aug 2019 17:52:57 +0200
Subject: Review request for JMC-6548: Duplicated Flags rule somewhat naive
In-Reply-To: <CADm1rcba5KwfScvsbXf6qUiPZCB4i=57cCLrdZd5qPH4ODRYKw@mail.gmail.com>
References: <CADm1rcba5KwfScvsbXf6qUiPZCB4i=57cCLrdZd5qPH4ODRYKw@mail.gmail.com>
Message-ID: <CADFkdVQiNdCd0yAwHX2=f1RbSEQCCgw2ppoNVOayq4p5VngCRQ@mail.gmail.com>

Hi Florian,

The split needs to have that limit there due to the experimental arguments
with options, i.e. -XX:FlightRecorderOptions=stackdepth=128. With this
change we would get inconsistent results there instead as the argument
would be seen as FlightRecorderOptions=stackdepth=128 instead of
FlightRecorderOptions.

Also, if an argument matches one in the VERBATIM array it should only be
compared using the full argument and we won't even run that split on that
argument. If we want to compare multiple -javaagent commands that share
jarpaths but might have different options that could be contradictory I
think we need to have a more detailed solution, i.e. have a check for
"-javaagent" as a prefix instead of adding it to the VERBATIM array and
handling those arguments specially.


Cheers,
Henrik Dafg?rd


On Tue, 6 Aug 2019 at 14:41, Florian David <florian.david at datadoghq.com>
wrote:

> Hi,
>
> Please find attached a webrev to solve JMC-6548.
>
> I have also corrected a small bug on line 123 (String[] split =
> fullArgument.split("[=:]",
> 2);). In case fullArgument contains more than one ':' (for instance
> "-javaagent:C:/mypath"), split[1] does not contain the exact option
> argument (in this case only "C"), which could give inconsistent results.
>
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6548
> Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6548/webrev.0/
>
> Thanks,
> Florian
>

From hdafgard at gmail.com  Tue Aug  6 15:57:10 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Tue, 6 Aug 2019 17:57:10 +0200
Subject: Review Request for JMC-6467
In-Reply-To: <CADPaBqkBTerZAppWsO1N_+s2NOUWQeX77UnZ3=fGAxBR9Bkgsg@mail.gmail.com>
References: <CADFkdVRi2AnJeDwQeoBMTBFHNDyKDA6WBc3rYuA5GKPOungL_Q@mail.gmail.com>
 <CAOsn=kpKkBXfYMY5e9mS-Yqe5xoJ147m5_SLk16aeb3=6__MLg@mail.gmail.com>
 <CADFkdVSQ2eg-jk-n79Vg=029ZZYGnKs1_Dk6p9fm7FPu2fJrmw@mail.gmail.com>
 <CAOsn=kqcgJSon16dm-Dw85x8BVWBE9We5+=g4RH7vmiVp_90kQ@mail.gmail.com>
 <CAOsn=kqfV5fO1feNpxvN1wgoOgYPj2ajAfLZ2cuQFO5H3=3OSA@mail.gmail.com>
 <CADPaBqkBTerZAppWsO1N_+s2NOUWQeX77UnZ3=fGAxBR9Bkgsg@mail.gmail.com>
Message-ID: <CADFkdVQuC_f3PWjFETX2AFqm9cza2oB2i+SSMPDNVHf9Pp-0gw@mail.gmail.com>

Hi Ken,

Great feedback! I actually hadn't noticed the text boxes being editable! So
you're completely right in that that should be fixed.

Regarding the region visualizer I get what you mean, even most production
G1 heaps aren't easily visualized there. It's definitely a possibility to
create a new component that could switch between visualizing the entire
heap over the entire recording (maybe with distribution or some
downsampling) and one that shows individual regions as now. The current
functionality is mostly due to that component already existing and that it
was more performant than my own, earlier, attempt (that also showed region
utilization).


Cheers,
Henrik Dafg?rd


On Tue, 6 Aug 2019 at 17:26, Ken Dobson <kdobson at redhat.com> wrote:

> Hi Henrik,
>
> I tested it out and the functionality all looks good the only issue I
> found was it was missing some of the Shenandoah states which cause some
> things to break, I've added them in the webrev below.
>
> I do have a couple comments regarding the UI:
>
> 1. It doesn't seem necessary for the legend names to be an editable text
> box, I can't foresee any use for this and it's more likely to cause
> confusion.
> 2. The Region Visualizer is unlikely to ever be able to be rendered for
> Shenandoah due to the number of regions, I wonder if it might make sense
> for the default chart to be more like a stack chart showing the total
> distribution (i.e. 20% Empty Uncommitted 40% Regular 40% Trash) or
> something of that nature. Any changes to the region visualizer are best for
> another patch but it would be worth considering.
>
> Webrev: http://cr.openjdk.java.net/~kdobson/JMC-6467/webrev/
>
> Cheers,
>
> Ken Dobson
>
> On Wed, Jul 31, 2019 at 3:44 PM Alex Macdonald <almacdon at redhat.com>
> wrote:
>
>> Hi Henrik,
>>
>> On Tue, Jul 30, 2019 at 11:04 AM Alex Macdonald <almacdon at redhat.com>
>> wrote:
>>
>> > Hi Henrik,
>> >
>> > On Tue, Jul 30, 2019 at 7:45 AM Henrik Dafg?rd <hdafgard at gmail.com>
>> wrote:
>> >
>> >> Hi Alex,
>> >>
>> >> Thanks for finding this, the issue seems to be that I mis-typed the
>> type
>> >> string for Jdk.ShenandoahRegionStateChange as
>> >> Jdk.ShenandoahRegionTypeChange. Fixing that solved the NPEs.
>> >>
>> >> Updated Webrev:
>> http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.1/
>> >>
>> >>
>> > Hm, it looks like I'm still encountering the same problem as before. It
>> > wasn't that branch of the if-statement in G1Constants which was running
>> > into problems (but good a typo was caught), but rather the one above it:
>> >
>> > [..]
>> > } else if
>> >
>> (type.getIdentifier().equals(JdkTypeIDs.GC_SHENANDOAH_HEAP_REGION_INFORMATION))
>> > {
>> >   return REGION_STATE.getAccessor(type);
>> > }
>> > [..]
>> >
>> > The returned value here is null for me. When I take a look at the passed
>> > type object it is correctly a jdk.ShenandoahHeapRegionInformation,
>> however
>> > the state attribute looks like:
>> >
>> > type.m_accessors[2] = Attribute(state,
>> >
>> Linear(number))=org.openjdk.jmc.common.unit.StructContentType$AccessorEntry at 5b32e0b1
>> >
>> > but the REGION_STATE is looking for PLAIN_TEXT ("text"), which is a
>> > mismatch.
>> >
>> > For reference here's the stack trace that gets displayed in the jfr
>> editor
>> > page:
>> >
>> > java.lang.NullPointerException
>> >   at
>> >
>> org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.createRegionList(G1Page.java:443)
>> >   at
>> >
>> org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.setUpHeapDumps(G1Page.java:454)
>> >   at
>> >
>> org.openjdk.jmc.flightrecorder.ext.g1.G1Page$G1PageUI.<init>(G1Page.java:218)
>> >   at
>> org.openjdk.jmc.flightrecorder.ext.g1.G1Page.display(G1Page.java:586)
>> >   at
>> >
>> org.openjdk.jmc.flightrecorder.ui.JfrEditor.displayPage(JfrEditor.java:232)
>> >   at
>> >
>> org.openjdk.jmc.flightrecorder.ui.JfrEditor.navigateTo(JfrEditor.java:216)
>> >   at
>> >
>> org.openjdk.jmc.flightrecorder.ui.JfrOutlinePage.selectionChanged(JfrOutlinePage.java:449)
>> >
>>
>> My mistake, it looks like the recording I've been using may be irrelevant
>> because it was using a work-in-progress implementation of the shenandoah
>> events rather than the final ones. Ken has supplied me a newer shenandoah
>> recording and the page is visible and working now.
>>
>> As for some minor nits:
>> There are a handful of empty spaces/tabs that can be cleaned up:
>> - ColorMap (9)
>> - G1Page (4)
>> - TypeIDs (2)
>>
>> Also the page name has been generalized from "G1 Heap Layout", would now
>> also be a good time to update the other instances of g1* throughout the
>> extension?
>>
>>
>> > Cheers,
>> >> Henrik Dafg?rd
>> >>
>> >>
>> >> On Mon, 29 Jul 2019 at 18:03, Alex Macdonald <almacdon at redhat.com>
>> wrote:
>> >>
>> >>> Hi Henrik,
>> >>>
>> >>> On Thu, Jul 25, 2019 at 1:37 PM Henrik Dafg?rd <hdafgard at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Hi all,
>> >>>>
>> >>>> Please review this request for generalizing the G1 Heap Layout page.
>> The
>> >>>> pages.xml file that contains the new default color values could use
>> one
>> >>>> or
>> >>>> two suggestions for Shenandoah events, if anyone has particular
>> >>>> suggestions
>> >>>> for default color values there.
>> >>>>
>> >>>
>> >>> I've applied the patch and tried to open the Heap Layout page, however
>> >>> I'm running into a NPE when G1Page.createRegionList() [0] is adding
>> items
>> >>> to "allRegions".
>> >>>
>> >>> For type jdk.ShenandoahHeapRegionInformation, the "typeAccessor"
>> >>> variable [1] is coming back null, which ultimately causes an NPE when
>> >>> trying to to retrieve a value from it [2]. Taking a bit of a deeper
>> look
>> >>> there seems to be a mismatch between the structure of REGION_STATE
>> and what
>> >>> I'm observing in the list of accessors. G1Constants is looking for
>> (state,
>> >>> Type(text)), however the actual value of the key involving state is
>> (state,
>> >>> Linear(number)). To quickly test I was able to retrieve a value using
>> >>> attr("state", "State", NUMBER), however this doesn't match the return
>> type
>> >>> of customAccessor().
>> >>>
>> >>> I only have one shenandoah jfr file that I've been using, if you
>> aren't
>> >>> experiencing this exception would you be able to provide a basic jfr
>> file
>> >>> for verifying the behaviour?
>> >>>
>> >>> [0]
>> >>>
>> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l442
>> >>> [1]
>> >>>
>> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l453
>> >>> [2]
>> >>>
>> http://hg.openjdk.java.net/jmc/jmc/file/91a803e741ac/application/org.openjdk.jmc.flightrecorder.ext.g1/src/main/java/org/openjdk/jmc/flightrecorder/ext/g1/G1Page.java#l458
>> >>>
>> >>>
>> >>>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6467
>> >>>> Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6467/webrev.0/
>> >>>>
>> >>>>
>> >>>> Cheers,
>> >>>> Henrik Dafg?rd
>> >>>>
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Alex
>> >>>
>> >>
>>
>

From hdafgard at gmail.com  Tue Aug  6 16:02:46 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Tue, 6 Aug 2019 18:02:46 +0200
Subject: Review request for JM-6544: Add support to parse Java internal
 version of Zulu JVM
In-Reply-To: <CADm1rcbsRhHRkUAeVaPJq+Bt0kxb_T_LDDQDqAK+a4URh=rNmA@mail.gmail.com>
References: <CADm1rcYi1FiA6b+GkujhWw8OG+_5gO5fdOoBHiJKRRX2_hb-QQ@mail.gmail.com>
 <CADm1rcaQ_y5GXQypfZXi1dErdkWst7E02tBbuf8fnB=6orRppg@mail.gmail.com>
 <4ff6f1a4-d421-fa67-7607-8a36f3c78792@redhat.com>
 <CADFkdVQ9qt_m1o1xG2JJO7wpMpc3o+3pQeN2g5R_teKWR3_ZbQ@mail.gmail.com>
 <CADm1rcbsRhHRkUAeVaPJq+Bt0kxb_T_LDDQDqAK+a4URh=rNmA@mail.gmail.com>
Message-ID: <CADFkdVSoFx8qieOZAxmA7E92sh4czBxyBz8sXuJc_x9PFRD9hg@mail.gmail.com>

Hi Florian,

This change looks good to me!


Cheers,
Henrik Dafg?rd


On Tue, 6 Aug 2019 at 11:12, Florian David <florian.david at datadoghq.com>
wrote:

> Thanks for your feedback, I understand the pain of having to maintain
> different vendors version in the upstream project. As Henrik wrote, having
> a long-term solution for this would involve a longer discussion.
>
> Meanwhile, we can still fix this issue with the solution mentioned above
> and having a correct error message reported to the user, providing a better
> understanding than just a NPE.
>
> Here is the updated patch:
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6544
> Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6544/webrev.1/
>
> Thanks,
> Florian
>
>
>
> On Mon, Aug 5, 2019 at 6:44 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>
>> Hi all,
>>
>> I think that this is a more involved discussion that should definitely be
>> had. Originally we only built JMC to support known JDKs built by Oracle
>> where we could be assumed to know enough details about the features of
>> each
>> version to depend on only version numbers to decide whether to check for
>> certain behaviours in the rules. This is in e.g. the String Deduplication
>> rule and the Code Cache rule, they're already depending on vendor, albeit
>> implicitly.
>>
>> To fix this properly we could perhaps build some support in the core JMC
>> APIs for checking Java Vendor and allowing downstream implementations to
>> react to different vendors, rather than just to which JDK version is used.
>> We would then have to replace all references to
>> RulesToolkit.getJavaVersion
>> used for determining runtime features with both checks for vendor and
>> version.
>>
>> Regardless, we should still fix this issue and after looking through
>> usages
>> of the JavaVersion methods I've found that most of them check for a
>> potential null return value and only two don't (and they both have
>> implicit
>> vendor dependencies). So the best fix is probably to add null checks to
>> the
>> FlightRecordingSupportRule:113 with a N/A result and the
>> CodeCachePageUI:294.
>>
>>
>> Cheers,
>> Henrik Dafg?rd
>>
>>
>> On Mon, 5 Aug 2019 at 10:46, Mario Torre <neugens at redhat.com> wrote:
>>
>> > On 05/08/2019 10:31, Florian David wrote:
>> > > I have been told that the patch was removed from the previous mail.
>> > > Please find a web review instead:
>> > >
>> > > JIRA: https://bugs.openjdk.java.net/browse/JMC-6544
>> > > Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6544/webrev.0/
>> >
>> > Hi Florian,
>> >
>> > To be honest, I already expressed concerns about this
>> > FlightRecordingSupportRule, I don't think it's a good idea to make JMC
>> > know every single java vendor out there in the world.
>> >
>> > I would rather prefer such patches are either internal to vendors and
>> > not exposed in the upstream project, but more generally we should rework
>> > this mechanisms in order to be vendor-agnostic rather than add more
>> > special cases.
>> >
>> > Cheers,
>> > Mario
>> >
>> > > On Sun, Aug 4, 2019 at 6:12 PM Florian David <
>> > florian.david at datadoghq.com>
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >>
>> > >> Please find attached a patch to solve an error that arise when
>> parsing
>> > >> Zulu internal version [0]. I also added a test with a representative
>> > set of
>> > >> Java internal versions of the Zulu JVM, even if it's far from
>> covering
>> > >> every single case.
>> > >>
>> > >>
>> > >> Regards,
>> > >>
>> > >> Florian
>> > >>
>> > >>
>> > >> [0] https://bugs.openjdk.java.net/browse/JMC-6544
>> > >>
>> > >>
>> > >>
>> > >>
>> >
>> >
>> > --
>> > Mario Torre
>> > Associate Manager, Software Engineering
>> > Red Hat GmbH <https://www.redhat.com>
>> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>> >
>>
>

From florian.david at datadoghq.com  Tue Aug  6 16:55:08 2019
From: florian.david at datadoghq.com (Florian David)
Date: Tue, 6 Aug 2019 18:55:08 +0200
Subject: Review request for JMC-6548: Duplicated Flags rule somewhat naive
In-Reply-To: <CADFkdVQiNdCd0yAwHX2=f1RbSEQCCgw2ppoNVOayq4p5VngCRQ@mail.gmail.com>
References: <CADm1rcba5KwfScvsbXf6qUiPZCB4i=57cCLrdZd5qPH4ODRYKw@mail.gmail.com>
 <CADFkdVQiNdCd0yAwHX2=f1RbSEQCCgw2ppoNVOayq4p5VngCRQ@mail.gmail.com>
Message-ID: <CADm1rcZm+KgnWcPdAXN1w1oUskNAeE7jB-Cez2qVBi6AWCp=5A@mail.gmail.com>

On Tue, Aug 6, 2019 at 5:53 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:

> Hi Florian,
>
> The split needs to have that limit there due to the experimental arguments
> with options, i.e. -XX:FlightRecorderOptions=stackdepth=128. With this
> change we would get inconsistent results there instead as the argument
> would be seen as FlightRecorderOptions=stackdepth=128 instead of
> FlightRecorderOptions.
>
> Oh right, I did not think about these ones.


> Also, if an argument matches one in the VERBATIM array it should only be
> compared using the full argument and we won't even run that split on that
> argument. If we want to compare multiple -javaagent commands that share
> jarpaths but might have different options that could be contradictory I
> think we need to have a more detailed solution, i.e. have a check for
> "-javaagent" as a prefix instead of adding it to the VERBATIM array and
> handling those arguments specially.
>
>
After an offline discussion with Henrick, we think it's better to display a
message in case there is duplicate agents ("duplicate" here meaning agents
with the same jar) even if given options are different. This is something
the current patch does not catch, I'll update it accordingly.


>
> Cheers,
> Henrik Dafg?rd
>
>
> On Tue, 6 Aug 2019 at 14:41, Florian David <florian.david at datadoghq.com>
> wrote:
>
>> Hi,
>>
>> Please find attached a webrev to solve JMC-6548.
>>
>> I have also corrected a small bug on line 123 (String[] split =
>> fullArgument.split("[=:]",
>> 2);). In case fullArgument contains more than one ':' (for instance
>> "-javaagent:C:/mypath"), split[1] does not contain the exact option
>> argument (in this case only "C"), which could give inconsistent results.
>>
>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6548
>> Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6548/webrev.0/
>>
>> Thanks,
>> Florian
>>
>

From neugens at redhat.com  Wed Aug  7 13:39:05 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 7 Aug 2019 15:39:05 +0200
Subject: JMC-5640: Used Heap After GC Chart
In-Reply-To: <CAEBeOcq-SvmtA+X38D2djH6tdo7zWKHG8JeY63z+XBcgrxXrOw@mail.gmail.com>
References: <CADPaBq=Ds5s55ByF9xcX3Mxyb8_anAXoEOzJkUsOXjQNB+7Xcw@mail.gmail.com>
 <CAEBeOcq-SvmtA+X38D2djH6tdo7zWKHG8JeY63z+XBcgrxXrOw@mail.gmail.com>
Message-ID: <7ae3823a-ff10-600f-21dd-965fa3fc413e@redhat.com>

On 30/07/2019 22:48, Jie Kang wrote:
> On Tue, Jul 23, 2019 at 10:29 AM Ken Dobson <kdobson at redhat.com> wrote:
>>
>> Hi all,
>>
>> Here is a patch that adds a Used Heap Post GC chart to the Garbage
>> Collections page.
>> The implementation is a bit hacky but the only way I could find to add a
>> variation of an attribute already being displayed on a page was to create a
>> duplicate attribute in JdkAttributes.java as well as compare names for
>> uniqueness as identifiers are no longer unique if we intend to look at
>> different subsets of the same attribute.
>>
>> If anyone has any ideas as to how to enact this change in a way that allows
>> us to maintain consistency with the way the other pages operate as well as
>> a way to avoid multiple copies of attributes feel free to share them.
>>
>> Bug Id: https://bugs.openjdk.java.net/browse/JMC-5640
>> Webrev: http://cr.openjdk.java.net/~kdobson/JMC-5640/webrev/
> 
> Hey Ken,
> 
> One minor nit:
> 
> 
> DataPageToolkit.buildLinesRow(Messages.GarbageCollectionsPage_ROW_HEAP,
> 
> Messages.GarbageCollectionsPage_ROW_HEAP_DESC, allItems, false,
> HEAP_SUMMARY,
>  legendFilter,
>                                         UnitLookup.BYTE.quantity(0),
> null).ifPresent(rows::add);
> +                       DataPageToolkit.buildLinesRow("Heap Post GC",
> +                                       "Heap Post GC", allItems,
> false, HEAP_SUMMARY_POST_GC, legendFilter,
> +                                       UnitLookup.BYTE.quantity(0),
> null).ifPresent(rows::add);
> 
> You should add a String for "Heap Post GC" to Messages and reference
> that instead, like how it's done above your addition. The rest looks
> fine to me.

I think the patch is good to go as is too, with this minor fix.

> Regarding the 'hacky' Attributes addition, it's a bit complicated. The
> toolkit code being used doesn't cover the situation where you are
> showing the same attribute filtered two different ways in the same
> chart. Though it can be confusing, the distinction does need to be
> made somewhere along the line. I think this patch is okay but I could
> see an issue made to address this use-case more cleanly. Trying to
> re-work the existing code might take some time.

The approach is a bit "hacky" indeed, I'm not sure what would be the
best approach either short of refactoring this whole code. Perhaps
Marcus has some suggestion?

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From hdafgard at gmail.com  Wed Aug  7 14:13:24 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Wed, 7 Aug 2019 16:13:24 +0200
Subject: JMC-5640: Used Heap After GC Chart
In-Reply-To: <7ae3823a-ff10-600f-21dd-965fa3fc413e@redhat.com>
References: <CADPaBq=Ds5s55ByF9xcX3Mxyb8_anAXoEOzJkUsOXjQNB+7Xcw@mail.gmail.com>
 <CAEBeOcq-SvmtA+X38D2djH6tdo7zWKHG8JeY63z+XBcgrxXrOw@mail.gmail.com>
 <7ae3823a-ff10-600f-21dd-965fa3fc413e@redhat.com>
Message-ID: <CADFkdVR_rd=thqWujz=02cuR3qBkQ9F-W57-J7yySzB0vWo4Dw@mail.gmail.com>

Hi all,

I agree that there should be a better way to do this, but for now this
looks good with the minor change of moving the Attribute and Query to the
GarbageCollectionsPage instead of having them in core. I think it's far too
confusing to have an attribute called HEAP_USED_POST_GC that's a duplicate
of HEAP_USED in the core APIs, this is just going to lead to hard to
identify bugs for downstream applications in the future.


Cheers,
Henrik Dafg?rd


On Wed, 7 Aug 2019 at 15:39, Mario Torre <neugens at redhat.com> wrote:

> On 30/07/2019 22:48, Jie Kang wrote:
> > On Tue, Jul 23, 2019 at 10:29 AM Ken Dobson <kdobson at redhat.com> wrote:
> >>
> >> Hi all,
> >>
> >> Here is a patch that adds a Used Heap Post GC chart to the Garbage
> >> Collections page.
> >> The implementation is a bit hacky but the only way I could find to add a
> >> variation of an attribute already being displayed on a page was to
> create a
> >> duplicate attribute in JdkAttributes.java as well as compare names for
> >> uniqueness as identifiers are no longer unique if we intend to look at
> >> different subsets of the same attribute.
> >>
> >> If anyone has any ideas as to how to enact this change in a way that
> allows
> >> us to maintain consistency with the way the other pages operate as well
> as
> >> a way to avoid multiple copies of attributes feel free to share them.
> >>
> >> Bug Id: https://bugs.openjdk.java.net/browse/JMC-5640
> >> Webrev: http://cr.openjdk.java.net/~kdobson/JMC-5640/webrev/
> >
> > Hey Ken,
> >
> > One minor nit:
> >
> >
> > DataPageToolkit.buildLinesRow(Messages.GarbageCollectionsPage_ROW_HEAP,
> >
> > Messages.GarbageCollectionsPage_ROW_HEAP_DESC, allItems, false,
> > HEAP_SUMMARY,
> >  legendFilter,
> >                                         UnitLookup.BYTE.quantity(0),
> > null).ifPresent(rows::add);
> > +                       DataPageToolkit.buildLinesRow("Heap Post GC",
> > +                                       "Heap Post GC", allItems,
> > false, HEAP_SUMMARY_POST_GC, legendFilter,
> > +                                       UnitLookup.BYTE.quantity(0),
> > null).ifPresent(rows::add);
> >
> > You should add a String for "Heap Post GC" to Messages and reference
> > that instead, like how it's done above your addition. The rest looks
> > fine to me.
>
> I think the patch is good to go as is too, with this minor fix.
>
> > Regarding the 'hacky' Attributes addition, it's a bit complicated. The
> > toolkit code being used doesn't cover the situation where you are
> > showing the same attribute filtered two different ways in the same
> > chart. Though it can be confusing, the distinction does need to be
> > made somewhere along the line. I think this patch is okay but I could
> > see an issue made to address this use-case more cleanly. Trying to
> > re-work the existing code might take some time.
>
> The approach is a bit "hacky" indeed, I'm not sure what would be the
> best approach either short of refactoring this whole code. Perhaps
> Marcus has some suggestion?
>
> Cheers,
> Mario
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From neugens at redhat.com  Wed Aug  7 14:22:27 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 7 Aug 2019 16:22:27 +0200
Subject: JMC-5640: Used Heap After GC Chart
In-Reply-To: <CADFkdVR_rd=thqWujz=02cuR3qBkQ9F-W57-J7yySzB0vWo4Dw@mail.gmail.com>
References: <CADPaBq=Ds5s55ByF9xcX3Mxyb8_anAXoEOzJkUsOXjQNB+7Xcw@mail.gmail.com>
 <CAEBeOcq-SvmtA+X38D2djH6tdo7zWKHG8JeY63z+XBcgrxXrOw@mail.gmail.com>
 <7ae3823a-ff10-600f-21dd-965fa3fc413e@redhat.com>
 <CADFkdVR_rd=thqWujz=02cuR3qBkQ9F-W57-J7yySzB0vWo4Dw@mail.gmail.com>
Message-ID: <CAJwKKmYMG+Jg2+iVHZjGYg8XZxoZxjr08LS3RuTpeGEsaFHNBw@mail.gmail.com>

On Wed, Aug 7, 2019 at 4:13 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>
> Hi all,
>
> I agree that there should be a better way to do this, but for now this looks good with the minor change of moving the Attribute and Query to the GarbageCollectionsPage instead of having them in core. I think it's far too confusing to have an attribute called HEAP_USED_POST_GC that's a duplicate of HEAP_USED in the core APIs, this is just going to lead to hard to identify bugs for downstream applications in the future.
>

Right, this is a good point. It also make it more difficult to
refactor in the future if they are "officially" visible.

Ken, once you fix this, can you please file a new bug report to track
the refactoring?

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From kdobson at redhat.com  Wed Aug  7 15:37:37 2019
From: kdobson at redhat.com (Ken Dobson)
Date: Wed, 7 Aug 2019 11:37:37 -0400
Subject: JMC-5640: Used Heap After GC Chart
In-Reply-To: <CAJwKKmYMG+Jg2+iVHZjGYg8XZxoZxjr08LS3RuTpeGEsaFHNBw@mail.gmail.com>
References: <CADPaBq=Ds5s55ByF9xcX3Mxyb8_anAXoEOzJkUsOXjQNB+7Xcw@mail.gmail.com>
 <CAEBeOcq-SvmtA+X38D2djH6tdo7zWKHG8JeY63z+XBcgrxXrOw@mail.gmail.com>
 <7ae3823a-ff10-600f-21dd-965fa3fc413e@redhat.com>
 <CADFkdVR_rd=thqWujz=02cuR3qBkQ9F-W57-J7yySzB0vWo4Dw@mail.gmail.com>
 <CAJwKKmYMG+Jg2+iVHZjGYg8XZxoZxjr08LS3RuTpeGEsaFHNBw@mail.gmail.com>
Message-ID: <CADPaBqm0QMApJ2ivm3R3j3GAUUoQ5d2jiDe331+0sOqP1saBJQ@mail.gmail.com>

Hi all,

Thanks for the review, I've moved the attribute and query to the Garbage
Collection Page which should certainly be less confusing.

Yes I'll open a bug report for refactoring the attributes.

webrev: http://cr.openjdk.java.net/~kdobson/JMC-5640/webrev.01/

Cheers,

Ken Dobson

On Wed, Aug 7, 2019 at 10:23 AM Mario Torre <neugens at redhat.com> wrote:

> On Wed, Aug 7, 2019 at 4:13 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
> >
> > Hi all,
> >
> > I agree that there should be a better way to do this, but for now this
> looks good with the minor change of moving the Attribute and Query to the
> GarbageCollectionsPage instead of having them in core. I think it's far too
> confusing to have an attribute called HEAP_USED_POST_GC that's a duplicate
> of HEAP_USED in the core APIs, this is just going to lead to hard to
> identify bugs for downstream applications in the future.
> >
>
> Right, this is a good point. It also make it more difficult to
> refactor in the future if they are "officially" visible.
>
> Ken, once you fix this, can you please file a new bug report to track
> the refactoring?
>
> Cheers,
> Mario
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From hdafgard at gmail.com  Wed Aug  7 16:05:33 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Wed, 7 Aug 2019 18:05:33 +0200
Subject: JMC-5640: Used Heap After GC Chart
In-Reply-To: <CADPaBqm0QMApJ2ivm3R3j3GAUUoQ5d2jiDe331+0sOqP1saBJQ@mail.gmail.com>
References: <CADPaBq=Ds5s55ByF9xcX3Mxyb8_anAXoEOzJkUsOXjQNB+7Xcw@mail.gmail.com>
 <CAEBeOcq-SvmtA+X38D2djH6tdo7zWKHG8JeY63z+XBcgrxXrOw@mail.gmail.com>
 <7ae3823a-ff10-600f-21dd-965fa3fc413e@redhat.com>
 <CADFkdVR_rd=thqWujz=02cuR3qBkQ9F-W57-J7yySzB0vWo4Dw@mail.gmail.com>
 <CAJwKKmYMG+Jg2+iVHZjGYg8XZxoZxjr08LS3RuTpeGEsaFHNBw@mail.gmail.com>
 <CADPaBqm0QMApJ2ivm3R3j3GAUUoQ5d2jiDe331+0sOqP1saBJQ@mail.gmail.com>
Message-ID: <CADFkdVSmJhPgME9QLMu3Q1vv4ofoD0yaoujUzQOcwMxpCktYtA@mail.gmail.com>

Hi all,

This looks good to me!


Cheers,
Henrik Dafg?rd


On Wed, 7 Aug 2019 at 17:37, Ken Dobson <kdobson at redhat.com> wrote:

> Hi all,
>
> Thanks for the review, I've moved the attribute and query to the Garbage
> Collection Page which should certainly be less confusing.
>
> Yes I'll open a bug report for refactoring the attributes.
>
> webrev: http://cr.openjdk.java.net/~kdobson/JMC-5640/webrev.01/
>
> Cheers,
>
> Ken Dobson
>
> On Wed, Aug 7, 2019 at 10:23 AM Mario Torre <neugens at redhat.com> wrote:
>
>> On Wed, Aug 7, 2019 at 4:13 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I agree that there should be a better way to do this, but for now this
>> looks good with the minor change of moving the Attribute and Query to the
>> GarbageCollectionsPage instead of having them in core. I think it's far too
>> confusing to have an attribute called HEAP_USED_POST_GC that's a duplicate
>> of HEAP_USED in the core APIs, this is just going to lead to hard to
>> identify bugs for downstream applications in the future.
>> >
>>
>> Right, this is a good point. It also make it more difficult to
>> refactor in the future if they are "officially" visible.
>>
>> Ken, once you fix this, can you please file a new bug report to track
>> the refactoring?
>>
>> Cheers,
>> Mario
>>
>>
>> --
>> Mario Torre
>> Associate Manager, Software Engineering
>> Red Hat GmbH <https://www.redhat.com>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>
>

From jkang at redhat.com  Thu Aug  8 15:07:56 2019
From: jkang at redhat.com (Jie Kang)
Date: Thu, 8 Aug 2019 11:07:56 -0400
Subject: Review Request for JMC-5923: Add allocation pressure column to
 stacktrace view
In-Reply-To: <CAN4WuHa-SY0Bi8Xfkjc8CToDFb-C=gmZVBCwRCBv=y2HFB5EZg@mail.gmail.com>
References: <CAN4WuHYqvhOZcOSu5gL51GOWA4fVuSvPU7K_xT0-ayBEWcForQ@mail.gmail.com>
 <CAN4WuHa-SY0Bi8Xfkjc8CToDFb-C=gmZVBCwRCBv=y2HFB5EZg@mail.gmail.com>
Message-ID: <CAEBeOcoJcXXz7q_NbcmnbE7GoOBDzQwiASEpfEaZ8C4+41HgkA@mail.gmail.com>

On Fri, Jul 26, 2019 at 10:15 AM Salman Siddiqui <sasiddiq at redhat.com> wrote:
>
> Hi all,
>
> Here is a webrev for the patch:
> https://cr.openjdk.java.net/~aptmac/JMC-5923/webrev.00/

Hi Salman,

Some comments below:

+                       IItemCollection itemsCollection =
ItemCollectionToolkit.build(IteratorToolkit.toList(items.iterator(),
items.size()).stream());
+                       IItemCollection allItemsCollection =
ItemCollectionToolkit.build(IteratorToolkit.toList(allItems.iterator(),
items.size()).stream());

Should it be allItems.size() in the second line?

+                       SimpleArray<IItem> items = frame.getItems();
+                       Branch branch = frame.getBranch();
+                       SimpleArray<IItem> allItems = new
SimpleArray<IItem>(branch.getFirstFrame().getItems().elements());
+                       for (StacktraceFrame f: branch.getTailFrames()) {
+                               allItems.addAll(f.getItems().elements());
+                       }

As with Joshua's comments, tests would be neat. Does the ratio of the
frame's items against the frame's, branch's first frame's items plus
the items of all the branch's tail frames match the "ratio of the size
of the allocations of a particular class to the size of total
allocations from that stacktrace frame." ? I'll try to read more into
the underlying classes it but if someone with more experience with the
Stacktrace classes could take a look at this I'd appreciate it as
well.

+                               Double itemsAlloc =
itemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue();
+                               Double allItemsAlloc =
allItemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue();
+                               return String.format("%.1f %%",
(itemsAlloc / allItemsAlloc ) * 100);
+                       } catch (NullPointerException e) { //
ALLOCATION_TOTAL is only available in Memory page
+                               return "";

This comment seems strange to me. When I have a selection through the
Memory page, there are still elements in the stack trace view that
have "" for their allocation pressure column. That makes sense but
doesn't really match the comment here. Maybe the comment can be
rephrased?


Regards,


>
> Thanks,
> Salman
>
> On Thu, Jul 25, 2019 at 9:42 PM Salman Siddiqui <sasiddiq at redhat.com> wrote:
>
> > Hi all,
> >
> > Here is patch that adds a column to the stacktrace view to display
> > normalized allocation pressure. The allocation pressure is a ratio of the
> > size of the allocations of a particular class to the size of total
> > allocations from that stacktrace frame.
> >
> > Also, as per suggestion from Marcus, I have normalized the count that is
> > displayed in the stacktrace view (this is similar to what is already being
> > displayed in the tool tip for the count).
> >
> > JIRA issue: https://bugs.openjdk.java.net/browse/JMC-5923
> > Related GitHub issue: https://github.com/JDKMissionControl/jmc/issues/6
> >
> > Patch is below.
> >
> > Thanks,
> > Salman
> >
> >
> > diff --git
> > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> > index 7b576f3..cd8234a 100644
> > ---
> > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> > +++
> > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
> > @@ -435,6 +435,7 @@ public class Messages extends NLS {
> >   public static String SELECT_RANGE_WIZARD_TEXT;
> >   public static String SELECT_RANGE_WIZARD_TITLE;
> >   public static String SELECT_RANGE_WIZARD_TO_MUCH_SELECTED_WARNING;
> > + public static String STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME;
> >   public static String STACKTRACE_VIEW_COUNT_COLUMN_NAME;
> >   public static String STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY;
> >   public static String STACKTRACE_VIEW_FRAME_GROUP_CHOOSE;
> > diff --git
> > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> > index 2b51e80..9d96016 100644
> > ---
> > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> > +++
> > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/views/stacktrace/StacktraceView.java
> > @@ -92,10 +92,16 @@ import org.eclipse.ui.part.ViewPart;
> >  import org.openjdk.jmc.common.IDisplayable;
> >  import org.openjdk.jmc.common.IMCFrame;
> >  import org.openjdk.jmc.common.IState;
> > +import org.openjdk.jmc.common.collection.IteratorToolkit;
> >  import org.openjdk.jmc.common.collection.SimpleArray;
> > +import org.openjdk.jmc.common.item.IItem;
> >  import org.openjdk.jmc.common.item.IItemCollection;
> > +import org.openjdk.jmc.common.item.IItemFilter;
> > +import org.openjdk.jmc.common.item.ItemFilters;
> >  import org.openjdk.jmc.common.unit.UnitLookup;
> >  import org.openjdk.jmc.common.util.StateToolkit;
> > +import org.openjdk.jmc.flightrecorder.jdk.JdkAggregators;
> > +import org.openjdk.jmc.flightrecorder.jdk.JdkFilters;
> >  import org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator;
> >  import
> > org.openjdk.jmc.flightrecorder.stacktrace.FrameSeparator.FrameCategorization;
> >  import org.openjdk.jmc.flightrecorder.stacktrace.StacktraceFormatToolkit;
> > @@ -181,7 +187,7 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   private static final Color COUNT_COLOR = SWTColorToolkit.getColor(new
> > RGB(100, 200, 100));
> >   private static final String SIBLINGS_IMG_KEY = "siblingsColor";
> > //$NON-NLS-1$
> >   private static final Color SIBLINGS_COUNT_COLOR =
> > SWTColorToolkit.getColor(new RGB(170, 250, 170));
> > - private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150};
> > + private static final int[] DEFAULT_COLUMN_WIDTHS = {700, 150, 150};
> >   private static final String THREAD_ROOT_KEY = "threadRootAtTop";
> > //$NON-NLS-1$
> >   private static final String FRAME_OPTIMIZATION_KEY =
> > "distinguishFramesByOptimization"; //$NON-NLS-1$
> >   private static final String FRAME_CATEGORIZATION_KEY =
> > "distinguishFramesCategorization"; //$NON-NLS-1$
> > @@ -491,7 +497,7 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   new StacktraceViewToolTipSupport(viewer);
> >   MCContextMenuManager mm =
> > MCContextMenuManager.create(viewer.getControl());
> >   CopySelectionAction copyAction = new CopySelectionAction(viewer,
> > - FormatToolkit.selectionFormatter(stackTraceLabelProvider,
> > countLabelProvider));
> > + FormatToolkit.selectionFormatter(stackTraceLabelProvider,
> > countLabelProvider, allocPressureLabelProvider));
> >   InFocusHandlerActivator.install(viewer.getControl(), copyAction);
> >   mm.appendToGroup(MCContextMenuManager.GROUP_EDIT, copyAction);
> >   mm.appendToGroup(MCContextMenuManager.GROUP_EDIT,
> > CopySettings.getInstance().createContributionItem());
> > @@ -515,6 +521,8 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   .setLabelProvider(stackTraceLabelProvider);
> >   buildColumn(viewer, Messages.STACKTRACE_VIEW_COUNT_COLUMN_NAME,
> > SWT.RIGHT, columnWidths[1])
> >   .setLabelProvider(countLabelProvider);
> > + buildColumn(viewer, Messages.STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME,
> > SWT.RIGHT, columnWidths[2])
> > + .setLabelProvider(allocPressureLabelProvider);
> >
> >   PlatformUI.getWorkbench().getHelpSystem().setHelp(viewer.getControl(),
> > HELP_CONTEXT_ID);
> >
> > @@ -731,7 +739,13 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   private final ColumnLabelProvider countLabelProvider = new
> > ColumnLabelProvider() {
> >   @Override
> >   public String getText(Object element) {
> > - return Integer.toString(((StacktraceFrame) element).getItemCount());
> > + // display normalized count (percentage of total count)
> > + StacktraceFrame frame = (StacktraceFrame) element;
> > + Fork rootFork = getRootFork(frame.getBranch().getParentFork());
> > + int itemCount = frame.getItemCount();
> > + int totalCount = rootFork.getItemsInFork();
> > + return UnitLookup.PERCENT_UNITY.quantity(itemCount / (double) totalCount)
> > + .displayUsing(IDisplayable.AUTO);
> >   }
> >
> >   @Override
> > @@ -756,6 +770,31 @@ public class StacktraceView extends ViewPart
> > implements ISelectionListener {
> >   }
> >   };
> >
> > + private final ColumnLabelProvider allocPressureLabelProvider = new
> > ColumnLabelProvider() {
> > + @Override
> > + public String getText(Object element) {
> > + StacktraceFrame frame = (StacktraceFrame) element;
> > +
> > + SimpleArray<IItem> items = frame.getItems();
> > + Branch branch = frame.getBranch();
> > + SimpleArray<IItem> allItems = new
> > SimpleArray<IItem>(branch.getFirstFrame().getItems().elements());
> > + for (StacktraceFrame f: branch.getTailFrames()) {
> > + allItems.addAll(f.getItems().elements());
> > + }
> > +
> > + IItemCollection itemsCollection =
> > ItemCollectionToolkit.build(IteratorToolkit.toList(items.iterator(),
> > items.size()).stream());
> > + IItemCollection allItemsCollection =
> > ItemCollectionToolkit.build(IteratorToolkit.toList(allItems.iterator(),
> > items.size()).stream());
> > +
> > + try {
> > + Double itemsAlloc =
> > itemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue();
> > + Double allItemsAlloc =
> > allItemsCollection.getAggregate(JdkAggregators.ALLOCATION_TOTAL).numberValue().doubleValue();
> > + return String.format("%.1f %%", (itemsAlloc / allItemsAlloc ) * 100);
> > + } catch (NullPointerException e) { // ALLOCATION_TOTAL is only available
> > in Memory page
> > + return "";
> > + }
> > + }
> > + };
> > +
> >   private final ColumnLabelProvider stackTraceLabelProvider = new
> > ColumnLabelProvider() {
> >
> >   @Override
> > diff --git
> > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> > index cd954bd..96ce600 100644
> > ---
> > a/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> > +++
> > b/application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties
> > @@ -418,6 +418,7 @@ STORED_SELECTIONS_SIZE_UNPARSABLE=Number of stored
> > selections to keep: {0}
> >  STORE_SELECTION_ACTION=Store Selection
> >  STORE_AND_ACTIVATE_SELECTION_ACTION=Store and Set As Focused Selection
> >
> > +STACKTRACE_VIEW_ALLOC_PRESSURE_COLUMN_NAME=Allocation Pressure
> >  STACKTRACE_VIEW_COUNT_COLUMN_NAME=Count
> >  STACKTRACE_VIEW_DISTINGUISH_FRAMES_BY=Distinguish Frames By
> >  STACKTRACE_VIEW_FRAME_GROUP_CHOOSE=Choose Frame Group
> >
> >
> >

From florian.david at datadoghq.com  Thu Aug  8 15:13:15 2019
From: florian.david at datadoghq.com (Florian David)
Date: Thu, 8 Aug 2019 17:13:15 +0200
Subject: Review request for JMC-6548: Duplicated Flags rule somewhat naive
In-Reply-To: <CADm1rcZm+KgnWcPdAXN1w1oUskNAeE7jB-Cez2qVBi6AWCp=5A@mail.gmail.com>
References: <CADm1rcba5KwfScvsbXf6qUiPZCB4i=57cCLrdZd5qPH4ODRYKw@mail.gmail.com>
 <CADFkdVQiNdCd0yAwHX2=f1RbSEQCCgw2ppoNVOayq4p5VngCRQ@mail.gmail.com>
 <CADm1rcZm+KgnWcPdAXN1w1oUskNAeE7jB-Cez2qVBi6AWCp=5A@mail.gmail.com>
Message-ID: <CADm1rcbbBv_2DpNEyxdYGuSgwFKNaLeTOujj8nUkpmio7U+Y5Q@mail.gmail.com>

Here is the new version of the patch.

JIRA: https://bugs.openjdk.java.net/browse/JMC-6548
Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6548/webrev.1/

Cheers,
Florian


On Tue, Aug 6, 2019 at 6:55 PM Florian David <florian.david at datadoghq.com>
wrote:

>
>
> On Tue, Aug 6, 2019 at 5:53 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>
>> Hi Florian,
>>
>> The split needs to have that limit there due to the experimental
>> arguments with options, i.e. -XX:FlightRecorderOptions=stackdepth=128. With
>> this change we would get inconsistent results there instead as the argument
>> would be seen as FlightRecorderOptions=stackdepth=128 instead of
>> FlightRecorderOptions.
>>
>> Oh right, I did not think about these ones.
>
>
>> Also, if an argument matches one in the VERBATIM array it should only be
>> compared using the full argument and we won't even run that split on that
>> argument. If we want to compare multiple -javaagent commands that share
>> jarpaths but might have different options that could be contradictory I
>> think we need to have a more detailed solution, i.e. have a check for
>> "-javaagent" as a prefix instead of adding it to the VERBATIM array and
>> handling those arguments specially.
>>
>>
> After an offline discussion with Henrick, we think it's better to display
> a message in case there is duplicate agents ("duplicate" here meaning
> agents with the same jar) even if given options are different. This is
> something the current patch does not catch, I'll update it accordingly.
>
>
>>
>> Cheers,
>> Henrik Dafg?rd
>>
>>
>> On Tue, 6 Aug 2019 at 14:41, Florian David <florian.david at datadoghq.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Please find attached a webrev to solve JMC-6548.
>>>
>>> I have also corrected a small bug on line 123 (String[] split =
>>> fullArgument.split("[=:]",
>>> 2);). In case fullArgument contains more than one ':' (for instance
>>> "-javaagent:C:/mypath"), split[1] does not contain the exact option
>>> argument (in this case only "C"), which could give inconsistent results.
>>>
>>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6548
>>> Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6548/webrev.0/
>>>
>>> Thanks,
>>> Florian
>>>
>>

From hdafgard at gmail.com  Thu Aug  8 17:07:47 2019
From: hdafgard at gmail.com (hdafgard at gmail.com)
Date: Thu, 08 Aug 2019 17:07:47 +0000
Subject: hg: jmc/jmc: JMC-6544: Allow FlightRecordingSupportRule to run even
 with an unknown Java version
Message-ID: <201908081707.x78H7l8Y010541@aojmv0008.oracle.com>

Changeset: bc0ae8ff490d
Author:    hdafgard <hdafgard at gmail.com>
Date:      2019-08-08 19:01 +0200
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/bc0ae8ff490d

JMC-6544: Allow FlightRecordingSupportRule to run even with an unknown Java version
Summary: Fix bugs where FlightRecordingSupportRule and CodeCachePage cause NPEs when run on recordings made with certain unknown JVMs
Reviewed-by: hdafgard
Contributed-by: Florian David <florian.david at datadoghq.com>

! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/CodeCachePage.java
! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/FlightRecordingSupportRule.java


From kenni.dobson at gmail.com  Thu Aug  8 21:01:24 2019
From: kenni.dobson at gmail.com (kenni.dobson at gmail.com)
Date: Thu, 08 Aug 2019 21:01:24 +0000
Subject: hg: jmc/jmc: JMC-5640: Heap Usage after GC Chart
Message-ID: <201908082101.x78L1O2P003097@aojmv0008.oracle.com>

Changeset: b055b282a5e1
Author:    kdobson
Date:      2019-08-08 16:47 -0400
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/b055b282a5e1

JMC-5640: Heap Usage after GC Chart
Summary: Adds a chart to the Garbage Collections Page displaying Heap Usage Post GC
Reviewed By: hdafgard, neugens

! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/messages/internal/Messages.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/pages/GarbageCollectionsPage.java
! application/org.openjdk.jmc.flightrecorder.ui/src/main/resources/org/openjdk/jmc/flightrecorder/ui/messages/internal/messages.properties


From hdafgard at gmail.com  Mon Aug 12 14:42:44 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Mon, 12 Aug 2019 16:42:44 +0200
Subject: Review request for JMC-6548: Duplicated Flags rule somewhat naive
In-Reply-To: <CADm1rcbbBv_2DpNEyxdYGuSgwFKNaLeTOujj8nUkpmio7U+Y5Q@mail.gmail.com>
References: <CADm1rcba5KwfScvsbXf6qUiPZCB4i=57cCLrdZd5qPH4ODRYKw@mail.gmail.com>
 <CADFkdVQiNdCd0yAwHX2=f1RbSEQCCgw2ppoNVOayq4p5VngCRQ@mail.gmail.com>
 <CADm1rcZm+KgnWcPdAXN1w1oUskNAeE7jB-Cez2qVBi6AWCp=5A@mail.gmail.com>
 <CADm1rcbbBv_2DpNEyxdYGuSgwFKNaLeTOujj8nUkpmio7U+Y5Q@mail.gmail.com>
Message-ID: <CADFkdVTiV75CY=o7L6ZDyUuzD2PPDCV0XFGZH6ZTLBOg9ssJPg@mail.gmail.com>

LGTM!


Cheers,
Henrik Dafg?rd


On Thu, 8 Aug 2019 at 17:13, Florian David <florian.david at datadoghq.com>
wrote:

> Here is the new version of the patch.
>
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6548
> Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6548/webrev.1/
>
> Cheers,
> Florian
>
>
> On Tue, Aug 6, 2019 at 6:55 PM Florian David <florian.david at datadoghq.com>
> wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 5:53 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>>
>>> Hi Florian,
>>>
>>> The split needs to have that limit there due to the experimental
>>> arguments with options, i.e. -XX:FlightRecorderOptions=stackdepth=128. With
>>> this change we would get inconsistent results there instead as the argument
>>> would be seen as FlightRecorderOptions=stackdepth=128 instead of
>>> FlightRecorderOptions.
>>>
>>> Oh right, I did not think about these ones.
>>
>>
>>> Also, if an argument matches one in the VERBATIM array it should only be
>>> compared using the full argument and we won't even run that split on that
>>> argument. If we want to compare multiple -javaagent commands that share
>>> jarpaths but might have different options that could be contradictory I
>>> think we need to have a more detailed solution, i.e. have a check for
>>> "-javaagent" as a prefix instead of adding it to the VERBATIM array and
>>> handling those arguments specially.
>>>
>>>
>> After an offline discussion with Henrick, we think it's better to display
>> a message in case there is duplicate agents ("duplicate" here meaning
>> agents with the same jar) even if given options are different. This is
>> something the current patch does not catch, I'll update it accordingly.
>>
>>
>>>
>>> Cheers,
>>> Henrik Dafg?rd
>>>
>>>
>>> On Tue, 6 Aug 2019 at 14:41, Florian David <florian.david at datadoghq.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find attached a webrev to solve JMC-6548.
>>>>
>>>> I have also corrected a small bug on line 123 (String[] split =
>>>> fullArgument.split("[=:]",
>>>> 2);). In case fullArgument contains more than one ':' (for instance
>>>> "-javaagent:C:/mypath"), split[1] does not contain the exact option
>>>> argument (in this case only "C"), which could give inconsistent results.
>>>>
>>>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6548
>>>> Webrev: http://cr.openjdk.java.net/~fdavid/JMC-6548/webrev.0/
>>>>
>>>> Thanks,
>>>> Florian
>>>>
>>>

From hdafgard at gmail.com  Mon Aug 12 15:08:03 2019
From: hdafgard at gmail.com (hdafgard at gmail.com)
Date: Mon, 12 Aug 2019 15:08:03 +0000
Subject: hg: jmc/jmc: JMC-6548: Allow multiple java agents in jvm argument
 rule check
Message-ID: <201908121508.x7CF83DD024012@aojmv0008.oracle.com>

Changeset: c56816b25c99
Author:    hdafgard <hdafgard at gmail.com>
Date:      2019-08-12 16:29 +0200
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/c56816b25c99

JMC-6548: Allow multiple java agents in jvm argument rule check
Summary: Duplicate flags rule now checks for duplicated java agents properly so multiple agents will not trigger a warning result
Reviewed-by: hdafgard
Contributed-by: Florian David <florian.david at datadoghq.com>

! core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/dataproviders/JvmInternalsDataProvider.java
+ core/tests/org.openjdk.jmc.flightrecorder.rules.jdk.test/src/test/java/org/openjdk/jmc/flightrecorder/test/rules/dataproviders/TestJvmInternalsDataProvider.java


From am at topazdevelopment.com  Wed Aug 14 02:47:43 2019
From: am at topazdevelopment.com (am at topazdevelopment.com)
Date: Tue, 13 Aug 2019 22:47:43 -0400
Subject: Errors building jmc 7.1.0-SNAPSHOT
Message-ID: <0af39e43-eefa-baa1-afbd-1e3a566d3d71@topazdevelopment.com>

I was able to build JMC from source in the past.? Now doing this:

$:/jmc-c56816b25c99/releng/third-party$ mvn -v
Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 1.8.0_222, vendor: Amazon.com Inc., runtime: /opt/jdk-8/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-54-generic", arch: "amd64", family: 
"unix"

/jmc-c56816b25c99/releng/third-party$ mvn p2:site

...generates many errors like

[info] Executing Bundler:
[info]?? [EXEC] javafx-media-11.0.1-mac.jar
[warn]? : Imports that lack version ranges: [com.sun.glass.ui, 
com.sun.glass.utils, com.sun.javafx.collections, com.sun.javafx.geom, 
com.sun.javafx
.geom.transform, com.sun.javafx.media, com.sun.javafx.scene, 
com.sun.javafx.scene.media, com.sun.javafx.sg.prism, com.sun.javafx.tk, 
com.sun.javafx
.util, com.sun.media.jfxmedia, com.sun.media.jfxmedia.control, 
com.sun.media.jfxmedia.effects, com.sun.media.jfxmedia.events, 
com.sun.media.jfxmedi
a.locator, com.sun.media.jfxmedia.logging, com.sun.media.jfxmedia.track, 
com.sun.media.jfxmediaimpl, com.sun.media.jfxmediaimpl.platform, com.sun.m
edia.jfxmediaimpl.platform.gstreamer, 
com.sun.media.jfxmediaimpl.platform.ios, 
com.sun.media.jfxmediaimpl.platform.java, com.sun.media.jfxmediaimpl
.platform.osx, com.sun.prism, javafx.application, javafx.beans, 
javafx.beans.binding, javafx.beans.property, javafx.beans.value, 
javafx.collections
, javafx.event, javafx.geometry, javafx.scene, javafx.scene.image, 
javafx.scene.media, javafx.util]
[error]? : Exception: java.lang.ArrayIndexOutOfBoundsException
[error]? : Invalid class file module-info.class 
(java.lang.ArrayIndexOutOfBoundsException)
[info] Bundling Artifact org.openjfx:javafx-media:jar:win:11.0.1
[warn] BND instructions are NOT applied to the transitive dependencies 
of? org.openjfx:javafx-media:jar:win:11.0.1

Followed by thread dumps.? However mvn still reports BUILD SUCCESS

Looks like I get the same result even when
- using an older version of maven
- building jmc-c56816b25c99 or jmc-5e0a199762b6 from a few months ago 
(used to work)
- deleting maven's .m2 cache
- using Windows or Linux
- using different JDK versions

I assume maven must be pulling down something newer than it was a couple 
months ago.
It sounds related to this
https://stackoverflow.com/questions/50530927/maven-bundle-plugin-fails-with-invalid-class-file-module-info-class 


What's the trick here?? Thanks! -Andrew

From jkang at redhat.com  Wed Aug 14 14:21:28 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 14 Aug 2019 10:21:28 -0400
Subject: Errors building jmc 7.1.0-SNAPSHOT
In-Reply-To: <0af39e43-eefa-baa1-afbd-1e3a566d3d71@topazdevelopment.com>
References: <0af39e43-eefa-baa1-afbd-1e3a566d3d71@topazdevelopment.com>
Message-ID: <CAEBeOcrhwCQskyRsgSwXK0aG_OmcK4wPZUQuRbxuotafKw9VVg@mail.gmail.com>

On Tue, Aug 13, 2019 at 10:48 PM <am at topazdevelopment.com> wrote:
>
> I was able to build JMC from source in the past.  Now doing this:
>
> $:/jmc-c56816b25c99/releng/third-party$ mvn -v
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 1.8.0_222, vendor: Amazon.com Inc., runtime: /opt/jdk-8/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-54-generic", arch: "amd64", family:
> "unix"
>
> /jmc-c56816b25c99/releng/third-party$ mvn p2:site
>
> ...generates many errors like
>
> [info] Executing Bundler:
> [info]   [EXEC] javafx-media-11.0.1-mac.jar
> [warn]  : Imports that lack version ranges: [com.sun.glass.ui,
> com.sun.glass.utils, com.sun.javafx.collections, com.sun.javafx.geom,
> com.sun.javafx
> .geom.transform, com.sun.javafx.media, com.sun.javafx.scene,
> com.sun.javafx.scene.media, com.sun.javafx.sg.prism, com.sun.javafx.tk,
> com.sun.javafx
> .util, com.sun.media.jfxmedia, com.sun.media.jfxmedia.control,
> com.sun.media.jfxmedia.effects, com.sun.media.jfxmedia.events,
> com.sun.media.jfxmedi
> a.locator, com.sun.media.jfxmedia.logging, com.sun.media.jfxmedia.track,
> com.sun.media.jfxmediaimpl, com.sun.media.jfxmediaimpl.platform, com.sun.m
> edia.jfxmediaimpl.platform.gstreamer,
> com.sun.media.jfxmediaimpl.platform.ios,
> com.sun.media.jfxmediaimpl.platform.java, com.sun.media.jfxmediaimpl
> .platform.osx, com.sun.prism, javafx.application, javafx.beans,
> javafx.beans.binding, javafx.beans.property, javafx.beans.value,
> javafx.collections
> , javafx.event, javafx.geometry, javafx.scene, javafx.scene.image,
> javafx.scene.media, javafx.util]
> [error]  : Exception: java.lang.ArrayIndexOutOfBoundsException
> [error]  : Invalid class file module-info.class
> (java.lang.ArrayIndexOutOfBoundsException)
> [info] Bundling Artifact org.openjfx:javafx-media:jar:win:11.0.1
> [warn] BND instructions are NOT applied to the transitive dependencies
> of  org.openjfx:javafx-media:jar:win:11.0.1
>
> Followed by thread dumps.  However mvn still reports BUILD SUCCESS
>
> Looks like I get the same result even when
> - using an older version of maven
> - building jmc-c56816b25c99 or jmc-5e0a199762b6 from a few months ago
> (used to work)
> - deleting maven's .m2 cache
> - using Windows or Linux
> - using different JDK versions
>
> I assume maven must be pulling down something newer than it was a couple
> months ago.
> It sounds related to this
> https://stackoverflow.com/questions/50530927/maven-bundle-plugin-fails-with-invalid-class-file-module-info-class
>
>
> What's the trick here?  Thanks! -Andrew

Hey Andrew,

I tried running it this morning and when I examined the results of
p2:site against my pre-existing jars, they weren't different. When I
continued the build process, building core, starting the Jetty and
then building the root, I did not run into any issues. Does continuing
the build process work for you as well? For what it's worth, I was on
revision 527d408d2a4e


Regards,

From marcus.hirt at datadoghq.com  Wed Aug 14 15:40:12 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Wed, 14 Aug 2019 17:40:12 +0200
Subject: Errors building jmc 7.1.0-SNAPSHOT
In-Reply-To: <0af39e43-eefa-baa1-afbd-1e3a566d3d71@topazdevelopment.com>
References: <0af39e43-eefa-baa1-afbd-1e3a566d3d71@topazdevelopment.com>
Message-ID: <CAOpWGx3VV32UqAth4x1mhWO4cs91Q52DERZ9sdLXQC86EPMkSg@mail.gmail.com>

Hi there,

There is no trick - these build errors and warnings for the p2 repo are
known and an effect of build changes related to pulling Java FX as a
third-party dependency (not expecting Java FX to be part of the JDK, like
it used to be in Oracle JDK 8). We haven't looked into if they can be
solved in a good way (Guru Hb would be the guy to talk to), but they do not
affect the build.

Kind regards,
Marcus

On Wed, Aug 14, 2019 at 4:48 AM <am at topazdevelopment.com> wrote:

> I was able to build JMC from source in the past.  Now doing this:
>
> $:/jmc-c56816b25c99/releng/third-party$ mvn -v
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 1.8.0_222, vendor: Amazon.com Inc., runtime: /opt/jdk-8/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-54-generic", arch: "amd64", family:
> "unix"
>
> /jmc-c56816b25c99/releng/third-party$ mvn p2:site
>
> ...generates many errors like
>
> [info] Executing Bundler:
> [info]   [EXEC] javafx-media-11.0.1-mac.jar
> [warn]  : Imports that lack version ranges: [com.sun.glass.ui,
> com.sun.glass.utils, com.sun.javafx.collections, com.sun.javafx.geom,
> com.sun.javafx
> .geom.transform, com.sun.javafx.media, com.sun.javafx.scene,
> com.sun.javafx.scene.media, com.sun.javafx.sg.prism, com.sun.javafx.tk,
> com.sun.javafx
> .util, com.sun.media.jfxmedia, com.sun.media.jfxmedia.control,
> com.sun.media.jfxmedia.effects, com.sun.media.jfxmedia.events,
> com.sun.media.jfxmedi
> a.locator, com.sun.media.jfxmedia.logging, com.sun.media.jfxmedia.track,
> com.sun.media.jfxmediaimpl, com.sun.media.jfxmediaimpl.platform, com.sun.m
> edia.jfxmediaimpl.platform.gstreamer,
> com.sun.media.jfxmediaimpl.platform.ios,
> com.sun.media.jfxmediaimpl.platform.java, com.sun.media.jfxmediaimpl
> .platform.osx, com.sun.prism, javafx.application, javafx.beans,
> javafx.beans.binding, javafx.beans.property, javafx.beans.value,
> javafx.collections
> , javafx.event, javafx.geometry, javafx.scene, javafx.scene.image,
> javafx.scene.media, javafx.util]
> [error]  : Exception: java.lang.ArrayIndexOutOfBoundsException
> [error]  : Invalid class file module-info.class
> (java.lang.ArrayIndexOutOfBoundsException)
> [info] Bundling Artifact org.openjfx:javafx-media:jar:win:11.0.1
> [warn] BND instructions are NOT applied to the transitive dependencies
> of  org.openjfx:javafx-media:jar:win:11.0.1
>
> Followed by thread dumps.  However mvn still reports BUILD SUCCESS
>
> Looks like I get the same result even when
> - using an older version of maven
> - building jmc-c56816b25c99 or jmc-5e0a199762b6 from a few months ago
> (used to work)
> - deleting maven's .m2 cache
> - using Windows or Linux
> - using different JDK versions
>
> I assume maven must be pulling down something newer than it was a couple
> months ago.
> It sounds related to this
>
> https://stackoverflow.com/questions/50530927/maven-bundle-plugin-fails-with-invalid-class-file-module-info-class
>
>
> What's the trick here?  Thanks! -Andrew
>

From am at topazdevelopment.com  Wed Aug 14 20:05:38 2019
From: am at topazdevelopment.com (am at topazdevelopment.com)
Date: Wed, 14 Aug 2019 16:05:38 -0400
Subject: Errors building jmc 7.1.0-SNAPSHOT
In-Reply-To: <CAEBeOcrhwCQskyRsgSwXK0aG_OmcK4wPZUQuRbxuotafKw9VVg@mail.gmail.com>
References: <0af39e43-eefa-baa1-afbd-1e3a566d3d71@topazdevelopment.com>
 <CAEBeOcrhwCQskyRsgSwXK0aG_OmcK4wPZUQuRbxuotafKw9VVg@mail.gmail.com>
Message-ID: <bb91a30e-0146-08b1-416b-8104367e0fe1@topazdevelopment.com>

Yes it's building now.? Thanks.? It wasn't building before so I'm 
assuming clearing the .m2 cache fixed something or other.

On 8/14/2019 10:21 AM, Jie Kang wrote:
> On Tue, Aug 13, 2019 at 10:48 PM <am at topazdevelopment.com> wrote:
>> I was able to build JMC from source in the past.  Now doing this:
>>
>> $:/jmc-c56816b25c99/releng/third-party$ mvn -v
>> Apache Maven 3.6.0
>> Maven home: /usr/share/maven
>> Java version: 1.8.0_222, vendor: Amazon.com Inc., runtime: /opt/jdk-8/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "linux", version: "4.15.0-54-generic", arch: "amd64", family:
>> "unix"
>>
>> /jmc-c56816b25c99/releng/third-party$ mvn p2:site
>>
>> ...generates many errors like
>>
>> [info] Executing Bundler:
>> [info]   [EXEC] javafx-media-11.0.1-mac.jar
>> [warn]  : Imports that lack version ranges: [com.sun.glass.ui,
>> com.sun.glass.utils, com.sun.javafx.collections, com.sun.javafx.geom,
>> com.sun.javafx
>> .geom.transform, com.sun.javafx.media, com.sun.javafx.scene,
>> com.sun.javafx.scene.media, com.sun.javafx.sg.prism, com.sun.javafx.tk,
>> com.sun.javafx
>> .util, com.sun.media.jfxmedia, com.sun.media.jfxmedia.control,
>> com.sun.media.jfxmedia.effects, com.sun.media.jfxmedia.events,
>> com.sun.media.jfxmedi
>> a.locator, com.sun.media.jfxmedia.logging, com.sun.media.jfxmedia.track,
>> com.sun.media.jfxmediaimpl, com.sun.media.jfxmediaimpl.platform, com.sun.m
>> edia.jfxmediaimpl.platform.gstreamer,
>> com.sun.media.jfxmediaimpl.platform.ios,
>> com.sun.media.jfxmediaimpl.platform.java, com.sun.media.jfxmediaimpl
>> .platform.osx, com.sun.prism, javafx.application, javafx.beans,
>> javafx.beans.binding, javafx.beans.property, javafx.beans.value,
>> javafx.collections
>> , javafx.event, javafx.geometry, javafx.scene, javafx.scene.image,
>> javafx.scene.media, javafx.util]
>> [error]  : Exception: java.lang.ArrayIndexOutOfBoundsException
>> [error]  : Invalid class file module-info.class
>> (java.lang.ArrayIndexOutOfBoundsException)
>> [info] Bundling Artifact org.openjfx:javafx-media:jar:win:11.0.1
>> [warn] BND instructions are NOT applied to the transitive dependencies
>> of  org.openjfx:javafx-media:jar:win:11.0.1
>>
>> Followed by thread dumps.  However mvn still reports BUILD SUCCESS
>>
>> Looks like I get the same result even when
>> - using an older version of maven
>> - building jmc-c56816b25c99 or jmc-5e0a199762b6 from a few months ago
>> (used to work)
>> - deleting maven's .m2 cache
>> - using Windows or Linux
>> - using different JDK versions
>>
>> I assume maven must be pulling down something newer than it was a couple
>> months ago.
>> It sounds related to this
>> https://stackoverflow.com/questions/50530927/maven-bundle-plugin-fails-with-invalid-class-file-module-info-class
>>
>>
>> What's the trick here?  Thanks! -Andrew
> Hey Andrew,
>
> I tried running it this morning and when I examined the results of
> p2:site against my pre-existing jars, they weren't different. When I
> continued the build process, building core, starting the Jetty and
> then building the root, I did not run into any issues. Does continuing
> the build process work for you as well? For what it's worth, I was on
> revision 527d408d2a4e
>
>
> Regards,

-- 
Andrew Munn
(312) 320-0232


From am at topazdevelopment.com  Thu Aug 15 02:33:05 2019
From: am at topazdevelopment.com (am at topazdevelopment.com)
Date: Wed, 14 Aug 2019 22:33:05 -0400
Subject: JMX bean browser problem...
Message-ID: <c987252c-cec7-05bb-e3ff-68c7237dbd53@topazdevelopment.com>

The JMC MBean browser will not permit expanding JMX Endpoints exposed by 
Spring Boot Actuator.? JConsole will.? Is this a known issue?? I don't 
see any open bugs which appear related but am happy to file one.

-Andrew Munn


From marcus at hirt.se  Thu Aug 15 19:52:45 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Thu, 15 Aug 2019 21:52:45 +0200
Subject: Sv: JMX bean browser problem...
In-Reply-To: <c987252c-cec7-05bb-e3ff-68c7237dbd53@topazdevelopment.com>
References: <c987252c-cec7-05bb-e3ff-68c7237dbd53@topazdevelopment.com>
Message-ID: <015901d553a3$01c79790$0556c6b0$@hirt.se>

Hi Andrew!

I have no idea - I am not a Spring Boot Actuator user, so can't test or repro. Are you on the JMC slack?

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r am at topazdevelopment.com
Skickat: den 15 augusti 2019 04:33
Till: jmc-dev at openjdk.java.net
?mne: JMX bean browser problem...

The JMC MBean browser will not permit expanding JMX Endpoints exposed by Spring Boot Actuator.  JConsole will.  Is this a known issue?  I don't see any open bugs which appear related but am happy to file one.

-Andrew Munn



From am at topazdevelopment.com  Thu Aug 15 20:09:13 2019
From: am at topazdevelopment.com (am at topazdevelopment.com)
Date: Thu, 15 Aug 2019 16:09:13 -0400
Subject: Sv: JMX bean browser problem...
In-Reply-To: <015901d553a3$01c79790$0556c6b0$@hirt.se>
References: <c987252c-cec7-05bb-e3ff-68c7237dbd53@topazdevelopment.com>
 <015901d553a3$01c79790$0556c6b0$@hirt.se>
Message-ID: <50fafb46-3d94-b705-ba25-2514e70b965e@topazdevelopment.com>

Hey Marcus!

I am not on the JMC slack but I will jump on there.

I can also package up something small that demonstrates the issue I'm 
seeing.
-Andrew


On 8/15/2019 3:52 PM, Marcus Hirt wrote:
> Hi Andrew!
>
> I have no idea - I am not a Spring Boot Actuator user, so can't test or repro. Are you on the JMC slack?
>
> Kind regards,
> Marcus
>
> -----Ursprungligt meddelande-----
> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r am at topazdevelopment.com
> Skickat: den 15 augusti 2019 04:33
> Till: jmc-dev at openjdk.java.net
> ?mne: JMX bean browser problem...
>
> The JMC MBean browser will not permit expanding JMX Endpoints exposed by Spring Boot Actuator.  JConsole will.  Is this a known issue?  I don't see any open bugs which appear related but am happy to file one.
>
> -Andrew Munn
>
>

-- 
Andrew Munn
(312) 320-0232


From jkang at redhat.com  Fri Aug 16 14:10:43 2019
From: jkang at redhat.com (Jie Kang)
Date: Fri, 16 Aug 2019 10:10:43 -0400
Subject: RFR: JMC-6534 String deduplication rule assumes only G1 has feature
Message-ID: <CAEBeOcpUjLR1arYWzVSaoFT8nQ6h3jKeepREoBxc3JW6D5JEBw@mail.gmail.com>

Hi,

Please review this update to the String Deduplication rule. It now
also checks for Shenandoah GC and the messages have been updated
appropriately. I would also like to request translation assistance for
said messages for Chinese and Japanese. Specifically:

StringDeduplicationRule_RESULT_LONG_DESCRIPTION
StringDeduplicationRule_RESULT_GC_LONG

Webrev:
http://cr.openjdk.java.net/~jkang/jmc-6534/webrev.01/
JIRA:
https://bugs.openjdk.java.net/browse/JMC-6534


Regards,

From hdafgard at gmail.com  Fri Aug 16 14:17:25 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Fri, 16 Aug 2019 16:17:25 +0200
Subject: RFR: JMC-6534 String deduplication rule assumes only G1 has
 feature
In-Reply-To: <CAEBeOcpUjLR1arYWzVSaoFT8nQ6h3jKeepREoBxc3JW6D5JEBw@mail.gmail.com>
References: <CAEBeOcpUjLR1arYWzVSaoFT8nQ6h3jKeepREoBxc3JW6D5JEBw@mail.gmail.com>
Message-ID: <CADFkdVQv0ZvMVbcuh5WHak3DEkF_Fhiz-4FC5BwBtZcrvNJRhw@mail.gmail.com>

Hi Jie,

This change looks good to me!


Cheers,
Henrik Dafg?rd


On Fri, 16 Aug 2019 at 16:11, Jie Kang <jkang at redhat.com> wrote:

> Hi,
>
> Please review this update to the String Deduplication rule. It now
> also checks for Shenandoah GC and the messages have been updated
> appropriately. I would also like to request translation assistance for
> said messages for Chinese and Japanese. Specifically:
>
> StringDeduplicationRule_RESULT_LONG_DESCRIPTION
> StringDeduplicationRule_RESULT_GC_LONG
>
> Webrev:
> http://cr.openjdk.java.net/~jkang/jmc-6534/webrev.01/
> JIRA:
> https://bugs.openjdk.java.net/browse/JMC-6534
>
>
> Regards,
>

From jkang at redhat.com  Fri Aug 16 19:28:38 2019
From: jkang at redhat.com (Jie Kang)
Date: Fri, 16 Aug 2019 15:28:38 -0400
Subject: RFR: JMC-6115 Use Jemmy builds from Maven Central
Message-ID: <CAEBeOcpD37YGGH-Bv0K5duZk5-5ttgF7rhoMrAP1Y6k7uj-HFQ@mail.gmail.com>

Hi,

Please review this fix to use Jemmy dependencies from Maven, removing
the need for users to manually acquire Jemmy (download & compile). The
dependencies now come from the p2 repository and use the updated Jemmy
version 2.0.0. The indentation is also fixed for
application/uitests/org.openjdk.jmc.test.jemmy/pom.xml.

Webrev:
http://cr.openjdk.java.net/~jkang/jmc-6115/webrev.01/
Bug:
https://bugs.openjdk.java.net/browse/JMC-6115


Regards,

From marcus at hirt.se  Sat Aug 17 11:43:35 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Sat, 17 Aug 2019 13:43:35 +0200
Subject: Sv: JMC-6115 Use Jemmy builds from Maven Central
In-Reply-To: <CAEBeOcpD37YGGH-Bv0K5duZk5-5ttgF7rhoMrAP1Y6k7uj-HFQ@mail.gmail.com>
References: <CAEBeOcpD37YGGH-Bv0K5duZk5-5ttgF7rhoMrAP1Y6k7uj-HFQ@mail.gmail.com>
Message-ID: <08bf01d554f1$0114ce90$033e6bb0$@hirt.se>

Looks good!

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Jie Kang
Skickat: den 16 augusti 2019 21:29
Till: jmc-dev at openjdk.java.net
?mne: RFR: JMC-6115 Use Jemmy builds from Maven Central

Hi,

Please review this fix to use Jemmy dependencies from Maven, removing the need for users to manually acquire Jemmy (download & compile). The dependencies now come from the p2 repository and use the updated Jemmy version 2.0.0. The indentation is also fixed for application/uitests/org.openjdk.jmc.test.jemmy/pom.xml.

Webrev:
http://cr.openjdk.java.net/~jkang/jmc-6115/webrev.01/
Bug:
https://bugs.openjdk.java.net/browse/JMC-6115


Regards,


From almacdon at redhat.com  Mon Aug 19 13:33:26 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Mon, 19 Aug 2019 09:33:26 -0400
Subject: RFR: JMC-6115 Use Jemmy builds from Maven Central
In-Reply-To: <CAEBeOcpD37YGGH-Bv0K5duZk5-5ttgF7rhoMrAP1Y6k7uj-HFQ@mail.gmail.com>
References: <CAEBeOcpD37YGGH-Bv0K5duZk5-5ttgF7rhoMrAP1Y6k7uj-HFQ@mail.gmail.com>
Message-ID: <CAOsn=kqMMsYkZyd1fQSb0T1s5nrcPd9ztzAp8oqOAKzKyZY+Vg@mail.gmail.com>

Hi Jie,

On Fri, Aug 16, 2019 at 3:29 PM Jie Kang <jkang at redhat.com> wrote:

> Hi,
>
> Please review this fix to use Jemmy dependencies from Maven, removing
> the need for users to manually acquire Jemmy (download & compile). The
> dependencies now come from the p2 repository and use the updated Jemmy
> version 2.0.0. The indentation is also fixed for
> application/uitests/org.openjdk.jmc.test.jemmy/pom.xml.
>
> Webrev:
> http://cr.openjdk.java.net/~jkang/jmc-6115/webrev.01/
> Bug:
> https://bugs.openjdk.java.net/browse/JMC-6115


These changes look good to me. The uitests work properly in my Linux
(Travis & local) and Windows (local) environments.

Here's a sample build with your patch applied:
https://travis-ci.org/aptmac/jmc-qa/builds/572875046


>
>
>
> Regards,
>

Cheers,

Alex

From almacdon at redhat.com  Mon Aug 19 16:56:14 2019
From: almacdon at redhat.com (almacdon at redhat.com)
Date: Mon, 19 Aug 2019 16:56:14 +0000
Subject: hg: jmc/jmc: JMC-6115: Use Jemmy builds from Maven Central
Message-ID: <201908191656.x7JGuEsm025165@aojmv0008.oracle.com>

Changeset: cc07a1f270e9
Author:    jkang <jkang at redhat.com>
Date:      2019-08-19 11:57 -0400
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/cc07a1f270e9

JMC-6115: Use Jemmy builds from Maven Central
Summary: Jemmy now comes from the local p2 repository and uses the updated Jemmy version 2.0.0
Reviewed-by: aptmac, hirt

! README.md
! application/uitests/org.openjdk.jmc.test.jemmy/.classpath
! application/uitests/org.openjdk.jmc.test.jemmy/META-INF/MANIFEST.MF
! application/uitests/org.openjdk.jmc.test.jemmy/build.properties
! application/uitests/org.openjdk.jmc.test.jemmy/pom.xml
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/base/wrappers/MCJemmyBase.java
! releng/platform-definitions/platform-definition-2018-09/platform-definition-2018-09.target
! releng/platform-definitions/platform-definition-2018-12/platform-definition-2018-12.target
! releng/platform-definitions/platform-definition-2019-03/platform-definition-2019-03.target
! releng/platform-definitions/platform-definition-2019-06/platform-definition-2019-06.target
! releng/platform-definitions/platform-definition-photon/platform-definition-photon.target
! releng/third-party/pom.xml


From neugens at redhat.com  Tue Aug 20 06:49:24 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 20 Aug 2019 08:49:24 +0200
Subject: RFC: https://bugs.openjdk.java.net/browse/JMC-6554
Message-ID: <53b0a725-c962-d68c-46f6-2c8a124f91a9@redhat.com>

Hi!

I would like to push the patch Aleksey proposed on JMC-6554.

I understand there's some concern that this may not be incompatible with
Oracle proprietary builds, but I have no way to test this, nevertheless,
going forward OpenJDK 8 (which is still the reference implementation)
will likely have JFR and JMC should work with it, possibly by 7.1 already.

Can someone from Oracle test the patch and give some feedback?

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus.hirt at datadoghq.com  Tue Aug 20 08:13:18 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 20 Aug 2019 10:13:18 +0200
Subject: RFC: https://bugs.openjdk.java.net/browse/JMC-6554
In-Reply-To: <53b0a725-c962-d68c-46f6-2c8a124f91a9@redhat.com>
References: <53b0a725-c962-d68c-46f6-2c8a124f91a9@redhat.com>
Message-ID: <CAOpWGx2GnDvoFAa+6+cYRzD=f-JRF6oC2cEKt=LuqhMyn7GLsA@mail.gmail.com>

Someone from Oracle should rework this patch into something that works
properly with Oracle JDK 7 to 10. Guru, can someone from the Oracle JMC
team own JMC-6554.

Kind regards,
Marcus

On Tue, Aug 20, 2019 at 8:49 AM Mario Torre <neugens at redhat.com> wrote:

> Hi!
>
> I would like to push the patch Aleksey proposed on JMC-6554.
>
> I understand there's some concern that this may not be incompatible with
> Oracle proprietary builds, but I have no way to test this, nevertheless,
> going forward OpenJDK 8 (which is still the reference implementation)
> will likely have JFR and JMC should work with it, possibly by 7.1 already.
>
> Can someone from Oracle test the patch and give some feedback?
>
> Cheers,
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From neugens at redhat.com  Tue Aug 20 08:41:56 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 20 Aug 2019 10:41:56 +0200
Subject: RFC: https://bugs.openjdk.java.net/browse/JMC-6554
In-Reply-To: <CAOpWGx2GnDvoFAa+6+cYRzD=f-JRF6oC2cEKt=LuqhMyn7GLsA@mail.gmail.com>
References: <53b0a725-c962-d68c-46f6-2c8a124f91a9@redhat.com>
 <CAOpWGx2GnDvoFAa+6+cYRzD=f-JRF6oC2cEKt=LuqhMyn7GLsA@mail.gmail.com>
Message-ID: <CAJwKKmbxs4r1QB8pzyt9+atTehv83LvDJuMVFK0GPEMt4yU=xA@mail.gmail.com>

We would need some acknowledgement that this will be done in some timing
fashion however, I would like to avoid that we ship this patch downstream
only for the need to support the closed 7.

In general I think this whole code shouldn?t be part of upstream JMC, you
mentioned some reason for this, can you explain better the issue and why is
it needed?

Cheers,
Mario

On Tuesday, August 20, 2019, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:

> Someone from Oracle should rework this patch into something that works
> properly with Oracle JDK 7 to 10. Guru, can someone from the Oracle JMC
> team own JMC-6554.
>
> Kind regards,
> Marcus
>
> On Tue, Aug 20, 2019 at 8:49 AM Mario Torre <neugens at redhat.com> wrote:
>
>> Hi!
>>
>> I would like to push the patch Aleksey proposed on JMC-6554.
>>
>> I understand there's some concern that this may not be incompatible with
>> Oracle proprietary builds, but I have no way to test this, nevertheless,
>> going forward OpenJDK 8 (which is still the reference implementation)
>> will likely have JFR and JMC should work with it, possibly by 7.1 already.
>>
>> Can someone from Oracle test the patch and give some feedback?
>>
>> Cheers,
>> Mario
>> --
>> Mario Torre
>> Associate Manager, Software Engineering
>> Red Hat GmbH <https://www.redhat.com>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>
>

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH &lt;https://www.redhat.com&gt;<br>9704 A60C B4BE A8B8 0F30
9205 5D7E 4952 3F65 7898

From marcus.hirt at datadoghq.com  Tue Aug 20 09:12:08 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 20 Aug 2019 11:12:08 +0200
Subject: RFC: https://bugs.openjdk.java.net/browse/JMC-6554
In-Reply-To: <CAJwKKmbxs4r1QB8pzyt9+atTehv83LvDJuMVFK0GPEMt4yU=xA@mail.gmail.com>
References: <53b0a725-c962-d68c-46f6-2c8a124f91a9@redhat.com>
 <CAOpWGx2GnDvoFAa+6+cYRzD=f-JRF6oC2cEKt=LuqhMyn7GLsA@mail.gmail.com>
 <CAJwKKmbxs4r1QB8pzyt9+atTehv83LvDJuMVFK0GPEMt4yU=xA@mail.gmail.com>
Message-ID: <CAOpWGx1O1r=KLYqmXqZ73U5Mz=4gHNB1s_7Kw2_h9dtC6JZ77Q@mail.gmail.com>

I'd like to avoid fragmentation. In the best case scenario, any downstream
build of JMC would work with most JVMs. Oracle invented JFR and JMC and
donated it all to the community. I think it's fair to continue to make sure
JMC keeps working with the early versions of Oracle's work, and that we
avoid causing unnecessary grief.

I agree that this work should be prioritized, and that one of the goals of
7.1.0 should be to work well with the backport. I've raised the priority of
this bug to P2, and asked Oracle to own it. I'll talk to Guru about the
earliest possible iteration when this work can be targeted.

Kind regards,
Marcus

On Tue, Aug 20, 2019 at 10:41 AM Mario Torre <neugens at redhat.com> wrote:

> We would need some acknowledgement that this will be done in some timing
> fashion however, I would like to avoid that we ship this patch downstream
> only for the need to support the closed 7.
>
> In general I think this whole code shouldn?t be part of upstream JMC, you
> mentioned some reason for this, can you explain better the issue and why is
> it needed?
>
> Cheers,
> Mario
>
> On Tuesday, August 20, 2019, Marcus Hirt <marcus.hirt at datadoghq.com>
> wrote:
>
>> Someone from Oracle should rework this patch into something that works
>> properly with Oracle JDK 7 to 10. Guru, can someone from the Oracle JMC
>> team own JMC-6554.
>>
>> Kind regards,
>> Marcus
>>
>> On Tue, Aug 20, 2019 at 8:49 AM Mario Torre <neugens at redhat.com> wrote:
>>
>>> Hi!
>>>
>>> I would like to push the patch Aleksey proposed on JMC-6554.
>>>
>>> I understand there's some concern that this may not be incompatible with
>>> Oracle proprietary builds, but I have no way to test this, nevertheless,
>>> going forward OpenJDK 8 (which is still the reference implementation)
>>> will likely have JFR and JMC should work with it, possibly by 7.1
>>> already.
>>>
>>> Can someone from Oracle test the patch and give some feedback?
>>>
>>> Cheers,
>>> Mario
>>> --
>>> Mario Torre
>>> Associate Manager, Software Engineering
>>> Red Hat GmbH <https://www.redhat.com>
>>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>>
>>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH &lt;https://www.redhat.com&gt;<br>9704 A60C B4BE A8B8 0F30
> 9205 5D7E 4952 3F65 7898
>

From neugens at redhat.com  Tue Aug 20 10:38:36 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 20 Aug 2019 12:38:36 +0200
Subject: RFC: https://bugs.openjdk.java.net/browse/JMC-6554
In-Reply-To: <CAOpWGx1O1r=KLYqmXqZ73U5Mz=4gHNB1s_7Kw2_h9dtC6JZ77Q@mail.gmail.com>
References: <53b0a725-c962-d68c-46f6-2c8a124f91a9@redhat.com>
 <CAOpWGx2GnDvoFAa+6+cYRzD=f-JRF6oC2cEKt=LuqhMyn7GLsA@mail.gmail.com>
 <CAJwKKmbxs4r1QB8pzyt9+atTehv83LvDJuMVFK0GPEMt4yU=xA@mail.gmail.com>
 <CAOpWGx1O1r=KLYqmXqZ73U5Mz=4gHNB1s_7Kw2_h9dtC6JZ77Q@mail.gmail.com>
Message-ID: <76b66416-b16d-a3ee-0503-e018aeecd32b@redhat.com>

On 20/08/2019 11:12, Marcus Hirt wrote:
> I'd like to avoid fragmentation. In the best case scenario, any
> downstream build of JMC would work with most JVMs. Oracle invented JFR
> and JMC and donated it all to the community. I think it's fair to
> continue to make sure JMC keeps working with the early versions of
> Oracle's work, and that we avoid causing unnecessary grief.

Of course, I just want to be sure it doesn't get forgotten.

> I agree that this work should be prioritized, and that one of the goals
> of 7.1.0 should be to work well with the backport. I've raised the
> priority of this bug to P2, and asked Oracle to own it. I'll talk to
> Guru about the earliest possible iteration when this work can be targeted.

Sure.

Cheers,
Mario

> Kind regards,
> Marcus
> 
> On Tue, Aug 20, 2019 at 10:41 AM Mario Torre <neugens at redhat.com
> <mailto:neugens at redhat.com>> wrote:
> 
>     We would need some acknowledgement that this will be done in some
>     timing fashion however, I would like to avoid that we ship this
>     patch downstream only for the need to support the closed 7.
> 
>     In general I think this whole code shouldn?t be part of upstream
>     JMC, you mentioned some reason for this, can you explain better the
>     issue and why is it needed?
> 
>     Cheers,
>     Mario?
> 
>     On Tuesday, August 20, 2019, Marcus Hirt <marcus.hirt at datadoghq.com
>     <mailto:marcus.hirt at datadoghq.com>> wrote:
> 
>         Someone from Oracle should rework this patch into something that
>         works properly with Oracle JDK 7 to 10. Guru, can someone from
>         the Oracle JMC team own JMC-6554.
> 
>         Kind regards,
>         Marcus
> 
>         On Tue, Aug 20, 2019 at 8:49 AM Mario Torre <neugens at redhat.com
>         <mailto:neugens at redhat.com>> wrote:
> 
>             Hi!
> 
>             I would like to push the patch Aleksey proposed on JMC-6554.
> 
>             I understand there's some concern that this may not be
>             incompatible with
>             Oracle proprietary builds, but I have no way to test this,
>             nevertheless,
>             going forward OpenJDK 8 (which is still the reference
>             implementation)
>             will likely have JFR and JMC should work with it, possibly
>             by 7.1 already.
> 
>             Can someone from Oracle test the patch and give some feedback?
> 
>             Cheers,
>             Mario
>             -- 
>             Mario Torre
>             Associate Manager, Software Engineering
>             Red Hat GmbH <https://www.redhat.com>
>             9704 A60C B4BE A8B8 0F30? 9205 5D7E 4952 3F65 7898
> 
> 
> 
>     -- 
>     Mario Torre
>     Associate Manager, Software Engineering
>     Red Hat GmbH &lt;https://www.redhat.com&gt;<br>9704 A60C B4BE A8B8
>     0F30? 9205 5D7E 4952 3F65 7898
> 


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From jkang at redhat.com  Tue Aug 20 17:45:16 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 20 Aug 2019 13:45:16 -0400
Subject: [Fedora] Request for testing JMC packages in F30
Message-ID: <CAEBeOcpPE53e6fg3m5DB5kj5sARjZax1kPTv-8q2cARL6RML6Q@mail.gmail.com>

Hi all,

In Fedora 30, there are two streams for JMC, latest tracking the
latest in upstream and 7 tracking the 7.x.y series.

If you have some cycles and an F30 machine I'd appreciate testing the
JMC streams with the instructions below. The updates require 3
positive karma (3 people) to push to stable, or a week to pass. Bugs
can be reported for product 'Fedora Modules', component 'jmc' at
http://bugzilla.redhat.com

# Instructions to Test

latest stream:
$ sudo dnf --enablerepo=updates-testing-modular module install
jmc:latest/default
$ jmc

To switch streams, remove and reset the module:
$ sudo dnf --enablerepo=updates-testing-modular module remove jmc
$ sudo dnf --enablerepo=updates-testing-modular module reset jmc

7 stream:
$ sudo dnf --enablerepo=updates-testing-modular module install jmc:7/default
$ jmc

With a Fedora account, karma can then be added at:

latest stream:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-9926ee53e8

7 stream:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-1f2ef177b6


Regards,

From kxu at redhat.com  Wed Aug 21 14:40:56 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Wed, 21 Aug 2019 10:40:56 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
Message-ID: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>

Hello all,

This change aims to port JOverflow from using JavaFX to SWT/JFace, so
the extra dependencies could be dropped. Additionally, this change
makes JMC-6343 is no longer valid.

This port (re)implements all features available in the original
version, and UI design is kept as close as possible. Please let me
know your thoughts. Thank you very much!

Also, thanks Jie for creating this webrev for me!

Webrev:
https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.01/
Bug:
https://bugs.openjdk.java.net/browse/JMC-6555

Regards,
Kangcheng

From sasiddiq at redhat.com  Fri Aug 23 19:31:13 2019
From: sasiddiq at redhat.com (Salman Siddiqui)
Date: Fri, 23 Aug 2019 15:31:13 -0400
Subject: RFR: JMC-6553 Update error message when JFR is not available
Message-ID: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>

Hi all,

Please review edit to error message for unavailable JFR below.

JIRA: https://bugs.openjdk.java.net/browse/JMC-6553

Thanks,
Salman


diff -r cc07a1f270e9
application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
---
a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
   Mon Aug 19 11:57:12 2019 -0400
+++
b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
   Fri Aug 23 15:29:46 2019 -0400
@@ -45,7 +45,7 @@
 JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
 JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
unknown JVM. This will most likely not succeed unless you're running the
JMX Console, and even then functionality will be limited. \n\nAre you sure
you want to continue?
 JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
you sure you want to continue?
-JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
not recent enough for full functionality in the JMX Console. For full
functionality you need to connect to a Java 7u40 or later JVM. Do you still
want to connect?
+JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
not recent enough for full functionality in the JMX Console. For full
functionality you need to connect to an OracleJDK 7u40 or later JVM or an
OpenJDK 11+ JVM. Do you still want to connect?
 JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
Use a 4.x version of Mission Control when connecting to a JRockit.
 JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
supported
 JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight Recorder is
not supported for JVMs with Java versions below 7u4
@@ -54,7 +54,7 @@
 JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
Recorder is not fully supported for JVMs with Java versions below 7u40
 JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is
not supported for non HotSpot JVMs
 JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
is not supported for non HotSpot JVMs
-JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
enabled. To enable this you need to use a Java 7u4 or later JVM started
with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
+JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
enabled. To enable this you need to use an OracleJDK 7u4 or later JVM
started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
OpenJDK 11+ JVM.
 JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
not enabled
 JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is explicitly
disabled. To enable the Flight Recorder, remove -XX:-FlightRecorder from
the command line.
 JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
disabled

From marcus at hirt.se  Fri Aug 23 20:29:56 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 23 Aug 2019 22:29:56 +0200
Subject: Sv: JMC-6553 Update error message when JFR is not available
In-Reply-To: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>
References: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>
Message-ID: <1a3e01d559f1$8713a660$953af320$@hirt.se>

Hi Salman,

I believe the Oracle JDK has a space between Oracle and JDK 
(as opposed to OpenJDK, which is written together).

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Salman Siddiqui
Skickat: den 23 augusti 2019 21:31
Till: jmc-dev at openjdk.java.net
?mne: RFR: JMC-6553 Update error message when JFR is not available

Hi all,

Please review edit to error message for unavailable JFR below.

JIRA: https://bugs.openjdk.java.net/browse/JMC-6553

Thanks,
Salman


diff -r cc07a1f270e9
application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
---
a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
   Mon Aug 19 11:57:12 2019 -0400
+++
b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
   Fri Aug 23 15:29:46 2019 -0400
@@ -45,7 +45,7 @@
 JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM  JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an unknown JVM. This will most likely not succeed unless you're running the JMX Console, and even then functionality will be limited. \n\nAre you sure you want to continue?
 JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre you sure you want to continue?
-JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is not recent enough for full functionality in the JMX Console. For full functionality you need to connect to a Java 7u40 or later JVM. Do you still want to connect?
+JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
not recent enough for full functionality in the JMX Console. For full functionality you need to connect to an OracleJDK 7u40 or later JVM or an OpenJDK 11+ JVM. Do you still want to connect?
 JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
Use a 4.x version of Mission Control when connecting to a JRockit.
 JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7 +54,7 @@  JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
Recorder is not fully supported for JVMs with Java versions below 7u40  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not supported for non HotSpot JVMs  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder is not supported for non HotSpot JVMs -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not enabled. To enable this you need to use a Java 7u4 or later JVM started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
+JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
enabled. To enable this you need to use an OracleJDK 7u4 or later JVM started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an OpenJDK 11+ JVM.
 JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is explicitly disabled. To enable the Flight Recorder, remove -XX:-FlightRecorder from the command line.
 JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly disabled


From sasiddiq at redhat.com  Mon Aug 26 13:10:39 2019
From: sasiddiq at redhat.com (Salman Siddiqui)
Date: Mon, 26 Aug 2019 09:10:39 -0400
Subject: JMC-6553 Update error message when JFR is not available
In-Reply-To: <1a3e01d559f1$8713a660$953af320$@hirt.se>
References: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>
 <1a3e01d559f1$8713a660$953af320$@hirt.se>
Message-ID: <CAN4WuHYoQMPV+me7eYJE9aHX8PVedvB=8bn63pvCbiuntUE5Hw@mail.gmail.com>

Hi Marcus,

Thanks for the correction. Fixed below.

Regards,
Salman


diff -r cc07a1f270e9
application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
---
a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
   Mon Aug 19 11:57:12 2019 -0400
+++
b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
   Fri Aug 23 15:29:46 2019 -0400
@@ -45,7 +45,7 @@
 JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
unknown JVM. This will most likely not succeed unless you're running the
JMX Console, and even then functionality will be limited. \n\nAre you sure
you want to continue?
 JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
you sure you want to continue?
-JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
not recent enough for full functionality in the JMX Console. For full
functionality you need to connect to a Java 7u40 or later JVM. Do you still
want to connect?
+JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
not recent enough for full functionality in the JMX Console. For full
functionality you need to connect to an Oracle JDK 7u40 or later JVM or an
OpenJDK 11+ JVM. Do you still want to connect?
 JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
Use a 4.x version of Mission Control when connecting to a JRockit.
 JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
+54,7 @@
JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
Recorder is not fully supported for JVMs with Java versions below 7u40
JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not
supported for non HotSpot JVMs
JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
is not supported for non HotSpot JVMs
-JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
enabled. To enable this you need to use a Java 7u4 or later JVM started
with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
+JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
enabled. To enable this you need to use an Oracle JDK 7u4 or later JVM
started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
OpenJDK 11+ JVM.
 JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
explicitly disabled. To enable the Flight Recorder, remove
-XX:-FlightRecorder from the command line.
 JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
disabled

On Fri, Aug 23, 2019 at 4:30 PM Marcus Hirt <marcus at hirt.se> wrote:

> Hi Salman,
>
> I believe the Oracle JDK has a space between Oracle and JDK
> (as opposed to OpenJDK, which is written together).
>
> Kind regards,
> Marcus
>
> -----Ursprungligt meddelande-----
> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Salman Siddiqui
> Skickat: den 23 augusti 2019 21:31
> Till: jmc-dev at openjdk.java.net
> ?mne: RFR: JMC-6553 Update error message when JFR is not available
>
> Hi all,
>
> Please review edit to error message for unavailable JFR below.
>
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6553
>
> Thanks,
> Salman
>
>
> diff -r cc07a1f270e9
>
> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> ---
>
> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>    Mon Aug 19 11:57:12 2019 -0400
> +++
>
> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>    Fri Aug 23 15:29:46 2019 -0400
> @@ -45,7 +45,7 @@
>  JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> unknown JVM. This will most likely not succeed unless you're running the
> JMX Console, and even then functionality will be limited. \n\nAre you sure
> you want to continue?
>  JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
> a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
> you sure you want to continue?
> -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> not recent enough for full functionality in the JMX Console. For full
> functionality you need to connect to a Java 7u40 or later JVM. Do you still
> want to connect?
> +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> not recent enough for full functionality in the JMX Console. For full
> functionality you need to connect to an OracleJDK 7u40 or later JVM or an
> OpenJDK 11+ JVM. Do you still want to connect?
>  JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> Use a 4.x version of Mission Control when connecting to a JRockit.
>  JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> +54,7 @@
> JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> Recorder is not fully supported for JVMs with Java versions below 7u40
> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not
> supported for non HotSpot JVMs
> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
> is not supported for non HotSpot JVMs
> -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> enabled. To enable this you need to use a Java 7u4 or later JVM started
> with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> enabled. To enable this you need to use an OracleJDK 7u4 or later JVM
> started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> OpenJDK 11+ JVM.
>  JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
> not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> explicitly disabled. To enable the Flight Recorder, remove
> -XX:-FlightRecorder from the command line.
>  JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> disabled
>
>

From jkang at redhat.com  Mon Aug 26 13:15:39 2019
From: jkang at redhat.com (Jie Kang)
Date: Mon, 26 Aug 2019 09:15:39 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
Message-ID: <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>

On Wed, Aug 21, 2019 at 10:41 AM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> Hello all,
>
> This change aims to port JOverflow from using JavaFX to SWT/JFace, so
> the extra dependencies could be dropped. Additionally, this change
> makes JMC-6343 is no longer valid.
>
> This port (re)implements all features available in the original
> version, and UI design is kept as close as possible. Please let me
> know your thoughts. Thank you very much!
>
> Also, thanks Jie for creating this webrev for me!
>
> Webrev:
> https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.01/
> Bug:
> https://bugs.openjdk.java.net/browse/JMC-6555

Hey Arvin,

Overall nice work! Visually and functionally (minor manual testing) it
looks to be working quite nicely. I have some comments and nits below,
separated in two sections. The nits in the second section can be
addressed in follow-up JIRA issues + patches.

# Section One

##
+import org.eclipse.swt.widgets.*;

There are a number of imports of x.y.* packages. Are all the classes
from these required? If not I would use individual imports. This makes
it easier to see exactly what package a class comes form.

##
With the removal of openjfx, it looks like org.openjdk.jmc.javafx.osgi
is no longer used. Can this be removed as well? As well, can the
javafx dependencies defined in the p2 repository and set in the target
platform files also be removed?

##
There are various instances of whitespace being included for newlines.
Please try to remove these, probably most easily done with an
auto-formatting tool. For what it's worth, in my terminal, invocations
of `hg diff` shows these as big blocks of red. Also it seems some
files use tabs and others use spaces. I think all should be switched
to tabs for this project.

##
+++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
+    private boolean mIsUpdatingModel;
[...]
+    private void updateModel() {
+        if (mIsUpdatingModel) {
+            // skip updating if busy
+            return;
+        }
+
+        mIsUpdatingModel = true;
[...]
+        mIsUpdatingModel = false;
+    }
+
+    void reset() {
+        mIsUpdatingModel = true;
[...]
+        mIsUpdatingModel = false;
[...]

The thread safety of this construct is concerning. Is it expected to
only be called by a single thread? If yes, I'd appreciate a comment
specifying that it is not thread-safe, but it is okay because no more
than one thread calls this. If no, then I think a lock would be more
appropriate than a boolean.

Also there is a guard in updateModel() but no guard in reset(); is
that intentional? Can things go awry if reset occurs while updateModel
is executing? I guess these kinds of questions need only be considered
if there is multi-threaded access...

##
+++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/BaseViewer.java
[...]
+    public void setHeapSize(long size) {
+        mHeapSize = size;
+    }
+
+    public long getHeapSize() {
+        return mHeapSize;
+    }

I don't see any usages of getHeapSize or of mHeapSize within this
class. Can they be removed?

##
+++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/MemoryStatisticsTab
leViewer.java
+class MemoryStatisticsTableViewer extends TableViewer {
+
+       private long mHeapSize;
[...]
+       MemoryStatisticsTableViewer(Composite parent, int style,
Function<MemoryStatisticsItem, Color> colorProvider) {
[...]
+               createTableColumnViewer("Memory KB",
+                               model -> String.format("%d (%d%%)",
model.getMemory() / 1024, model.getMemory() * 100 / mHeapSize),
[...]
+       void setHeapSize(long size) {
+               mHeapSize = size;
+       }

Is it possible mHeapSize is *not* set via the package private function
before being used in the label provider created by the constructor? I
might initialize it to 1 just to prevent a possible NPE.


# Section 2: Can be addressed in follow-up JIRA issues + patches, or
immediately if easily done

##
The values displayed are no longer comma separated. For example
1234567 instead of 1,234,567. I think comma-separation increases
readability. If possible could this be added?

##
For the colour selection of arcs, some colours blend quite closely
with each other. While we're here it would be nice to only use
contrasting colours (rainbow).

##
The selection made in the Ancestor Referrer table persists though the
table contents change after selection. In the jfx version, the table
is deselected after. To reproduce, use the mouse to select a row in
the table. After selection, the table contents are changed but the row
(which has different content) remains selected. I think it's okay to
deselect after, or better yet, re-select the correct row.

##
When loading the same hprof file into JOverflow, some values are off
by one between the jfx and swt versions. Is it possibly due to
different rounding in the ui? It looks like the core api for joverflow
is unchanged. If so, this can probably be ignored. I saw this for
values in the Ancestor Referrer table.

##
+               // FIXME: Bug 165637 - [Viewers]
ArrayIndexOutOfBoundsException exception in ConcurrentTableUpdator
(used in DeferredContentProvider)
+        // https://bugs.eclipse.org/bugs/show_bug.cgi?id=165637
+               mContentProvider = new DeferredContentProvider((lhs, rhs) -> 0);
[...]
+                                       // FIXME: Bug 146799 - Blank
last table item on virtual table
+                       // https://bugs.eclipse.org/bugs/show_bug.cgi?id=146799

Ouch. Did you see these occur in practice? I guess it can be a
follow-up issue to resolve (probably by replacing with a different
implementation) but I'd be very reluctant to allow this to sit for any
length of time.

##
+++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
[...]
+        mOverheadTypeViewer.setHeapSize(heapSize);
+        mReferrerViewer.setHeapSize(heapSize);
+        mClusterGroupViewer.setHeapSize(heapSize);
+        mAncestorViewer.setHeapSize(heapSize);
[...]
+        mReferrerViewer.allIncluded();
+        mClusterGroupViewer.allIncluded();
+        mAncestorViewer.allIncluded();
+        mOverheadTypeViewer.allIncluded();
+        for (ModelListener l : mModelListeners) {
+            l.allIncluded();
+        }
[...]
+        mOverheadTypeViewer.reset();
+        mReferrerViewer.reset();
+        mClusterGroupViewer.reset();
+        mAncestorViewer.reset();


These duplicate calls for the four sub-components feel sub-optimal,
especially in the allIncluded calls. Would it be appropriate to have
the for-loop construct for the listeners also be used to make the
calls to the sub-components as well? I.e. having the sub-components
added to the listener set?


Regards,

>
> Regards,
> Kangcheng

From neugens at redhat.com  Mon Aug 26 13:24:34 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 26 Aug 2019 15:24:34 +0200
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
Message-ID: <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>

On Mon, Aug 26, 2019 at 3:16 PM Jie Kang <jkang at redhat.com> wrote:

>
> The thread safety of this construct is concerning. Is it expected to
> only be called by a single thread? If yes, I'd appreciate a comment
> specifying that it is not thread-safe, but it is okay because no more
> than one thread calls this. If no, then I think a lock would be more
> appropriate than a boolean.
>
> Also there is a guard in updateModel() but no guard in reset(); is
> that intentional? Can things go awry if reset occurs while updateModel
> is executing? I guess these kinds of questions need only be considered
> if there is multi-threaded access...
>

I'm not an expert of the Eclipse threading model, but I would be very
surprised if the UI was updated outside the rendering thread, and afaik SWT
does not allow access from multiple thread on its component hierarchy, so I
would rather add a comment if this code was meant to be accessed by
multiple threads since that would be the exception.

Cheers,
Mario



> ##
> +++
> b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/BaseViewer.java
> [...]
> +    public void setHeapSize(long size) {
> +        mHeapSize = size;
> +    }
> +
> +    public long getHeapSize() {
> +        return mHeapSize;
> +    }
>
> I don't see any usages of getHeapSize or of mHeapSize within this
> class. Can they be removed?
>
> ##
> +++
> b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/MemoryStatisticsTab
> leViewer.java
> +class MemoryStatisticsTableViewer extends TableViewer {
> +
> +       private long mHeapSize;
> [...]
> +       MemoryStatisticsTableViewer(Composite parent, int style,
> Function<MemoryStatisticsItem, Color> colorProvider) {
> [...]
> +               createTableColumnViewer("Memory KB",
> +                               model -> String.format("%d (%d%%)",
> model.getMemory() / 1024, model.getMemory() * 100 / mHeapSize),
> [...]
> +       void setHeapSize(long size) {
> +               mHeapSize = size;
> +       }
>
> Is it possible mHeapSize is *not* set via the package private function
> before being used in the label provider created by the constructor? I
> might initialize it to 1 just to prevent a possible NPE.
>
>
> # Section 2: Can be addressed in follow-up JIRA issues + patches, or
> immediately if easily done
>
> ##
> The values displayed are no longer comma separated. For example
> 1234567 instead of 1,234,567. I think comma-separation increases
> readability. If possible could this be added?
>
> ##
> For the colour selection of arcs, some colours blend quite closely
> with each other. While we're here it would be nice to only use
> contrasting colours (rainbow).
>
> ##
> The selection made in the Ancestor Referrer table persists though the
> table contents change after selection. In the jfx version, the table
> is deselected after. To reproduce, use the mouse to select a row in
> the table. After selection, the table contents are changed but the row
> (which has different content) remains selected. I think it's okay to
> deselect after, or better yet, re-select the correct row.
>
> ##
> When loading the same hprof file into JOverflow, some values are off
> by one between the jfx and swt versions. Is it possibly due to
> different rounding in the ui? It looks like the core api for joverflow
> is unchanged. If so, this can probably be ignored. I saw this for
> values in the Ancestor Referrer table.
>
> ##
> +               // FIXME: Bug 165637 - [Viewers]
> ArrayIndexOutOfBoundsException exception in ConcurrentTableUpdator
> (used in DeferredContentProvider)
> +        // https://bugs.eclipse.org/bugs/show_bug.cgi?id=165637
> +               mContentProvider = new DeferredContentProvider((lhs, rhs)
> -> 0);
> [...]
> +                                       // FIXME: Bug 146799 - Blank
> last table item on virtual table
> +                       //
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=146799
>
> Ouch. Did you see these occur in practice? I guess it can be a
> follow-up issue to resolve (probably by replacing with a different
> implementation) but I'd be very reluctant to allow this to sit for any
> length of time.
>
> ##
> +++
> b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
> [...]
> +        mOverheadTypeViewer.setHeapSize(heapSize);
> +        mReferrerViewer.setHeapSize(heapSize);
> +        mClusterGroupViewer.setHeapSize(heapSize);
> +        mAncestorViewer.setHeapSize(heapSize);
> [...]
> +        mReferrerViewer.allIncluded();
> +        mClusterGroupViewer.allIncluded();
> +        mAncestorViewer.allIncluded();
> +        mOverheadTypeViewer.allIncluded();
> +        for (ModelListener l : mModelListeners) {
> +            l.allIncluded();
> +        }
> [...]
> +        mOverheadTypeViewer.reset();
> +        mReferrerViewer.reset();
> +        mClusterGroupViewer.reset();
> +        mAncestorViewer.reset();
>
>
> These duplicate calls for the four sub-components feel sub-optimal,
> especially in the allIncluded calls. Would it be appropriate to have
> the for-loop construct for the listeners also be used to make the
> calls to the sub-components as well? I.e. having the sub-components
> added to the listener set?
>
>
> Regards,
>
> >
> > Regards,
> > Kangcheng
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From neugens at redhat.com  Mon Aug 26 13:30:02 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 26 Aug 2019 15:30:02 +0200
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
Message-ID: <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>

On Mon, Aug 26, 2019 at 3:24 PM Mario Torre <neugens at redhat.com> wrote:
>
>
>
> On Mon, Aug 26, 2019 at 3:16 PM Jie Kang <jkang at redhat.com> wrote:
>>
>>
>> The thread safety of this construct is concerning. Is it expected to
>> only be called by a single thread? If yes, I'd appreciate a comment
>> specifying that it is not thread-safe, but it is okay because no more
>> than one thread calls this. If no, then I think a lock would be more
>> appropriate than a boolean.
>>
>> Also there is a guard in updateModel() but no guard in reset(); is
>> that intentional? Can things go awry if reset occurs while updateModel
>> is executing? I guess these kinds of questions need only be considered
>> if there is multi-threaded access...
>
>
> I'm not an expert of the Eclipse threading model, but I would be very surprised if the UI was updated outside the rendering thread, and afaik SWT does not allow access from multiple thread on its component hierarchy, so I would rather add a comment if this code was meant to be accessed by multiple threads since that would be the exception.

P.S.

In the case where the model is updated externally of the event thread,
you will likely need in the calling code some syncing libraries like
Display.asyncExec (or whatever Eclipse version of invokeLater is).
Indeed, the mIsUpdatingModel throws me off too, since it seems to
imply the view is being update concurrently.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From kxu at redhat.com  Mon Aug 26 13:55:44 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Mon, 26 Aug 2019 09:55:44 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
Message-ID: <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>

Thank you all for reviewing my code.

On Mon, 26 Aug 2019 at 09:30, Mario Torre <neugens at redhat.com> wrote:
>
> On Mon, Aug 26, 2019 at 3:24 PM Mario Torre <neugens at redhat.com> wrote:
> >
> >
> >
> > On Mon, Aug 26, 2019 at 3:16 PM Jie Kang <jkang at redhat.com> wrote:
> >>
> >>
> >> The thread safety of this construct is concerning. Is it expected to
> >> only be called by a single thread? If yes, I'd appreciate a comment
> >> specifying that it is not thread-safe, but it is okay because no more
> >> than one thread calls this. If no, then I think a lock would be more
> >> appropriate than a boolean.
> >>
> >> Also there is a guard in updateModel() but no guard in reset(); is
> >> that intentional? Can things go awry if reset occurs while updateModel
> >> is executing? I guess these kinds of questions need only be considered
> >> if there is multi-threaded access...
> >
> >
> > I'm not an expert of the Eclipse threading model, but I would be very surprised if the UI was updated outside the rendering thread, and afaik SWT does not allow access from multiple thread on its component hierarchy, so I would rather add a comment if this code was meant to be accessed by multiple threads since that would be the exception.

Yes, you are right Mario. updateModel() is only supposed to be called
from the SWT event thread. Any access from outside this thread will
result in a SWTException by its design.

> P.S.
>
> In the case where the model is updated externally of the event thread,
> you will likely need in the calling code some syncing libraries like
> Display.asyncExec (or whatever Eclipse version of invokeLater is).
> Indeed, the mIsUpdatingModel throws me off too, since it seems to
> imply the view is being update concurrently.

While updateModel() is not accessed outside the thread, it's possible
to be called multiple times, before the previous calls finish, from
the SWT event thread. From what I understand, SWT operates on some
kind of event loop design. In the process of updating the UI, it's
possible for some SWT listeners to be invoked and call updateModel()
again. (eg. SelectionListener listener is called when the table
content is updated.) Without this mIsUpdatingModel, it can easily
result in an endless recursion. However, I do agree that guarding with
a boolean is not the most elegant solution. Please let me know if
there is a better approach coming across your mind.

Thank you!
Arvin

> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus.hirt at datadoghq.com  Mon Aug 26 13:58:40 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 26 Aug 2019 15:58:40 +0200
Subject: JMC-6553 Update error message when JFR is not available
In-Reply-To: <CAN4WuHYoQMPV+me7eYJE9aHX8PVedvB=8bn63pvCbiuntUE5Hw@mail.gmail.com>
References: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>
 <1a3e01d559f1$8713a660$953af320$@hirt.se>
 <CAN4WuHYoQMPV+me7eYJE9aHX8PVedvB=8bn63pvCbiuntUE5Hw@mail.gmail.com>
Message-ID: <CAOpWGx0qyHrxKZddMPGjOMdX5K5=q_BySHSyou4meFiu7dwmgQ@mail.gmail.com>

Looks good to me, but I'd like someone from Oracle to weigh in, especially
on the change to JVMSupport_FLIGHT_RECORDER_NOT_ENABLED. Guru?

Kind regards,
Marcus

On Mon, Aug 26, 2019 at 3:11 PM Salman Siddiqui <sasiddiq at redhat.com> wrote:

> Hi Marcus,
>
> Thanks for the correction. Fixed below.
>
> Regards,
> Salman
>
>
> diff -r cc07a1f270e9
>
> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> ---
>
> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>    Mon Aug 19 11:57:12 2019 -0400
> +++
>
> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>    Fri Aug 23 15:29:46 2019 -0400
> @@ -45,7 +45,7 @@
>  JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> unknown JVM. This will most likely not succeed unless you're running the
> JMX Console, and even then functionality will be limited. \n\nAre you sure
> you want to continue?
>  JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
> a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
> you sure you want to continue?
> -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> not recent enough for full functionality in the JMX Console. For full
> functionality you need to connect to a Java 7u40 or later JVM. Do you still
> want to connect?
> +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> not recent enough for full functionality in the JMX Console. For full
> functionality you need to connect to an Oracle JDK 7u40 or later JVM or an
> OpenJDK 11+ JVM. Do you still want to connect?
>  JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> Use a 4.x version of Mission Control when connecting to a JRockit.
>  JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> +54,7 @@
> JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> Recorder is not fully supported for JVMs with Java versions below 7u40
> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not
> supported for non HotSpot JVMs
> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
> is not supported for non HotSpot JVMs
> -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> enabled. To enable this you need to use a Java 7u4 or later JVM started
> with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> enabled. To enable this you need to use an Oracle JDK 7u4 or later JVM
> started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> OpenJDK 11+ JVM.
>  JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
> not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> explicitly disabled. To enable the Flight Recorder, remove
> -XX:-FlightRecorder from the command line.
>  JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> disabled
>
> On Fri, Aug 23, 2019 at 4:30 PM Marcus Hirt <marcus at hirt.se> wrote:
>
> > Hi Salman,
> >
> > I believe the Oracle JDK has a space between Oracle and JDK
> > (as opposed to OpenJDK, which is written together).
> >
> > Kind regards,
> > Marcus
> >
> > -----Ursprungligt meddelande-----
> > Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Salman Siddiqui
> > Skickat: den 23 augusti 2019 21:31
> > Till: jmc-dev at openjdk.java.net
> > ?mne: RFR: JMC-6553 Update error message when JFR is not available
> >
> > Hi all,
> >
> > Please review edit to error message for unavailable JFR below.
> >
> > JIRA: https://bugs.openjdk.java.net/browse/JMC-6553
> >
> > Thanks,
> > Salman
> >
> >
> > diff -r cc07a1f270e9
> >
> >
> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> > ---
> >
> >
> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >    Mon Aug 19 11:57:12 2019 -0400
> > +++
> >
> >
> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >    Fri Aug 23 15:29:46 2019 -0400
> > @@ -45,7 +45,7 @@
> >  JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> > JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> > unknown JVM. This will most likely not succeed unless you're running the
> > JMX Console, and even then functionality will be limited. \n\nAre you
> sure
> > you want to continue?
> >  JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect
> to
> > a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> > Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> > R27. \nIf you connect to a JRockit, functionality will be limited.
> \n\nAre
> > you sure you want to continue?
> > -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> > not recent enough for full functionality in the JMX Console. For full
> > functionality you need to connect to a Java 7u40 or later JVM. Do you
> still
> > want to connect?
> > +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> > not recent enough for full functionality in the JMX Console. For full
> > functionality you need to connect to an OracleJDK 7u40 or later JVM or an
> > OpenJDK 11+ JVM. Do you still want to connect?
> >  JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> > Use a 4.x version of Mission Control when connecting to a JRockit.
> >  JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> > supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> > Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> > +54,7 @@
> > JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> > Recorder is not fully supported for JVMs with Java versions below 7u40
> > JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is
> not
> > supported for non HotSpot JVMs
> > JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight
> Recorder
> > is not supported for non HotSpot JVMs
> > -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> > enabled. To enable this you need to use a Java 7u4 or later JVM started
> > with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> > +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> > enabled. To enable this you need to use an OracleJDK 7u4 or later JVM
> > started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> > OpenJDK 11+ JVM.
> >  JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features
> are
> > not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> > explicitly disabled. To enable the Flight Recorder, remove
> > -XX:-FlightRecorder from the command line.
> >  JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> > disabled
> >
> >
>

From neugens at redhat.com  Mon Aug 26 13:59:09 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 26 Aug 2019 15:59:09 +0200
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
Message-ID: <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>

On Mon, Aug 26, 2019 at 3:56 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:

> While updateModel() is not accessed outside the thread, it's possible
> to be called multiple times, before the previous calls finish, from
> the SWT event thread. From what I understand, SWT operates on some
> kind of event loop design. In the process of updating the UI, it's
> possible for some SWT listeners to be invoked and call updateModel()
> again. (eg. SelectionListener listener is called when the table
> content is updated.) Without this mIsUpdatingModel, it can easily
> result in an endless recursion. However, I do agree that guarding with
> a boolean is not the most elegant solution. Please let me know if
> there is a better approach coming across your mind.

But if the call is synchronous those calls would be queued, not? What
you described seems to imply a multi-thread call.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From guru.hb at oracle.com  Mon Aug 26 14:20:28 2019
From: guru.hb at oracle.com (Guru)
Date: Mon, 26 Aug 2019 19:50:28 +0530
Subject: JMC-6553 Update error message when JFR is not available
In-Reply-To: <CAN4WuHYoQMPV+me7eYJE9aHX8PVedvB=8bn63pvCbiuntUE5Hw@mail.gmail.com>
References: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>
 <1a3e01d559f1$8713a660$953af320$@hirt.se>
 <CAN4WuHYoQMPV+me7eYJE9aHX8PVedvB=8bn63pvCbiuntUE5Hw@mail.gmail.com>
Message-ID: <AAB73856-FC05-4127-8928-46C7A09BE2BE@oracle.com>

Hi Salman,

Changes looks good to me. 

Could it be possible to have any one of below instead of 
> JVMSupport_MESSAGE_NOT_A_KNOWN_JVM : 
JVMSupport_MESSAGE_UNKNOWN_JVM 

> JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE (Any of the below or little better one ) 

JVMSupport_MESSAGE_UN_SUPPORTED_LEGACY_JVM_CONSOLE 
JVMSupport_MESSAGE_LEGACY_JVM_CONSOLE 

Thanks,
Guru
> On 26-Aug-2019, at 6:40 PM, Salman Siddiqui <sasiddiq at redhat.com> wrote:
> 
> Hi Marcus,
> 
> Thanks for the correction. Fixed below.
> 
> Regards,
> Salman
> 
> 
> diff -r cc07a1f270e9
> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> ---
> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>   Mon Aug 19 11:57:12 2019 -0400
> +++
> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>   Fri Aug 23 15:29:46 2019 -0400
> @@ -45,7 +45,7 @@
> JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> unknown JVM. This will most likely not succeed unless you're running the
> JMX Console, and even then functionality will be limited. \n\nAre you sure
> you want to continue?
> JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
> a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
> you sure you want to continue?
> -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> not recent enough for full functionality in the JMX Console. For full
> functionality you need to connect to a Java 7u40 or later JVM. Do you still
> want to connect?
> +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> not recent enough for full functionality in the JMX Console. For full
> functionality you need to connect to an Oracle JDK 7u40 or later JVM or an
> OpenJDK 11+ JVM. Do you still want to connect?
> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> Use a 4.x version of Mission Control when connecting to a JRockit.
> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> +54,7 @@
> JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> Recorder is not fully supported for JVMs with Java versions below 7u40
> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not
> supported for non HotSpot JVMs
> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
> is not supported for non HotSpot JVMs
> -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> enabled. To enable this you need to use a Java 7u4 or later JVM started
> with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> enabled. To enable this you need to use an Oracle JDK 7u4 or later JVM
> started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> OpenJDK 11+ JVM.
> JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
> not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> explicitly disabled. To enable the Flight Recorder, remove
> -XX:-FlightRecorder from the command line.
> JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> disabled
> 
> On Fri, Aug 23, 2019 at 4:30 PM Marcus Hirt <marcus at hirt.se> wrote:
> 
>> Hi Salman,
>> 
>> I believe the Oracle JDK has a space between Oracle and JDK
>> (as opposed to OpenJDK, which is written together).
>> 
>> Kind regards,
>> Marcus
>> 
>> -----Ursprungligt meddelande-----
>> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Salman Siddiqui
>> Skickat: den 23 augusti 2019 21:31
>> Till: jmc-dev at openjdk.java.net
>> ?mne: RFR: JMC-6553 Update error message when JFR is not available
>> 
>> Hi all,
>> 
>> Please review edit to error message for unavailable JFR below.
>> 
>> JIRA: https://bugs.openjdk.java.net/browse/JMC-6553
>> 
>> Thanks,
>> Salman
>> 
>> 
>> diff -r cc07a1f270e9
>> 
>> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>> ---
>> 
>> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>>   Mon Aug 19 11:57:12 2019 -0400
>> +++
>> 
>> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
>>   Fri Aug 23 15:29:46 2019 -0400
>> @@ -45,7 +45,7 @@
>> JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
>> JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
>> unknown JVM. This will most likely not succeed unless you're running the
>> JMX Console, and even then functionality will be limited. \n\nAre you sure
>> you want to continue?
>> JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
>> a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
>> Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
>> R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
>> you sure you want to continue?
>> -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
>> not recent enough for full functionality in the JMX Console. For full
>> functionality you need to connect to a Java 7u40 or later JVM. Do you still
>> want to connect?
>> +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
>> not recent enough for full functionality in the JMX Console. For full
>> functionality you need to connect to an OracleJDK 7u40 or later JVM or an
>> OpenJDK 11+ JVM. Do you still want to connect?
>> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
>> Use a 4.x version of Mission Control when connecting to a JRockit.
>> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
>> supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
>> Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
>> +54,7 @@
>> JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
>> Recorder is not fully supported for JVMs with Java versions below 7u40
>> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not
>> supported for non HotSpot JVMs
>> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
>> is not supported for non HotSpot JVMs
>> -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
>> enabled. To enable this you need to use a Java 7u4 or later JVM started
>> with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
>> +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
>> enabled. To enable this you need to use an OracleJDK 7u4 or later JVM
>> started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
>> OpenJDK 11+ JVM.
>> JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
>> not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
>> explicitly disabled. To enable the Flight Recorder, remove
>> -XX:-FlightRecorder from the command line.
>> JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
>> disabled
>> 
>> 


From kxu at redhat.com  Mon Aug 26 15:16:40 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Mon, 26 Aug 2019 11:16:40 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
Message-ID: <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>

(Replying all. Sorry if you've seen this reply, Mario.)

I'm unsure if those calls are queued or executed right away. I
remembered introducing this guard after I observed multiple updates
caused by single user interaction. However, I took a further look at
the code and experiment a bit. The guard is indeed unnecessary, at
least for the current code.

mIsUpdatingModel and all its usages will be removed.

On Mon, 26 Aug 2019 at 09:59, Mario Torre <neugens at redhat.com> wrote:
>
> On Mon, Aug 26, 2019 at 3:56 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> > While updateModel() is not accessed outside the thread, it's possible
> > to be called multiple times, before the previous calls finish, from
> > the SWT event thread. From what I understand, SWT operates on some
> > kind of event loop design. In the process of updating the UI, it's
> > possible for some SWT listeners to be invoked and call updateModel()
> > again. (eg. SelectionListener listener is called when the table
> > content is updated.) Without this mIsUpdatingModel, it can easily
> > result in an endless recursion. However, I do agree that guarding with
> > a boolean is not the most elegant solution. Please let me know if
> > there is a better approach coming across your mind.
>
> But if the call is synchronous those calls would be queued, not? What
> you described seems to imply a multi-thread call.
>
> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From hdafgard at gmail.com  Mon Aug 26 15:57:08 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Mon, 26 Aug 2019 17:57:08 +0200
Subject: RFR: JMC-6556 JFR V1 Parser memory leak
Message-ID: <CADFkdVTLAghhtah4-Va4F_ZU5g8hdL5iMh9GG3=QDDkh=T91FA@mail.gmail.com>

Hi all,

JIRA: https://bugs.openjdk.java.net/browse/JMC-6556

This fixes a small memory leak where the number of attributes added to a
StructContentType object grows unbounded while recordings are being parsed.

---
a/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
+++
b/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
@@ -116,7 +116,7 @@
  }

  // NOTE: Using constant pool id as identifier.
- private static final Map<Long, StructContentType<Object[]>> STRUCT_TYPES
= new HashMap<>();
+ private final Map<Long, StructContentType<Object[]>> STRUCT_TYPES = new
HashMap<>();

  private class TypeEntry {
  private static final String STRUCT_TYPE_CLASS = "java.lang.Class";
//$NON-NLS-1$


Cheers,
Henrik Dafg?rd

From erik.gahlin at oracle.com  Mon Aug 26 16:31:04 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 26 Aug 2019 18:31:04 +0200
Subject: RFR: JMC-6556 JFR V1 Parser memory leak
In-Reply-To: <CADFkdVTLAghhtah4-Va4F_ZU5g8hdL5iMh9GG3=QDDkh=T91FA@mail.gmail.com>
References: <CADFkdVTLAghhtah4-Va4F_ZU5g8hdL5iMh9GG3=QDDkh=T91FA@mail.gmail.com>
Message-ID: <5D640948.9050604@oracle.com>

Looks good.

Another problem with a static is that type id could differ between 
recordings or attributes could be added to type in a newer release.

As long as you only open one recording per JMC instance you will be 
fine, but pretty high risk it can go wrong if you open multiple 
recordings from different releases.

Erik

> Hi all,
>
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6556
>
> This fixes a small memory leak where the number of attributes added to a
> StructContentType object grows unbounded while recordings are being parsed.
>
> ---
> a/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
> +++
> b/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
> @@ -116,7 +116,7 @@
>    }
>
>    // NOTE: Using constant pool id as identifier.
> - private static final Map<Long, StructContentType<Object[]>> STRUCT_TYPES
> = new HashMap<>();
> + private final Map<Long, StructContentType<Object[]>> STRUCT_TYPES = new
> HashMap<>();
>
>    private class TypeEntry {
>    private static final String STRUCT_TYPE_CLASS = "java.lang.Class";
> //$NON-NLS-1$
>
>
> Cheers,
> Henrik Dafg?rd


From kxu at redhat.com  Mon Aug 26 18:37:10 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Mon, 26 Aug 2019 14:37:10 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
Message-ID: <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>

On Mon, 26 Aug 2019 at 14:36, Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> On Mon, 26 Aug 2019 at 09:15, Jie Kang <jkang at redhat.com> wrote:
> >
> > On Wed, Aug 21, 2019 at 10:41 AM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> > >
> > > Hello all,
> > >
> > > This change aims to port JOverflow from using JavaFX to SWT/JFace, so
> > > the extra dependencies could be dropped. Additionally, this change
> > > makes JMC-6343 is no longer valid.
> > >
> > > This port (re)implements all features available in the original
> > > version, and UI design is kept as close as possible. Please let me
> > > know your thoughts. Thank you very much!
> > >
> > > Also, thanks Jie for creating this webrev for me!
> > >
> > > Webrev:
> > > https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.01/
> > > Bug:
> > > https://bugs.openjdk.java.net/browse/JMC-6555
> >
> > Hey Arvin,
> >
> > Overall nice work! Visually and functionally (minor manual testing) it
> > looks to be working quite nicely. I have some comments and nits below,
> > separated in two sections. The nits in the second section can be
> > addressed in follow-up JIRA issues + patches.
> >
> > # Section One
> >
> > ##
> > +import org.eclipse.swt.widgets.*;
> >
> > There are a number of imports of x.y.* packages. Are all the classes
> > from these required? If not I would use individual imports. This makes
> > it easier to see exactly what package a class comes form.
>
> I agree. All wildcard imports will be replaced with single class imports.
>
> > ##
> > With the removal of openjfx, it looks like org.openjdk.jmc.javafx.osgi
> > is no longer used. Can this be removed as well? As well, can the
> > javafx dependencies defined in the p2 repository and set in the target
> > platform files also be removed?
>
> I only removed jfx related dependencies within the joverflow component itself and left the global ones untouched. Are there other dependents preventing us from removing jfx completely? If no further discussions are needed, I'll be happy to remove those, too.
>
> > ##
> > There are various instances of whitespace being included for newlines.
> > Please try to remove these, probably most easily done with an
> > auto-formatting tool. For what it's worth, in my terminal, invocations
> > of `hg diff` shows these as big blocks of red. Also it seems some
> > files use tabs and others use spaces. I think all should be switched
> > to tabs for this project.
>
> I will adjust my auto-format setting and reformat.
>
> > ##
> > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
> > +    private boolean mIsUpdatingModel;
> > [...]
> > +    private void updateModel() {
> > +        if (mIsUpdatingModel) {
> > +            // skip updating if busy
> > +            return;
> > +        }
> > +
> > +        mIsUpdatingModel = true;
> > [...]
> > +        mIsUpdatingModel = false;
> > +    }
> > +
> > +    void reset() {
> > +        mIsUpdatingModel = true;
> > [...]
> > +        mIsUpdatingModel = false;
> > [...]
> >
> > The thread safety of this construct is concerning. Is it expected to
> > only be called by a single thread? If yes, I'd appreciate a comment
> > specifying that it is not thread-safe, but it is okay because no more
> > than one thread calls this. If no, then I think a lock would be more
> > appropriate than a boolean.
> >
> > Also there is a guard in updateModel() but no guard in reset(); is
> > that intentional? Can things go awry if reset occurs while updateModel
> > is executing? I guess these kinds of questions need only be considered
> > if there is multi-threaded access...
>
> This is addressed in another email thread. mIsUpdatingModel is to be removed.
>
> > ##
> > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/BaseViewer.java
> > [...]
> > +    public void setHeapSize(long size) {
> > +        mHeapSize = size;
> > +    }
> > +
> > +    public long getHeapSize() {
> > +        return mHeapSize;
> > +    }
> >
> > I don't see any usages of getHeapSize or of mHeapSize within this
> > class. Can they be removed?
>
> Yes. getHeapSize and mHeapSize will be removed. setHeapSize will be declared abstract.
>
> > ##
> > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/MemoryStatisticsTab
> > leViewer.java
> > +class MemoryStatisticsTableViewer extends TableViewer {
> > +
> > +       private long mHeapSize;
> > [...]
> > +       MemoryStatisticsTableViewer(Composite parent, int style,
> > Function<MemoryStatisticsItem, Color> colorProvider) {
> > [...]
> > +               createTableColumnViewer("Memory KB",
> > +                               model -> String.format("%d (%d%%)",
> > model.getMemory() / 1024, model.getMemory() * 100 / mHeapSize),
> > [...]
> > +       void setHeapSize(long size) {
> > +               mHeapSize = size;
> > +       }
> >
> > Is it possible mHeapSize is *not* set via the package private function
> > before being used in the label provider created by the constructor? I
> > might initialize it to 1 just to prevent a possible NPE.
>
> I'm not aware of a better solution at this moment, but I'll initialize it to 1 to avoid ArithmeticException.
>
> > # Section 2: Can be addressed in follow-up JIRA issues + patches, or
> > immediately if easily done
> >
> > ##
> > The values displayed are no longer comma separated. For example
> > 1234567 instead of 1,234,567. I think comma-separation increases
> > readability. If possible could this be added?
>
> This should be an easy fix. Comma-separation will be implemented in the next update.
>
> > ##
> > For the colour selection of arcs, some colours blend quite closely
> > with each other. While we're here it would be nice to only use
> > contrasting colours (rainbow).
>
> Right now the colours are random. There is no colour palette since there is no telling how many colours are needed. I'll study the original implementation and see how it was handled.
>
> > ##
> > The selection made in the Ancestor Referrer table persists though the
> > table contents change after selection. In the jfx version, the table
> > is deselected after. To reproduce, use the mouse to select a row in
> > the table. After selection, the table contents are changed but the row
> > (which has different content) remains selected. I think it's okay to
> > deselect after, or better yet, re-select the correct row.
>
> This is interesting and I can't provide an explanation of why it is happening at this moment. I'll look into this afterwards.
>
> > ##
> > When loading the same hprof file into JOverflow, some values are off
> > by one between the jfx and swt versions. Is it possibly due to
> > different rounding in the ui? It looks like the core api for joverflow
> > is unchanged. If so, this can probably be ignored. I saw this for
> > values in the Ancestor Referrer table.
>
> Yes, it is a difference in rounding. When converting from B to KB, the jfx version rounds and the swt version truncates. I'll change it to rounding.
>
> Also, do you think it's worth to change "KB" to the more accurate "KiB"?
>
> > ##
> > +               // FIXME: Bug 165637 - [Viewers]
> > ArrayIndexOutOfBoundsException exception in ConcurrentTableUpdator
> > (used in DeferredContentProvider)
> > +        // https://bugs.eclipse.org/bugs/show_bug.cgi?id=165637
> > +               mContentProvider = new DeferredContentProvider((lhs, rhs) -> 0);
> > [...]
> > +                                       // FIXME: Bug 146799 - Blank
> > last table item on virtual table
> > +                       // https://bugs.eclipse.org/bugs/show_bug.cgi?id=146799
> >
> > Ouch. Did you see these occur in practice? I guess it can be a
> > follow-up issue to resolve (probably by replacing with a different
> > implementation) but I'd be very reluctant to allow this to sit for any
> > length of time.
>
> Yes. I've seen this occasionally. DeferredContentProvider looks quite fragile [0].
> However, virtual tables with an ILazyContentProvider is a must for this application since there are just too many entries. In theory, we can implement our own ILazyContentProvider that also does filtering and sorting like DeferredContentProvider, but what will be quite some work which deserves a follow-up.
>
> > ##
> > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
> > [...]
> > +        mOverheadTypeViewer.setHeapSize(heapSize);
> > +        mReferrerViewer.setHeapSize(heapSize);
> > +        mClusterGroupViewer.setHeapSize(heapSize);
> > +        mAncestorViewer.setHeapSize(heapSize);
> > [...]
> > +        mReferrerViewer.allIncluded();
> > +        mClusterGroupViewer.allIncluded();
> > +        mAncestorViewer.allIncluded();
> > +        mOverheadTypeViewer.allIncluded();
> > +        for (ModelListener l : mModelListeners) {
> > +            l.allIncluded();
> > +        }
> > [...]
> > +        mOverheadTypeViewer.reset();
> > +        mReferrerViewer.reset();
> > +        mClusterGroupViewer.reset();
> > +        mAncestorViewer.reset();
> >
> >
> > These duplicate calls for the four sub-components feel sub-optimal,
> > especially in the allIncluded calls. Would it be appropriate to have
> > the for-loop construct for the listeners also be used to make the
> > calls to the sub-components as well? I.e. having the sub-components
> > added to the listener set?
>
> Correct me if I'm wrong. Are you suggesting something like this?
>
> List<ModelListener> tmp = new ArrayList<>(mModelListeners);
> tmp.addAll(Arrays.asList(mReferrerViewer, mClusterGroupViewer, mAncestorViewer, mOverheadTypeViewer));
> for (ModelListener l : tmp) {
>     l.allIncluded();
> }
>
> Regards,
> Arvin
>
> [0] https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=509006&hide_resolved=1
> >
> > Regards,
> >
> > >
> > > Regards,
> > > Kangcheng

From jkang at redhat.com  Mon Aug 26 19:32:10 2019
From: jkang at redhat.com (Jie Kang)
Date: Mon, 26 Aug 2019 15:32:10 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
 <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>
Message-ID: <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>

On Mon, Aug 26, 2019 at 2:37 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> On Mon, 26 Aug 2019 at 14:36, Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> >
> > On Mon, 26 Aug 2019 at 09:15, Jie Kang <jkang at redhat.com> wrote:
> > >
> > > On Wed, Aug 21, 2019 at 10:41 AM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> > > >
> > > > Hello all,
> > > >
> > > > This change aims to port JOverflow from using JavaFX to SWT/JFace, so
> > > > the extra dependencies could be dropped. Additionally, this change
> > > > makes JMC-6343 is no longer valid.
> > > >
> > > > This port (re)implements all features available in the original
> > > > version, and UI design is kept as close as possible. Please let me
> > > > know your thoughts. Thank you very much!
> > > >
> > > > Also, thanks Jie for creating this webrev for me!
> > > >
> > > > Webrev:
> > > > https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.01/
> > > > Bug:
> > > > https://bugs.openjdk.java.net/browse/JMC-6555
> > >
> > > Hey Arvin,
> > >
> > > Overall nice work! Visually and functionally (minor manual testing) it
> > > looks to be working quite nicely. I have some comments and nits below,
> > > separated in two sections. The nits in the second section can be
> > > addressed in follow-up JIRA issues + patches.
> > >
> > > # Section One
> > >
> > > ##
> > > +import org.eclipse.swt.widgets.*;
> > >
> > > There are a number of imports of x.y.* packages. Are all the classes
> > > from these required? If not I would use individual imports. This makes
> > > it easier to see exactly what package a class comes form.
> >
> > I agree. All wildcard imports will be replaced with single class imports.
> >
> > > ##
> > > With the removal of openjfx, it looks like org.openjdk.jmc.javafx.osgi
> > > is no longer used. Can this be removed as well? As well, can the
> > > javafx dependencies defined in the p2 repository and set in the target
> > > platform files also be removed?
> >
> > I only removed jfx related dependencies within the joverflow component itself and left the global ones untouched. Are there other dependents preventing us from removing jfx completely? If no further discussions are needed, I'll be happy to remove those, too.

I think they can be removed safely and should be.

> >
> > > ##
> > > There are various instances of whitespace being included for newlines.
> > > Please try to remove these, probably most easily done with an
> > > auto-formatting tool. For what it's worth, in my terminal, invocations
> > > of `hg diff` shows these as big blocks of red. Also it seems some
> > > files use tabs and others use spaces. I think all should be switched
> > > to tabs for this project.
> >
> > I will adjust my auto-format setting and reformat.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
> > > +    private boolean mIsUpdatingModel;
> > > [...]
> > > +    private void updateModel() {
> > > +        if (mIsUpdatingModel) {
> > > +            // skip updating if busy
> > > +            return;
> > > +        }
> > > +
> > > +        mIsUpdatingModel = true;
> > > [...]
> > > +        mIsUpdatingModel = false;
> > > +    }
> > > +
> > > +    void reset() {
> > > +        mIsUpdatingModel = true;
> > > [...]
> > > +        mIsUpdatingModel = false;
> > > [...]
> > >
> > > The thread safety of this construct is concerning. Is it expected to
> > > only be called by a single thread? If yes, I'd appreciate a comment
> > > specifying that it is not thread-safe, but it is okay because no more
> > > than one thread calls this. If no, then I think a lock would be more
> > > appropriate than a boolean.
> > >
> > > Also there is a guard in updateModel() but no guard in reset(); is
> > > that intentional? Can things go awry if reset occurs while updateModel
> > > is executing? I guess these kinds of questions need only be considered
> > > if there is multi-threaded access...
> >
> > This is addressed in another email thread. mIsUpdatingModel is to be removed.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/BaseViewer.java
> > > [...]
> > > +    public void setHeapSize(long size) {
> > > +        mHeapSize = size;
> > > +    }
> > > +
> > > +    public long getHeapSize() {
> > > +        return mHeapSize;
> > > +    }
> > >
> > > I don't see any usages of getHeapSize or of mHeapSize within this
> > > class. Can they be removed?
> >
> > Yes. getHeapSize and mHeapSize will be removed. setHeapSize will be declared abstract.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/MemoryStatisticsTab
> > > leViewer.java
> > > +class MemoryStatisticsTableViewer extends TableViewer {
> > > +
> > > +       private long mHeapSize;
> > > [...]
> > > +       MemoryStatisticsTableViewer(Composite parent, int style,
> > > Function<MemoryStatisticsItem, Color> colorProvider) {
> > > [...]
> > > +               createTableColumnViewer("Memory KB",
> > > +                               model -> String.format("%d (%d%%)",
> > > model.getMemory() / 1024, model.getMemory() * 100 / mHeapSize),
> > > [...]
> > > +       void setHeapSize(long size) {
> > > +               mHeapSize = size;
> > > +       }
> > >
> > > Is it possible mHeapSize is *not* set via the package private function
> > > before being used in the label provider created by the constructor? I
> > > might initialize it to 1 just to prevent a possible NPE.
> >
> > I'm not aware of a better solution at this moment, but I'll initialize it to 1 to avoid ArithmeticException.
> >
> > > # Section 2: Can be addressed in follow-up JIRA issues + patches, or
> > > immediately if easily done
> > >
> > > ##
> > > The values displayed are no longer comma separated. For example
> > > 1234567 instead of 1,234,567. I think comma-separation increases
> > > readability. If possible could this be added?
> >
> > This should be an easy fix. Comma-separation will be implemented in the next update.
> >
> > > ##
> > > For the colour selection of arcs, some colours blend quite closely
> > > with each other. While we're here it would be nice to only use
> > > contrasting colours (rainbow).
> >
> > Right now the colours are random. There is no colour palette since there is no telling how many colours are needed. I'll study the original implementation and see how it was handled.
> >
> > > ##
> > > The selection made in the Ancestor Referrer table persists though the
> > > table contents change after selection. In the jfx version, the table
> > > is deselected after. To reproduce, use the mouse to select a row in
> > > the table. After selection, the table contents are changed but the row
> > > (which has different content) remains selected. I think it's okay to
> > > deselect after, or better yet, re-select the correct row.
> >
> > This is interesting and I can't provide an explanation of why it is happening at this moment. I'll look into this afterwards.

My text explanation may have been confusing but yeah sounds good to
look at it later.

> >
> > > ##
> > > When loading the same hprof file into JOverflow, some values are off
> > > by one between the jfx and swt versions. Is it possibly due to
> > > different rounding in the ui? It looks like the core api for joverflow
> > > is unchanged. If so, this can probably be ignored. I saw this for
> > > values in the Ancestor Referrer table.
> >
> > Yes, it is a difference in rounding. When converting from B to KB, the jfx version rounds and the swt version truncates. I'll change it to rounding.
> >
> > Also, do you think it's worth to change "KB" to the more accurate "KiB"?

I'd would follow whatever is done elsewhere in the project. Not sure
what you mean by more accurate though; my understanding from [1] KB ==
KiB != kB

[1] https://en.wikipedia.org/wiki/Kibibyte

> >
> > > ##
> > > +               // FIXME: Bug 165637 - [Viewers]
> > > ArrayIndexOutOfBoundsException exception in ConcurrentTableUpdator
> > > (used in DeferredContentProvider)
> > > +        // https://bugs.eclipse.org/bugs/show_bug.cgi?id=165637
> > > +               mContentProvider = new DeferredContentProvider((lhs, rhs) -> 0);
> > > [...]
> > > +                                       // FIXME: Bug 146799 - Blank
> > > last table item on virtual table
> > > +                       // https://bugs.eclipse.org/bugs/show_bug.cgi?id=146799
> > >
> > > Ouch. Did you see these occur in practice? I guess it can be a
> > > follow-up issue to resolve (probably by replacing with a different
> > > implementation) but I'd be very reluctant to allow this to sit for any
> > > length of time.
> >
> > Yes. I've seen this occasionally. DeferredContentProvider looks quite fragile [0].
> > However, virtual tables with an ILazyContentProvider is a must for this application since there are just too many entries. In theory, we can implement our own ILazyContentProvider that also does filtering and sorting like DeferredContentProvider, but what will be quite some work which deserves a follow-up.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
> > > [...]
> > > +        mOverheadTypeViewer.setHeapSize(heapSize);
> > > +        mReferrerViewer.setHeapSize(heapSize);
> > > +        mClusterGroupViewer.setHeapSize(heapSize);
> > > +        mAncestorViewer.setHeapSize(heapSize);
> > > [...]
> > > +        mReferrerViewer.allIncluded();
> > > +        mClusterGroupViewer.allIncluded();
> > > +        mAncestorViewer.allIncluded();
> > > +        mOverheadTypeViewer.allIncluded();
> > > +        for (ModelListener l : mModelListeners) {
> > > +            l.allIncluded();
> > > +        }
> > > [...]
> > > +        mOverheadTypeViewer.reset();
> > > +        mReferrerViewer.reset();
> > > +        mClusterGroupViewer.reset();
> > > +        mAncestorViewer.reset();
> > >
> > >
> > > These duplicate calls for the four sub-components feel sub-optimal,
> > > especially in the allIncluded calls. Would it be appropriate to have
> > > the for-loop construct for the listeners also be used to make the
> > > calls to the sub-components as well? I.e. having the sub-components
> > > added to the listener set?
> >
> > Correct me if I'm wrong. Are you suggesting something like this?
> >
> > List<ModelListener> tmp = new ArrayList<>(mModelListeners);
> > tmp.addAll(Arrays.asList(mReferrerViewer, mClusterGroupViewer, mAncestorViewer, mOverheadTypeViewer));
> > for (ModelListener l : tmp) {
> >     l.allIncluded();
> > }

Er; I mean to say that the viewers can add themselves, or be added to
the listener array that already exists and the listener could be
expanded to also signal reset and heap size changed. So in the
constructor you could run:

mModelListeners.addAll(Arrays.asList(mReferrerViewer,
mClusterGroupViewer, mAncestorViewer, mOverheadTypeViewer));

You can see something like this in the previous JOverflowFxUi, though
they chose (on purpose I suppose?) not to add one of the viewers. Not
sure if you need to follow them exactly though.


Regards,

> >
> > Regards,
> > Arvin
> >
> > [0] https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=509006&hide_resolved=1
> > >
> > > Regards,
> > >
> > > >
> > > > Regards,
> > > > Kangcheng

From sasiddiq at redhat.com  Mon Aug 26 19:52:39 2019
From: sasiddiq at redhat.com (Salman Siddiqui)
Date: Mon, 26 Aug 2019 15:52:39 -0400
Subject: JMC-6553 Update error message when JFR is not available
In-Reply-To: <AAB73856-FC05-4127-8928-46C7A09BE2BE@oracle.com>
References: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>
 <1a3e01d559f1$8713a660$953af320$@hirt.se>
 <CAN4WuHYoQMPV+me7eYJE9aHX8PVedvB=8bn63pvCbiuntUE5Hw@mail.gmail.com>
 <AAB73856-FC05-4127-8928-46C7A09BE2BE@oracle.com>
Message-ID: <CAN4WuHa=Thcb8Yk6b4_CuNbGupLM_B7t8CZG546Tt1e_7=vHsA@mail.gmail.com>

Hey Guru,

Thanks for taking a look.
I've changed the following:
* JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE -->
JVMSupport_TITLE_LEGACY_JVM_CONSOLE
* JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE -->
JVMSupport_MESSAGE_LEGACY_JVM_CONSOLE
* JVMSupport_TITLE_NOT_A_KNOWN_JVM --> JVMSupport_TITLE_UNKNOWN_JVM
* JVMSupport_MESSAGE_NOT_A_KNOWN_JVM --> JVMSupport_MESSAGE_UNKNOWN_JVM
* JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED -->
JVMSupport_JROCKIT_NO_LONGER_SUPPORTED
* JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT -->
JVMSupport_JROCKIT_NO_LONGER_SUPPORTED_SHORT

Please see changes in webrev.

https://cr.openjdk.java.net/~aptmac/JMC-6553/webrev.01/

Thanks,
Salman

On Mon, Aug 26, 2019 at 10:20 AM Guru <guru.hb at oracle.com> wrote:

> Hi Salman,
>
> Changes looks good to me.
>
> Could it be possible to have any one of below instead of
> > JVMSupport_MESSAGE_NOT_A_KNOWN_JVM :
> JVMSupport_MESSAGE_UNKNOWN_JVM
>
> > JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE (Any of the below or little
> better one )
>
> JVMSupport_MESSAGE_UN_SUPPORTED_LEGACY_JVM_CONSOLE
> JVMSupport_MESSAGE_LEGACY_JVM_CONSOLE
>
> Thanks,
> Guru
> > On 26-Aug-2019, at 6:40 PM, Salman Siddiqui <sasiddiq at redhat.com> wrote:
> >
> > Hi Marcus,
> >
> > Thanks for the correction. Fixed below.
> >
> > Regards,
> > Salman
> >
> >
> > diff -r cc07a1f270e9
> >
> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> > ---
> >
> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >   Mon Aug 19 11:57:12 2019 -0400
> > +++
> >
> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >   Fri Aug 23 15:29:46 2019 -0400
> > @@ -45,7 +45,7 @@
> > JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> > JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> > unknown JVM. This will most likely not succeed unless you're running the
> > JMX Console, and even then functionality will be limited. \n\nAre you
> sure
> > you want to continue?
> > JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
> > a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> > Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> > R27. \nIf you connect to a JRockit, functionality will be limited.
> \n\nAre
> > you sure you want to continue?
> > -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> > not recent enough for full functionality in the JMX Console. For full
> > functionality you need to connect to a Java 7u40 or later JVM. Do you
> still
> > want to connect?
> > +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> > not recent enough for full functionality in the JMX Console. For full
> > functionality you need to connect to an Oracle JDK 7u40 or later JVM or
> an
> > OpenJDK 11+ JVM. Do you still want to connect?
> > JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> > Use a 4.x version of Mission Control when connecting to a JRockit.
> > JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> > supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> > Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> > +54,7 @@
> > JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> > Recorder is not fully supported for JVMs with Java versions below 7u40
> > JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is
> not
> > supported for non HotSpot JVMs
> > JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight
> Recorder
> > is not supported for non HotSpot JVMs
> > -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> > enabled. To enable this you need to use a Java 7u4 or later JVM started
> > with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> > +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> > enabled. To enable this you need to use an Oracle JDK 7u4 or later JVM
> > started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> > OpenJDK 11+ JVM.
> > JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
> > not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> > explicitly disabled. To enable the Flight Recorder, remove
> > -XX:-FlightRecorder from the command line.
> > JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> > disabled
> >
> > On Fri, Aug 23, 2019 at 4:30 PM Marcus Hirt <marcus at hirt.se> wrote:
> >
> >> Hi Salman,
> >>
> >> I believe the Oracle JDK has a space between Oracle and JDK
> >> (as opposed to OpenJDK, which is written together).
> >>
> >> Kind regards,
> >> Marcus
> >>
> >> -----Ursprungligt meddelande-----
> >> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Salman Siddiqui
> >> Skickat: den 23 augusti 2019 21:31
> >> Till: jmc-dev at openjdk.java.net
> >> ?mne: RFR: JMC-6553 Update error message when JFR is not available
> >>
> >> Hi all,
> >>
> >> Please review edit to error message for unavailable JFR below.
> >>
> >> JIRA: https://bugs.openjdk.java.net/browse/JMC-6553
> >>
> >> Thanks,
> >> Salman
> >>
> >>
> >> diff -r cc07a1f270e9
> >>
> >>
> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >> ---
> >>
> >>
> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >>   Mon Aug 19 11:57:12 2019 -0400
> >> +++
> >>
> >>
> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >>   Fri Aug 23 15:29:46 2019 -0400
> >> @@ -45,7 +45,7 @@
> >> JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> >> JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> >> unknown JVM. This will most likely not succeed unless you're running the
> >> JMX Console, and even then functionality will be limited. \n\nAre you
> sure
> >> you want to continue?
> >> JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect
> to
> >> a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> >> Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> >> R27. \nIf you connect to a JRockit, functionality will be limited.
> \n\nAre
> >> you sure you want to continue?
> >> -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> >> not recent enough for full functionality in the JMX Console. For full
> >> functionality you need to connect to a Java 7u40 or later JVM. Do you
> still
> >> want to connect?
> >> +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> >> not recent enough for full functionality in the JMX Console. For full
> >> functionality you need to connect to an OracleJDK 7u40 or later JVM or
> an
> >> OpenJDK 11+ JVM. Do you still want to connect?
> >> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> >> Use a 4.x version of Mission Control when connecting to a JRockit.
> >> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> >> supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> >> Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> >> +54,7 @@
> >> JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> >> Recorder is not fully supported for JVMs with Java versions below 7u40
> >> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is
> not
> >> supported for non HotSpot JVMs
> >> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight
> Recorder
> >> is not supported for non HotSpot JVMs
> >> -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> >> enabled. To enable this you need to use a Java 7u4 or later JVM started
> >> with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> >> +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> >> enabled. To enable this you need to use an OracleJDK 7u4 or later JVM
> >> started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> >> OpenJDK 11+ JVM.
> >> JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features
> are
> >> not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> >> explicitly disabled. To enable the Flight Recorder, remove
> >> -XX:-FlightRecorder from the command line.
> >> JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> >> disabled
> >>
> >>
>
>

From kxu at redhat.com  Mon Aug 26 20:56:52 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Mon, 26 Aug 2019 16:56:52 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
 <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>
 <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>
Message-ID: <CA+tA26t+t9TGxgamF+LghypBYKX3tT4QRKEjQDYVWgvK_KWeKg@mail.gmail.com>

On Mon, 26 Aug 2019 at 15:32, Jie Kang <jkang at redhat.com> wrote:
>
> On Mon, Aug 26, 2019 at 2:37 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> >
> > On Mon, 26 Aug 2019 at 14:36, Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> > >
> > > On Mon, 26 Aug 2019 at 09:15, Jie Kang <jkang at redhat.com> wrote:
> > > >
> > > > On Wed, Aug 21, 2019 at 10:41 AM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> > > > >
> > > > > Hello all,
> > > > >
> > > > > This change aims to port JOverflow from using JavaFX to SWT/JFace, so
> > > > > the extra dependencies could be dropped. Additionally, this change
> > > > > makes JMC-6343 is no longer valid.
> > > > >
> > > > > This port (re)implements all features available in the original
> > > > > version, and UI design is kept as close as possible. Please let me
> > > > > know your thoughts. Thank you very much!
> > > > >
> > > > > Also, thanks Jie for creating this webrev for me!
> > > > >
> > > > > Webrev:
> > > > > https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.01/
> > > > > Bug:
> > > > > https://bugs.openjdk.java.net/browse/JMC-6555
> > > >
> > > > Hey Arvin,
> > > >
> > > > Overall nice work! Visually and functionally (minor manual testing) it
> > > > looks to be working quite nicely. I have some comments and nits below,
> > > > separated in two sections. The nits in the second section can be
> > > > addressed in follow-up JIRA issues + patches.
> > > >
> > > > # Section One
> > > >
> > > > ##
> > > > +import org.eclipse.swt.widgets.*;
> > > >
> > > > There are a number of imports of x.y.* packages. Are all the classes
> > > > from these required? If not I would use individual imports. This makes
> > > > it easier to see exactly what package a class comes form.
> > >
> > > I agree. All wildcard imports will be replaced with single class imports.
> > >
> > > > ##
> > > > With the removal of openjfx, it looks like org.openjdk.jmc.javafx.osgi
> > > > is no longer used. Can this be removed as well? As well, can the
> > > > javafx dependencies defined in the p2 repository and set in the target
> > > > platform files also be removed?
> > >
> > > I only removed jfx related dependencies within the joverflow component itself and left the global ones untouched. Are there other dependents preventing us from removing jfx completely? If no further discussions are needed, I'll be happy to remove those, too.
>
> I think they can be removed safely and should be.
No problem. Will remove in my next updated patch.
> > >
> > > > ##
> > > > There are various instances of whitespace being included for newlines.
> > > > Please try to remove these, probably most easily done with an
> > > > auto-formatting tool. For what it's worth, in my terminal, invocations
> > > > of `hg diff` shows these as big blocks of red. Also it seems some
> > > > files use tabs and others use spaces. I think all should be switched
> > > > to tabs for this project.
> > >
> > > I will adjust my auto-format setting and reformat.
> > >
> > > > ##
> > > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
> > > > +    private boolean mIsUpdatingModel;
> > > > [...]
> > > > +    private void updateModel() {
> > > > +        if (mIsUpdatingModel) {
> > > > +            // skip updating if busy
> > > > +            return;
> > > > +        }
> > > > +
> > > > +        mIsUpdatingModel = true;
> > > > [...]
> > > > +        mIsUpdatingModel = false;
> > > > +    }
> > > > +
> > > > +    void reset() {
> > > > +        mIsUpdatingModel = true;
> > > > [...]
> > > > +        mIsUpdatingModel = false;
> > > > [...]
> > > >
> > > > The thread safety of this construct is concerning. Is it expected to
> > > > only be called by a single thread? If yes, I'd appreciate a comment
> > > > specifying that it is not thread-safe, but it is okay because no more
> > > > than one thread calls this. If no, then I think a lock would be more
> > > > appropriate than a boolean.
> > > >
> > > > Also there is a guard in updateModel() but no guard in reset(); is
> > > > that intentional? Can things go awry if reset occurs while updateModel
> > > > is executing? I guess these kinds of questions need only be considered
> > > > if there is multi-threaded access...
> > >
> > > This is addressed in another email thread. mIsUpdatingModel is to be removed.
> > >
> > > > ##
> > > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/BaseViewer.java
> > > > [...]
> > > > +    public void setHeapSize(long size) {
> > > > +        mHeapSize = size;
> > > > +    }
> > > > +
> > > > +    public long getHeapSize() {
> > > > +        return mHeapSize;
> > > > +    }
> > > >
> > > > I don't see any usages of getHeapSize or of mHeapSize within this
> > > > class. Can they be removed?
> > >
> > > Yes. getHeapSize and mHeapSize will be removed. setHeapSize will be declared abstract.
> > >
> > > > ##
> > > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/viewers/MemoryStatisticsTab
> > > > leViewer.java
> > > > +class MemoryStatisticsTableViewer extends TableViewer {
> > > > +
> > > > +       private long mHeapSize;
> > > > [...]
> > > > +       MemoryStatisticsTableViewer(Composite parent, int style,
> > > > Function<MemoryStatisticsItem, Color> colorProvider) {
> > > > [...]
> > > > +               createTableColumnViewer("Memory KB",
> > > > +                               model -> String.format("%d (%d%%)",
> > > > model.getMemory() / 1024, model.getMemory() * 100 / mHeapSize),
> > > > [...]
> > > > +       void setHeapSize(long size) {
> > > > +               mHeapSize = size;
> > > > +       }
> > > >
> > > > Is it possible mHeapSize is *not* set via the package private function
> > > > before being used in the label provider created by the constructor? I
> > > > might initialize it to 1 just to prevent a possible NPE.
> > >
> > > I'm not aware of a better solution at this moment, but I'll initialize it to 1 to avoid ArithmeticException.
> > >
> > > > # Section 2: Can be addressed in follow-up JIRA issues + patches, or
> > > > immediately if easily done
> > > >
> > > > ##
> > > > The values displayed are no longer comma separated. For example
> > > > 1234567 instead of 1,234,567. I think comma-separation increases
> > > > readability. If possible could this be added?
> > >
> > > This should be an easy fix. Comma-separation will be implemented in the next update.
> > >
> > > > ##
> > > > For the colour selection of arcs, some colours blend quite closely
> > > > with each other. While we're here it would be nice to only use
> > > > contrasting colours (rainbow).
> > >
> > > Right now the colours are random. There is no colour palette since there is no telling how many colours are needed. I'll study the original implementation and see how it was handled.
> > >
> > > > ##
> > > > The selection made in the Ancestor Referrer table persists though the
> > > > table contents change after selection. In the jfx version, the table
> > > > is deselected after. To reproduce, use the mouse to select a row in
> > > > the table. After selection, the table contents are changed but the row
> > > > (which has different content) remains selected. I think it's okay to
> > > > deselect after, or better yet, re-select the correct row.
> > >
> > > This is interesting and I can't provide an explanation of why it is happening at this moment. I'll look into this afterwards.
>
> My text explanation may have been confusing but yeah sounds good to
> look at it later.
It seems like JFace would not handle these selection updates if using
ILazyContentProvider (which DeferredContentProvider implements). Could
this potentially be a part of the follow-up issue where we replace
DeferredContentProvider with something else?
> > >
> > > > ##
> > > > When loading the same hprof file into JOverflow, some values are off
> > > > by one between the jfx and swt versions. Is it possibly due to
> > > > different rounding in the ui? It looks like the core api for joverflow
> > > > is unchanged. If so, this can probably be ignored. I saw this for
> > > > values in the Ancestor Referrer table.
> > >
> > > Yes, it is a difference in rounding. When converting from B to KB, the jfx version rounds and the swt version truncates. I'll change it to rounding.
> > >
> > > Also, do you think it's worth to change "KB" to the more accurate "KiB"?
>
> I'd would follow whatever is done elsewhere in the project. Not sure
> what you mean by more accurate though; my understanding from [1] KB ==
> KiB != kB
>
> [1] https://en.wikipedia.org/wiki/Kibibyte
>
I see. I'll leave it unchanged. Thank you for correcting me.
> > >
> > > > ##
> > > > +               // FIXME: Bug 165637 - [Viewers]
> > > > ArrayIndexOutOfBoundsException exception in ConcurrentTableUpdator
> > > > (used in DeferredContentProvider)
> > > > +        // https://bugs.eclipse.org/bugs/show_bug.cgi?id=165637
> > > > +               mContentProvider = new DeferredContentProvider((lhs, rhs) -> 0);
> > > > [...]
> > > > +                                       // FIXME: Bug 146799 - Blank
> > > > last table item on virtual table
> > > > +                       // https://bugs.eclipse.org/bugs/show_bug.cgi?id=146799
> > > >
> > > > Ouch. Did you see these occur in practice? I guess it can be a
> > > > follow-up issue to resolve (probably by replacing with a different
> > > > implementation) but I'd be very reluctant to allow this to sit for any
> > > > length of time.
> > >
> > > Yes. I've seen this occasionally. DeferredContentProvider looks quite fragile [0].
> > > However, virtual tables with an ILazyContentProvider is a must for this application since there are just too many entries. In theory, we can implement our own ILazyContentProvider that also does filtering and sorting like DeferredContentProvider, but what will be quite some work which deserves a follow-up.
> > >
> > > > ##
> > > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JOverflowUi.java
> > > > [...]
> > > > +        mOverheadTypeViewer.setHeapSize(heapSize);
> > > > +        mReferrerViewer.setHeapSize(heapSize);
> > > > +        mClusterGroupViewer.setHeapSize(heapSize);
> > > > +        mAncestorViewer.setHeapSize(heapSize);
> > > > [...]
> > > > +        mReferrerViewer.allIncluded();
> > > > +        mClusterGroupViewer.allIncluded();
> > > > +        mAncestorViewer.allIncluded();
> > > > +        mOverheadTypeViewer.allIncluded();
> > > > +        for (ModelListener l : mModelListeners) {
> > > > +            l.allIncluded();
> > > > +        }
> > > > [...]
> > > > +        mOverheadTypeViewer.reset();
> > > > +        mReferrerViewer.reset();
> > > > +        mClusterGroupViewer.reset();
> > > > +        mAncestorViewer.reset();
> > > >
> > > >
> > > > These duplicate calls for the four sub-components feel sub-optimal,
> > > > especially in the allIncluded calls. Would it be appropriate to have
> > > > the for-loop construct for the listeners also be used to make the
> > > > calls to the sub-components as well? I.e. having the sub-components
> > > > added to the listener set?
> > >
> > > Correct me if I'm wrong. Are you suggesting something like this?
> > >
> > > List<ModelListener> tmp = new ArrayList<>(mModelListeners);
> > > tmp.addAll(Arrays.asList(mReferrerViewer, mClusterGroupViewer, mAncestorViewer, mOverheadTypeViewer));
> > > for (ModelListener l : tmp) {
> > >     l.allIncluded();
> > > }
>
> Er; I mean to say that the viewers can add themselves, or be added to
> the listener array that already exists and the listener could be
> expanded to also signal reset and heap size changed. So in the
> constructor you could run:
>
> mModelListeners.addAll(Arrays.asList(mReferrerViewer,
> mClusterGroupViewer, mAncestorViewer, mOverheadTypeViewer));
>
> You can see something like this in the previous JOverflowFxUi, though
> they chose (on purpose I suppose?) not to add one of the viewers. Not
> sure if you need to follow them exactly though.
>
Aha I see what you mean now. mOverheadTypeViewer is speical and
includes all ObjectCluster regardless if they're filtered by
mOverheadTypeViewer (unlike all other viewers). That's why the
previous JOverflowFxUi implementation only included three of the
viewers. I'll revert it to something like before.
>
> Regards,
>
> > >
> > > Regards,
> > > Arvin
> > >
> > > [0] https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=509006&hide_resolved=1
> > > >
> > > > Regards,
> > > >
> > > > >
> > > > > Regards,
> > > > > Kangcheng

From hdafgard at gmail.com  Mon Aug 26 22:27:11 2019
From: hdafgard at gmail.com (hdafgard at gmail.com)
Date: Mon, 26 Aug 2019 22:27:11 +0000
Subject: hg: jmc/jmc: JMC-6556: Remove static modifier for struct map in
 TypeManager
Message-ID: <201908262227.x7QMRBCw023826@aojmv0008.oracle.com>

Changeset: 5f29ad9ab539
Author:    hdafgard <hdafgard at gmail.com>
Date:      2019-08-27 00:23 +0200
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/5f29ad9ab539

JMC-6556: Remove static modifier for struct map in TypeManager
Summary: Removes static modifier to fix memory leak and maybe prevent other bugs
Reviewed-by: egahlin

! core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java


From guru.hb at oracle.com  Tue Aug 27 04:15:10 2019
From: guru.hb at oracle.com (Guru)
Date: Tue, 27 Aug 2019 09:45:10 +0530
Subject: JMC-6553 Update error message when JFR is not available
In-Reply-To: <CAN4WuHa=Thcb8Yk6b4_CuNbGupLM_B7t8CZG546Tt1e_7=vHsA@mail.gmail.com>
References: <CAN4WuHY4WAfGjDcRKBGCru-nz7W+Z0mvgjfdF-=s+Hk9rLPWKQ@mail.gmail.com>
 <1a3e01d559f1$8713a660$953af320$@hirt.se>
 <CAN4WuHYoQMPV+me7eYJE9aHX8PVedvB=8bn63pvCbiuntUE5Hw@mail.gmail.com>
 <AAB73856-FC05-4127-8928-46C7A09BE2BE@oracle.com>
 <CAN4WuHa=Thcb8Yk6b4_CuNbGupLM_B7t8CZG546Tt1e_7=vHsA@mail.gmail.com>
Message-ID: <47FBB6B5-19F5-4BBF-88EF-9BD05C0557B1@oracle.com>

+1, Looks good to me. 

Thanks,
Guru
> On 27-Aug-2019, at 1:22 AM, Salman Siddiqui <sasiddiq at redhat.com> wrote:
> 
> Hey Guru,
> 
> Thanks for taking a look.
> I've changed the following:
> * JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE --> JVMSupport_TITLE_LEGACY_JVM_CONSOLE
> * JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE --> JVMSupport_MESSAGE_LEGACY_JVM_CONSOLE
> * JVMSupport_TITLE_NOT_A_KNOWN_JVM --> JVMSupport_TITLE_UNKNOWN_JVM
> * JVMSupport_MESSAGE_NOT_A_KNOWN_JVM --> JVMSupport_MESSAGE_UNKNOWN_JVM
> * JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED --> JVMSupport_JROCKIT_NO_LONGER_SUPPORTED
> * JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT --> JVMSupport_JROCKIT_NO_LONGER_SUPPORTED_SHORT
> 
> Please see changes in webrev.
> 
> https://cr.openjdk.java.net/~aptmac/JMC-6553/webrev.01/ <https://cr.openjdk.java.net/~aptmac/JMC-6553/webrev.01/>
> 
> Thanks,
> Salman
> 
> On Mon, Aug 26, 2019 at 10:20 AM Guru <guru.hb at oracle.com <mailto:guru.hb at oracle.com>> wrote:
> Hi Salman,
> 
> Changes looks good to me. 
> 
> Could it be possible to have any one of below instead of 
> > JVMSupport_MESSAGE_NOT_A_KNOWN_JVM : 
> JVMSupport_MESSAGE_UNKNOWN_JVM 
> 
> > JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE (Any of the below or little better one ) 
> 
> JVMSupport_MESSAGE_UN_SUPPORTED_LEGACY_JVM_CONSOLE 
> JVMSupport_MESSAGE_LEGACY_JVM_CONSOLE 
> 
> Thanks,
> Guru
> > On 26-Aug-2019, at 6:40 PM, Salman Siddiqui <sasiddiq at redhat.com <mailto:sasiddiq at redhat.com>> wrote:
> > 
> > Hi Marcus,
> > 
> > Thanks for the correction. Fixed below.
> > 
> > Regards,
> > Salman
> > 
> > 
> > diff -r cc07a1f270e9
> > application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> > ---
> > a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >   Mon Aug 19 11:57:12 2019 -0400
> > +++
> > b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >   Fri Aug 23 15:29:46 2019 -0400
> > @@ -45,7 +45,7 @@
> > JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> > JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> > unknown JVM. This will most likely not succeed unless you're running the
> > JMX Console, and even then functionality will be limited. \n\nAre you sure
> > you want to continue?
> > JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
> > a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> > Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> > R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
> > you sure you want to continue?
> > -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> > not recent enough for full functionality in the JMX Console. For full
> > functionality you need to connect to a Java 7u40 or later JVM. Do you still
> > want to connect?
> > +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> > not recent enough for full functionality in the JMX Console. For full
> > functionality you need to connect to an Oracle JDK 7u40 or later JVM or an
> > OpenJDK 11+ JVM. Do you still want to connect?
> > JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> > Use a 4.x version of Mission Control when connecting to a JRockit.
> > JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> > supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> > Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> > +54,7 @@
> > JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> > Recorder is not fully supported for JVMs with Java versions below 7u40
> > JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not
> > supported for non HotSpot JVMs
> > JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
> > is not supported for non HotSpot JVMs
> > -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> > enabled. To enable this you need to use a Java 7u4 or later JVM started
> > with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> > +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> > enabled. To enable this you need to use an Oracle JDK 7u4 or later JVM
> > started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> > OpenJDK 11+ JVM.
> > JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
> > not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> > explicitly disabled. To enable the Flight Recorder, remove
> > -XX:-FlightRecorder from the command line.
> > JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> > disabled
> > 
> > On Fri, Aug 23, 2019 at 4:30 PM Marcus Hirt <marcus at hirt.se <mailto:marcus at hirt.se>> wrote:
> > 
> >> Hi Salman,
> >> 
> >> I believe the Oracle JDK has a space between Oracle and JDK
> >> (as opposed to OpenJDK, which is written together).
> >> 
> >> Kind regards,
> >> Marcus
> >> 
> >> -----Ursprungligt meddelande-----
> >> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net <mailto:jmc-dev-bounces at openjdk.java.net>> F?r Salman Siddiqui
> >> Skickat: den 23 augusti 2019 21:31
> >> Till: jmc-dev at openjdk.java.net <mailto:jmc-dev at openjdk.java.net>
> >> ?mne: RFR: JMC-6553 Update error message when JFR is not available
> >> 
> >> Hi all,
> >> 
> >> Please review edit to error message for unavailable JFR below.
> >> 
> >> JIRA: https://bugs.openjdk.java.net/browse/JMC-6553 <https://bugs.openjdk.java.net/browse/JMC-6553>
> >> 
> >> Thanks,
> >> Salman
> >> 
> >> 
> >> diff -r cc07a1f270e9
> >> 
> >> application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >> ---
> >> 
> >> a/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >>   Mon Aug 19 11:57:12 2019 -0400
> >> +++
> >> 
> >> b/application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
> >>   Fri Aug 23 15:29:46 2019 -0400
> >> @@ -45,7 +45,7 @@
> >> JVMSupport_TITLE_TOO_OLD_JVM_CONSOLE=Too Old JVM
> >> JVMSupport_MESSAGE_NOT_A_KNOWN_JVM=You are attempting to connect to an
> >> unknown JVM. This will most likely not succeed unless you're running the
> >> JMX Console, and even then functionality will be limited. \n\nAre you sure
> >> you want to continue?
> >> JVMSupport_MESSAGE_JROCKIT_NOT_SUPPORTED=You are attempting to connect to
> >> a JRockit JVM. To connect to a JRockit JVM, please use JRockit Mission
> >> Control 4.1 for JRockit R28, and JRockit Mission Control 3.1 for JRockit
> >> R27. \nIf you connect to a JRockit, functionality will be limited. \n\nAre
> >> you sure you want to continue?
> >> -JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> >> not recent enough for full functionality in the JMX Console. For full
> >> functionality you need to connect to a Java 7u40 or later JVM. Do you still
> >> want to connect?
> >> +JVMSupport_MESSAGE_TOO_OLD_JVM_CONSOLE=The JVM you are connecting to is
> >> not recent enough for full functionality in the JMX Console. For full
> >> functionality you need to connect to an OracleJDK 7u40 or later JVM or an
> >> OpenJDK 11+ JVM. Do you still want to connect?
> >> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED=JRockit is no longer supported.
> >> Use a 4.x version of Mission Control when connecting to a JRockit.
> >> JVMSupport_JROCKIT_NOT_LONGER_SUPPORTED_SHORT=JRockit is no longer
> >> supported  JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_OLD_HOTSPOT=Flight
> >> Recorder is not supported for JVMs with Java versions below 7u4 @@ -54,7
> >> +54,7 @@
> >> JVMSupport_FLIGHT_RECORDER_NOT_FULLY_SUPPORTED_OLD_HOTSPOT_SHORT=Flight
> >> Recorder is not fully supported for JVMs with Java versions below 7u40
> >> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT=Flight Recorder is not
> >> supported for non HotSpot JVMs
> >> JVMSupport_FLIGHT_RECORDER_NOT_SUPPORTED_NOT_HOTSPOT_SHORT=Flight Recorder
> >> is not supported for non HotSpot JVMs
> >> -JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> >> enabled. To enable this you need to use a Java 7u4 or later JVM started
> >> with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
> >> +JVMSupport_FLIGHT_RECORDER_NOT_ENABLED=Flight Recorder features are not
> >> enabled. To enable this you need to use an OracleJDK 7u4 or later JVM
> >> started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder or an
> >> OpenJDK 11+ JVM.
> >> JVMSupport_FLIGHT_RECORDER_NOT_ENABLED_SHORT=Flight Recorder features are
> >> not enabled  JVMSupport_FLIGHT_RECORDER_DISABLED=Flight Recorder is
> >> explicitly disabled. To enable the Flight Recorder, remove
> >> -XX:-FlightRecorder from the command line.
> >> JVMSupport_FLIGHT_RECORDER_DISABLED_SHORT=Flight Recorder is explicitly
> >> disabled
> >> 
> >> 
> 


From marcus.hirt at datadoghq.com  Tue Aug 27 08:27:10 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 27 Aug 2019 10:27:10 +0200
Subject: RFR: JMC-6556 JFR V1 Parser memory leak
In-Reply-To: <CADFkdVTLAghhtah4-Va4F_ZU5g8hdL5iMh9GG3=QDDkh=T91FA@mail.gmail.com>
References: <CADFkdVTLAghhtah4-Va4F_ZU5g8hdL5iMh9GG3=QDDkh=T91FA@mail.gmail.com>
Message-ID: <CAOpWGx1bTLA33e5sYvk7OD_qFfna8SQHoPedPRfeU0yJXr_7ww@mail.gmail.com>

LGTM! ;)

/M

On Mon, Aug 26, 2019 at 5:57 PM Henrik Dafg?rd <hdafgard at gmail.com> wrote:

> Hi all,
>
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6556
>
> This fixes a small memory leak where the number of attributes added to a
> StructContentType object grows unbounded while recordings are being parsed.
>
> ---
>
> a/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
> +++
>
> b/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
> @@ -116,7 +116,7 @@
>   }
>
>   // NOTE: Using constant pool id as identifier.
> - private static final Map<Long, StructContentType<Object[]>> STRUCT_TYPES
> = new HashMap<>();
> + private final Map<Long, StructContentType<Object[]>> STRUCT_TYPES = new
> HashMap<>();
>
>   private class TypeEntry {
>   private static final String STRUCT_TYPE_CLASS = "java.lang.Class";
> //$NON-NLS-1$
>
>
> Cheers,
> Henrik Dafg?rd
>

From neugens at redhat.com  Tue Aug 27 11:53:31 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 27 Aug 2019 13:53:31 +0200
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
 <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
Message-ID: <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>

On 26/08/2019 17:16, Arvin Kangcheng Xu wrote:
> I'm unsure if those calls are queued or executed right away. I
> remembered introducing this guard after I observed multiple updates
> caused by single user interaction. However, I took a further look at
> the code and experiment a bit. The guard is indeed unnecessary, at
> least for the current code.

What I mean is that the event thread should be the one executeing this
method exclusively, so it cannot be that this code is accessed again
before the update is finished, it's only one thread.

If you see this call executed multiple times it means it's being
accessed concurrently. I do not know enough of the Eclipse/SWT internal,
so I need to defer to Marcus or someone else for this review, however it
does seem to me that something is calling this method concurrently after
all, we should see what code does it and possibly fix it, because I
doubt this is correct.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From kxu at redhat.com  Tue Aug 27 13:40:20 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Tue, 27 Aug 2019 09:40:20 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
 <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
 <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>
Message-ID: <CA+tA26uCqLWCKJvipuvKNY113afJuQM5cyRParLKXhA8HPbZCg@mail.gmail.com>

On Tue, 27 Aug 2019 at 07:53, Mario Torre <neugens at redhat.com> wrote:
>
> On 26/08/2019 17:16, Arvin Kangcheng Xu wrote:
> > I'm unsure if those calls are queued or executed right away. I
> > remembered introducing this guard after I observed multiple updates
> > caused by single user interaction. However, I took a further look at
> > the code and experiment a bit. The guard is indeed unnecessary, at
> > least for the current code.
>
> What I mean is that the event thread should be the one executeing this
> method exclusively, so it cannot be that this code is accessed again
> before the update is finished, it's only one thread.
>
> If you see this call executed multiple times it means it's being
> accessed concurrently. I do not know enough of the Eclipse/SWT internal,
> so I need to defer to Marcus or someone else for this review, however it
> does seem to me that something is calling this method concurrently after
> all, we should see what code does it and possibly fix it, because I
> doubt this is correct.

There is no new thread created once the heap model is loaded, so it cannot
be accessed concurrently. The reason it was called multiple times was that I
had called setSelection on a viewer as part of the updateModel call hierarchy,
which triggers the callback where it handles user clicking and eventually calls
updateModel again. Calls to setSelection were removed later, but not this
guard.

At least that's what I thought what happened. There is a high
likelihood that I'm
wrong. I do agree the code needs extra reviews.

> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From almacdon at redhat.com  Tue Aug 27 15:32:16 2019
From: almacdon at redhat.com (almacdon at redhat.com)
Date: Tue, 27 Aug 2019 15:32:16 +0000
Subject: hg: jmc/jmc: JMC-6553: Update error message when JFR is not available
Message-ID: <201908271532.x7RFWGIF000993@aojmv0008.oracle.com>

Changeset: 3482d4ee8db5
Author:    aptmac <almacdon at redhat.com>
Date:      2019-08-27 10:51 -0400
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/3482d4ee8db5

JMC-6553: Update error message when JFR is not available
Summary: Edit error message for unavailable JFR and rename some message variables
Reviewed-by: hirt, ghb
Contributed-by: Salman Siddiqui <sasiddiq at redhat.com>

! application/l10n/org.openjdk.jmc.rjmx.ja/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages_ja.properties
! application/l10n/org.openjdk.jmc.rjmx.zh_CN/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages_zh_CN.properties
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/JVMSupportToolkit.java
! application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/messages/internal/Messages.java
! application/org.openjdk.jmc.rjmx/src/main/resources/org/openjdk/jmc/rjmx/messages/internal/messages.properties
! application/tests/org.openjdk.jmc.rjmx.test/src/test/java/org/openjdk/jmc/rjmx/test/JVMSupportToolkitTest.java
! application/uitests/org.openjdk.jmc.browser.uitest/src/test/java/org/openjdk/jmc/browser/uitest/jvmcompat/ConnectionMessageTest.java
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JvmBrowser.java


From kxu at redhat.com  Tue Aug 27 17:40:55 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Tue, 27 Aug 2019 13:40:55 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26uCqLWCKJvipuvKNY113afJuQM5cyRParLKXhA8HPbZCg@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
 <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
 <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>
 <CA+tA26uCqLWCKJvipuvKNY113afJuQM5cyRParLKXhA8HPbZCg@mail.gmail.com>
Message-ID: <CA+tA26vO9y73PkmVvOpYYxgMVBvtpW7mTzshuy1X_y4SNmNPHA@mail.gmail.com>

Hello all,

The following is the updated webrev. Several issues mentioned in this
thread are addressed:
- wildcard imports were replaced with single class imports
- unnecessary white spaces were removed
- indentations were changed to using tabs instead of spaces
- removed mIsUpdatingModel guard
- removed getHeapSize and mHeapSize in BaseViewer
- declared setHeapSize in BaseViewer abstract
- initialized mHeapSize to 1 to avoid division by zero
- numbers are now rounded instead of truncated
- number displays are now comma-separated
- removed global jfx dependencies (javafx.osgi, p2 repo, target platforms)
- refactored sub-component calls
- used a more contrasting color palette for pie charts

Webrev:
https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.02/

Thanks to Jie for updating the webrev.


On Tue, 27 Aug 2019 at 09:40, Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> On Tue, 27 Aug 2019 at 07:53, Mario Torre <neugens at redhat.com> wrote:
> >
> > On 26/08/2019 17:16, Arvin Kangcheng Xu wrote:
> > > I'm unsure if those calls are queued or executed right away. I
> > > remembered introducing this guard after I observed multiple updates
> > > caused by single user interaction. However, I took a further look at
> > > the code and experiment a bit. The guard is indeed unnecessary, at
> > > least for the current code.
> >
> > What I mean is that the event thread should be the one executeing this
> > method exclusively, so it cannot be that this code is accessed again
> > before the update is finished, it's only one thread.
> >
> > If you see this call executed multiple times it means it's being
> > accessed concurrently. I do not know enough of the Eclipse/SWT internal,
> > so I need to defer to Marcus or someone else for this review, however it
> > does seem to me that something is calling this method concurrently after
> > all, we should see what code does it and possibly fix it, because I
> > doubt this is correct.
>
> There is no new thread created once the heap model is loaded, so it cannot
> be accessed concurrently. The reason it was called multiple times was that I
> had called setSelection on a viewer as part of the updateModel call hierarchy,
> which triggers the callback where it handles user clicking and eventually calls
> updateModel again. Calls to setSelection were removed later, but not this
> guard.
>
> At least that's what I thought what happened. There is a high
> likelihood that I'm
> wrong. I do agree the code needs extra reviews.
>
> > Cheers,
> > Mario
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus at hirt.se  Wed Aug 28 11:24:23 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 28 Aug 2019 13:24:23 +0200
Subject: Sv: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
 <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>
 <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>
Message-ID: <090e01d55d93$2499c2d0$6dcd4870$@hirt.se>

Hi all,

Regarding the removal of the JavaFX bundles, I'll simply note that Oracle has a JavaFX based plug-in for Coherence. Removing the third-party JavaFX bundling from the p2 site would make it much harder to have JavaFX based plug-ins in most versions of JMC (except Oracle's, who would likely override stuff to retain this capability). This is not necessarily a bad thing - harmonizing around SWT (and Swing for some drawing on the AWT_SWT bridge) would simplify many things. Other things would OTOH become much harder. For example, I once prototyped a rather nice 3D heap region and occupancy viewer using JavaFX.

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Jie Kang
Skickat: den 26 augusti 2019 21:32
Till: Arvin Kangcheng Xu <kxu at redhat.com>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: RFR: JMC-6555 Convert JOverflow plugin to SWT

On Mon, Aug 26, 2019 at 2:37 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> On Mon, 26 Aug 2019 at 14:36, Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> >
> > On Mon, 26 Aug 2019 at 09:15, Jie Kang <jkang at redhat.com> wrote:
> > >
> > > On Wed, Aug 21, 2019 at 10:41 AM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> > > >
> > > > Hello all,
> > > >
> > > > This change aims to port JOverflow from using JavaFX to 
> > > > SWT/JFace, so the extra dependencies could be dropped. 
> > > > Additionally, this change makes JMC-6343 is no longer valid.
> > > >
> > > > This port (re)implements all features available in the original 
> > > > version, and UI design is kept as close as possible. Please let 
> > > > me know your thoughts. Thank you very much!
> > > >
> > > > Also, thanks Jie for creating this webrev for me!
> > > >
> > > > Webrev:
> > > > https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.01/
> > > > Bug:
> > > > https://bugs.openjdk.java.net/browse/JMC-6555
> > >
> > > Hey Arvin,
> > >
> > > Overall nice work! Visually and functionally (minor manual 
> > > testing) it looks to be working quite nicely. I have some comments 
> > > and nits below, separated in two sections. The nits in the second 
> > > section can be addressed in follow-up JIRA issues + patches.
> > >
> > > # Section One
> > >
> > > ##
> > > +import org.eclipse.swt.widgets.*;
> > >
> > > There are a number of imports of x.y.* packages. Are all the 
> > > classes from these required? If not I would use individual 
> > > imports. This makes it easier to see exactly what package a class comes form.
> >
> > I agree. All wildcard imports will be replaced with single class imports.
> >
> > > ##
> > > With the removal of openjfx, it looks like 
> > > org.openjdk.jmc.javafx.osgi is no longer used. Can this be removed 
> > > as well? As well, can the javafx dependencies defined in the p2 
> > > repository and set in the target platform files also be removed?
> >
> > I only removed jfx related dependencies within the joverflow component itself and left the global ones untouched. Are there other dependents preventing us from removing jfx completely? If no further discussions are needed, I'll be happy to remove those, too.

I think they can be removed safely and should be.

> >
> > > ##
> > > There are various instances of whitespace being included for newlines.
> > > Please try to remove these, probably most easily done with an 
> > > auto-formatting tool. For what it's worth, in my terminal, 
> > > invocations of `hg diff` shows these as big blocks of red. Also it 
> > > seems some files use tabs and others use spaces. I think all 
> > > should be switched to tabs for this project.
> >
> > I will adjust my auto-format setting and reformat.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/o
> > > +++ penjdk/jmc/joverflow/ui/JOverflowUi.java
> > > +    private boolean mIsUpdatingModel;
> > > [...]
> > > +    private void updateModel() {
> > > +        if (mIsUpdatingModel) {
> > > +            // skip updating if busy
> > > +            return;
> > > +        }
> > > +
> > > +        mIsUpdatingModel = true;
> > > [...]
> > > +        mIsUpdatingModel = false;
> > > +    }
> > > +
> > > +    void reset() {
> > > +        mIsUpdatingModel = true;
> > > [...]
> > > +        mIsUpdatingModel = false;
> > > [...]
> > >
> > > The thread safety of this construct is concerning. Is it expected 
> > > to only be called by a single thread? If yes, I'd appreciate a 
> > > comment specifying that it is not thread-safe, but it is okay 
> > > because no more than one thread calls this. If no, then I think a 
> > > lock would be more appropriate than a boolean.
> > >
> > > Also there is a guard in updateModel() but no guard in reset(); is 
> > > that intentional? Can things go awry if reset occurs while 
> > > updateModel is executing? I guess these kinds of questions need 
> > > only be considered if there is multi-threaded access...
> >
> > This is addressed in another email thread. mIsUpdatingModel is to be removed.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/o
> > > +++ penjdk/jmc/joverflow/ui/viewers/BaseViewer.java
> > > [...]
> > > +    public void setHeapSize(long size) {
> > > +        mHeapSize = size;
> > > +    }
> > > +
> > > +    public long getHeapSize() {
> > > +        return mHeapSize;
> > > +    }
> > >
> > > I don't see any usages of getHeapSize or of mHeapSize within this 
> > > class. Can they be removed?
> >
> > Yes. getHeapSize and mHeapSize will be removed. setHeapSize will be declared abstract.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/o
> > > +++ penjdk/jmc/joverflow/ui/viewers/MemoryStatisticsTab
> > > leViewer.java
> > > +class MemoryStatisticsTableViewer extends TableViewer {
> > > +
> > > +       private long mHeapSize;
> > > [...]
> > > +       MemoryStatisticsTableViewer(Composite parent, int style,
> > > Function<MemoryStatisticsItem, Color> colorProvider) { [...]
> > > +               createTableColumnViewer("Memory KB",
> > > +                               model -> String.format("%d 
> > > + (%d%%)",
> > > model.getMemory() / 1024, model.getMemory() * 100 / mHeapSize), 
> > > [...]
> > > +       void setHeapSize(long size) {
> > > +               mHeapSize = size;
> > > +       }
> > >
> > > Is it possible mHeapSize is *not* set via the package private 
> > > function before being used in the label provider created by the 
> > > constructor? I might initialize it to 1 just to prevent a possible NPE.
> >
> > I'm not aware of a better solution at this moment, but I'll initialize it to 1 to avoid ArithmeticException.
> >
> > > # Section 2: Can be addressed in follow-up JIRA issues + patches, 
> > > or immediately if easily done
> > >
> > > ##
> > > The values displayed are no longer comma separated. For example
> > > 1234567 instead of 1,234,567. I think comma-separation increases 
> > > readability. If possible could this be added?
> >
> > This should be an easy fix. Comma-separation will be implemented in the next update.
> >
> > > ##
> > > For the colour selection of arcs, some colours blend quite closely 
> > > with each other. While we're here it would be nice to only use 
> > > contrasting colours (rainbow).
> >
> > Right now the colours are random. There is no colour palette since there is no telling how many colours are needed. I'll study the original implementation and see how it was handled.
> >
> > > ##
> > > The selection made in the Ancestor Referrer table persists though 
> > > the table contents change after selection. In the jfx version, the 
> > > table is deselected after. To reproduce, use the mouse to select a 
> > > row in the table. After selection, the table contents are changed 
> > > but the row (which has different content) remains selected. I 
> > > think it's okay to deselect after, or better yet, re-select the correct row.
> >
> > This is interesting and I can't provide an explanation of why it is happening at this moment. I'll look into this afterwards.

My text explanation may have been confusing but yeah sounds good to look at it later.

> >
> > > ##
> > > When loading the same hprof file into JOverflow, some values are 
> > > off by one between the jfx and swt versions. Is it possibly due to 
> > > different rounding in the ui? It looks like the core api for 
> > > joverflow is unchanged. If so, this can probably be ignored. I saw 
> > > this for values in the Ancestor Referrer table.
> >
> > Yes, it is a difference in rounding. When converting from B to KB, the jfx version rounds and the swt version truncates. I'll change it to rounding.
> >
> > Also, do you think it's worth to change "KB" to the more accurate "KiB"?

I'd would follow whatever is done elsewhere in the project. Not sure what you mean by more accurate though; my understanding from [1] KB == KiB != kB

[1] https://en.wikipedia.org/wiki/Kibibyte

> >
> > > ##
> > > +               // FIXME: Bug 165637 - [Viewers]
> > > ArrayIndexOutOfBoundsException exception in ConcurrentTableUpdator 
> > > (used in DeferredContentProvider)
> > > +        // https://bugs.eclipse.org/bugs/show_bug.cgi?id=165637
> > > +               mContentProvider = new 
> > > + DeferredContentProvider((lhs, rhs) -> 0);
> > > [...]
> > > +                                       // FIXME: Bug 146799 - 
> > > + Blank
> > > last table item on virtual table
> > > +                       // 
> > > + https://bugs.eclipse.org/bugs/show_bug.cgi?id=146799
> > >
> > > Ouch. Did you see these occur in practice? I guess it can be a 
> > > follow-up issue to resolve (probably by replacing with a different
> > > implementation) but I'd be very reluctant to allow this to sit for 
> > > any length of time.
> >
> > Yes. I've seen this occasionally. DeferredContentProvider looks quite fragile [0].
> > However, virtual tables with an ILazyContentProvider is a must for this application since there are just too many entries. In theory, we can implement our own ILazyContentProvider that also does filtering and sorting like DeferredContentProvider, but what will be quite some work which deserves a follow-up.
> >
> > > ##
> > > +++ b/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/o
> > > +++ penjdk/jmc/joverflow/ui/JOverflowUi.java
> > > [...]
> > > +        mOverheadTypeViewer.setHeapSize(heapSize);
> > > +        mReferrerViewer.setHeapSize(heapSize);
> > > +        mClusterGroupViewer.setHeapSize(heapSize);
> > > +        mAncestorViewer.setHeapSize(heapSize);
> > > [...]
> > > +        mReferrerViewer.allIncluded();
> > > +        mClusterGroupViewer.allIncluded();
> > > +        mAncestorViewer.allIncluded();
> > > +        mOverheadTypeViewer.allIncluded();
> > > +        for (ModelListener l : mModelListeners) {
> > > +            l.allIncluded();
> > > +        }
> > > [...]
> > > +        mOverheadTypeViewer.reset();
> > > +        mReferrerViewer.reset();
> > > +        mClusterGroupViewer.reset();
> > > +        mAncestorViewer.reset();
> > >
> > >
> > > These duplicate calls for the four sub-components feel 
> > > sub-optimal, especially in the allIncluded calls. Would it be 
> > > appropriate to have the for-loop construct for the listeners also 
> > > be used to make the calls to the sub-components as well? I.e. 
> > > having the sub-components added to the listener set?
> >
> > Correct me if I'm wrong. Are you suggesting something like this?
> >
> > List<ModelListener> tmp = new ArrayList<>(mModelListeners); 
> > tmp.addAll(Arrays.asList(mReferrerViewer, mClusterGroupViewer, 
> > mAncestorViewer, mOverheadTypeViewer)); for (ModelListener l : tmp) {
> >     l.allIncluded();
> > }

Er; I mean to say that the viewers can add themselves, or be added to the listener array that already exists and the listener could be expanded to also signal reset and heap size changed. So in the constructor you could run:

mModelListeners.addAll(Arrays.asList(mReferrerViewer,
mClusterGroupViewer, mAncestorViewer, mOverheadTypeViewer));

You can see something like this in the previous JOverflowFxUi, though they chose (on purpose I suppose?) not to add one of the viewers. Not sure if you need to follow them exactly though.


Regards,

> >
> > Regards,
> > Arvin
> >
> > [0] 
> > https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=509006&hide_
> > resolved=1
> > >
> > > Regards,
> > >
> > > >
> > > > Regards,
> > > > Kangcheng


From neugens at redhat.com  Wed Aug 28 12:17:17 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 28 Aug 2019 14:17:17 +0200
Subject: Sv: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <090e01d55d93$2499c2d0$6dcd4870$@hirt.se>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
 <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>
 <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>
 <090e01d55d93$2499c2d0$6dcd4870$@hirt.se>
Message-ID: <601b6f2c-4306-61bd-54c7-b2b7f9a3f2ee@redhat.com>

On 28/08/2019 13:24, Marcus Hirt wrote:
> Hi all,
> 
> Regarding the removal of the JavaFX bundles, I'll simply note that Oracle has a JavaFX based plug-in for Coherence. Removing the third-party JavaFX bundling from the p2 site would make it much harder to have JavaFX based plug-ins in most versions of JMC (except Oracle's, who would likely override stuff to retain this capability). This is not necessarily a bad thing - harmonizing around SWT (and Swing for some drawing on the AWT_SWT bridge) would simplify many things. Other things would OTOH become much harder. For example, I once prototyped a rather nice 3D heap region and occupancy viewer using JavaFX.

Shouldn't this be treated as any other dependency however? If a plugin
needs it, it will just add it to its own p2 configuration, like it's
already the case, or am I missing something?

I think it's a good idea to cleanup the dependency set and remove what
is not needed. If there's some plugin that gets promoted into core we
can always re-add the deps.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus at hirt.se  Wed Aug 28 12:33:25 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 28 Aug 2019 14:33:25 +0200
Subject: Sv: Sv: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <601b6f2c-4306-61bd-54c7-b2b7f9a3f2ee@redhat.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
 <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>
 <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>
 <090e01d55d93$2499c2d0$6dcd4870$@hirt.se>
 <601b6f2c-4306-61bd-54c7-b2b7f9a3f2ee@redhat.com>
Message-ID: <001d01d55d9c$c99bcd10$5cd36730$@hirt.se>

Hi Mario,

The problem is that the JavaFX bundles aren't proper OSGi bundles exposed on any pre-existing update site - they get exposed to the Tycho build through the local update site, together with other such third-party dependencies. In other words, it becomes much more complicated for someone to add JavaFX depending plug-ins once we remove JavaFX from the local update site.

And, as I noted, that is both good and bad. ;)

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
Skickat: den 28 augusti 2019 14:17
Till: jmc-dev at openjdk.java.net
?mne: Re: Sv: RFR: JMC-6555 Convert JOverflow plugin to SWT

On 28/08/2019 13:24, Marcus Hirt wrote:
> Hi all,
> 
> Regarding the removal of the JavaFX bundles, I'll simply note that Oracle has a JavaFX based plug-in for Coherence. Removing the third-party JavaFX bundling from the p2 site would make it much harder to have JavaFX based plug-ins in most versions of JMC (except Oracle's, who would likely override stuff to retain this capability). This is not necessarily a bad thing - harmonizing around SWT (and Swing for some drawing on the AWT_SWT bridge) would simplify many things. Other things would OTOH become much harder. For example, I once prototyped a rather nice 3D heap region and occupancy viewer using JavaFX.

Shouldn't this be treated as any other dependency however? If a plugin needs it, it will just add it to its own p2 configuration, like it's already the case, or am I missing something?

I think it's a good idea to cleanup the dependency set and remove what is not needed. If there's some plugin that gets promoted into core we can always re-add the deps.

Cheers,
Mario

--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From neugens at redhat.com  Wed Aug 28 12:47:50 2019
From: neugens at redhat.com (Mario Torre)
Date: Wed, 28 Aug 2019 14:47:50 +0200
Subject: Sv: Sv: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <001d01d55d9c$c99bcd10$5cd36730$@hirt.se>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CA+tA26veuJv1sQ8u102woSQag0yQ=H++9RE0jtE-AC0oEWgFqQ@mail.gmail.com>
 <CA+tA26t+HF9Tvr4Z0=gmD-Dixzyhne-Y7essOY4Jn=tf71mr9w@mail.gmail.com>
 <CAEBeOcp2kFkerr49d9EcydkmNNEygHW5CR-Ba0tCOgfu4bH+8w@mail.gmail.com>
 <090e01d55d93$2499c2d0$6dcd4870$@hirt.se>
 <601b6f2c-4306-61bd-54c7-b2b7f9a3f2ee@redhat.com>
 <001d01d55d9c$c99bcd10$5cd36730$@hirt.se>
Message-ID: <c25fb229-ede5-62f2-02b2-3142664f9247@redhat.com>

On 28/08/2019 14:33, Marcus Hirt wrote:
> Hi Mario,
> 
> The problem is that the JavaFX bundles aren't proper OSGi bundles exposed on any pre-existing update site - they get exposed to the Tycho build through the local update site, together with other such third-party dependencies. In other words, it becomes much more complicated for someone to add JavaFX depending plug-ins once we remove JavaFX from the local update site.

Ok, I get that, but shouldn't we file a bug report to the OpenJFX folks
to fix this instead of hacking around a dependency we don't need?[1] :)

> And, as I noted, that is both good and bad. ;)

I think we should sanitize the dependencies, if OpenJFX-based JMC
plugins are really so popular, users can file a bug report and we can
revert the change. On the other hand, a plugin developer can do the same
Tycho build hack and be sure their plugin will work with any JMC build.
I would argue this is the most natural place anyway.

Cheers,
Mario

[1] Yet? Ever? ;)

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From jkang at redhat.com  Wed Aug 28 14:46:41 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 28 Aug 2019 10:46:41 -0400
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
 <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
Message-ID: <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>

Hi all,

Carmine has requested I continue this work in his stead. Please find
an updated webrev for review below.

Webrev: http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JMC-5473


Regards



On Thu, Aug 1, 2019 at 10:24 AM Carmine Vincenzo Russo
<carusso at redhat.com> wrote:
>
> Hi Jie,
>
> Thanks for pointing out these errors, I'll fix them and get back with an updated version.
>
> Thanks,
> Carmine
>
> On Thu, Aug 1, 2019 at 4:16 PM Jie Kang <jkang at redhat.com> wrote:
>>
>> On Thu, Aug 1, 2019 at 6:53 AM Carmine Vincenzo Russo
>> <carusso at redhat.com> wrote:
>> >
>> > Hi,
>> >
>> > The attached patch addresses the issue JMC-5473[0] in which a search
>> > feature for the Automated Analysis Result Table was lacking.
>> >
>> > In ResultOverview.java, I added the text component and a simple layout to
>> > give the page more consistency when the table is displayed.
>> > I also produced ResultOverviewTest.java to test if the table has
>> > components, the search feature operates, and two more to check if the
>> > behaviour is what we expect with a nonsense search and a specific search.
>> >
>> > A side note, since there were no tests for the Automated Analysis Result, I
>> > had to add the tab in JfrUi and allow the record analysis in two other
>> > classes, OldRecordingsVerificationTest.java and JfrRecordingTest.java,
>> > because they go through all the tabs listed in JfrUi during their tests.
>> >
>> > How does it look?
>>
>> Hi Carmine,
>>
>> Thanks for doing this; the tests are appreciated! I have some issues
>> to address below:
>>
>> diff --git a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/R
>> esultOverview.java
>> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/ov
>> erview/ResultOverview.java
>> --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
>> erview.java
>> +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
>> erview.java
>> [...]
>> -
>> +
>>
>> * Whitespace additions like the example shown above should be removed;
>> there are others in the patch.
>>
>> -                       Map<Result, DataPageDescriptor> map = createResultMap();
>> +                       GridLayout layout = new GridLayout(1, true);
>> +                       this.form.getBody().setLayout(layout);
>> +                       text = new Text(form.getBody(), SWT.BORDER |
>> SWT.HORIZONTAL | SWT.SEARCH | SWT.RESIZE);
>> +                       text.setLayoutData(new GridData(SWT.FILL,
>> SWT.DEFAULT, true, false));
>> +                       text.setMessage(Messages.ResultOverview_SEARCH_TABLE);
>> +                       text.setToolTipText(Messages.ResultOverview_SEARCH_BAR);
>> +                       Map<Result, DataPageDescriptor> map =
>> createResultMap(text.getText());
>>                         table = new ResultTableUi(form, toolkit,
>> editor, loadedState, map);
>> +                       ModifyListener listener = new ModifyListener() {
>> +                               @Override
>> +                               public void modifyText(ModifyEvent e) {
>> +                                       Map<Result,
>> DataPageDescriptor> map = createResultMap(text.getText());
>> +                                       table.updateInput(map);
>> +                               }
>> +                       };
>> +                       text.addModifyListener(listener);
>>                 }
>> * The additions to the Table UI done above should occur in the Table
>> UI code, rather than in the overview which is managing the HTML UI and
>> the Table UI, ie. the above should be within ResultTableUi.java
>>
>> * When switching to the Table and then back to the HTML, the resulting
>> view is strange; see the linked image [1]. This may have to do with
>> how the form's layout is modified by your addition. This form is the
>> parent for the ResultTableUi. I would add children to it with custom
>> layouts, but I would not modify the 'parent' layout itself.
>>
>> https://imgur.com/a/nS1m2T2
>>
>>
>> Regards,
>>
>> >
>> > Regards,
>> > Carmine
>> >
>> > [0] https://bugs.openjdk.java.net/browse/JMC-5473
>> >
>> > --
>> > Carmine Vincenzo Russo
>
>
>
> --
> Carmine Vincenzo Russo

From jkang at redhat.com  Wed Aug 28 15:33:23 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 28 Aug 2019 11:33:23 -0400
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
 <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
 <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>
Message-ID: <CAEBeOco2f89wiR6dCp60pEiYArOPRZ_1TFQkoP907QKend3r0g@mail.gmail.com>

On Wed, Aug 28, 2019 at 10:46 AM Jie Kang <jkang at redhat.com> wrote:
>
> Hi all,
>
> Carmine has requested I continue this work in his stead. Please find
> an updated webrev for review below.
>
> Webrev: http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JMC-5473

Ah; I had a mistake in the previous webrev (the TableViewer was no
longer set), please find an updated one below. Apologies for the
mistake.

http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.01/


Regards,

>
>
> Regards
>
>
>
> On Thu, Aug 1, 2019 at 10:24 AM Carmine Vincenzo Russo
> <carusso at redhat.com> wrote:
> >
> > Hi Jie,
> >
> > Thanks for pointing out these errors, I'll fix them and get back with an updated version.
> >
> > Thanks,
> > Carmine
> >
> > On Thu, Aug 1, 2019 at 4:16 PM Jie Kang <jkang at redhat.com> wrote:
> >>
> >> On Thu, Aug 1, 2019 at 6:53 AM Carmine Vincenzo Russo
> >> <carusso at redhat.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > The attached patch addresses the issue JMC-5473[0] in which a search
> >> > feature for the Automated Analysis Result Table was lacking.
> >> >
> >> > In ResultOverview.java, I added the text component and a simple layout to
> >> > give the page more consistency when the table is displayed.
> >> > I also produced ResultOverviewTest.java to test if the table has
> >> > components, the search feature operates, and two more to check if the
> >> > behaviour is what we expect with a nonsense search and a specific search.
> >> >
> >> > A side note, since there were no tests for the Automated Analysis Result, I
> >> > had to add the tab in JfrUi and allow the record analysis in two other
> >> > classes, OldRecordingsVerificationTest.java and JfrRecordingTest.java,
> >> > because they go through all the tabs listed in JfrUi during their tests.
> >> >
> >> > How does it look?
> >>
> >> Hi Carmine,
> >>
> >> Thanks for doing this; the tests are appreciated! I have some issues
> >> to address below:
> >>
> >> diff --git a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/R
> >> esultOverview.java
> >> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/ov
> >> erview/ResultOverview.java
> >> --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> >> erview.java
> >> +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> >> erview.java
> >> [...]
> >> -
> >> +
> >>
> >> * Whitespace additions like the example shown above should be removed;
> >> there are others in the patch.
> >>
> >> -                       Map<Result, DataPageDescriptor> map = createResultMap();
> >> +                       GridLayout layout = new GridLayout(1, true);
> >> +                       this.form.getBody().setLayout(layout);
> >> +                       text = new Text(form.getBody(), SWT.BORDER |
> >> SWT.HORIZONTAL | SWT.SEARCH | SWT.RESIZE);
> >> +                       text.setLayoutData(new GridData(SWT.FILL,
> >> SWT.DEFAULT, true, false));
> >> +                       text.setMessage(Messages.ResultOverview_SEARCH_TABLE);
> >> +                       text.setToolTipText(Messages.ResultOverview_SEARCH_BAR);
> >> +                       Map<Result, DataPageDescriptor> map =
> >> createResultMap(text.getText());
> >>                         table = new ResultTableUi(form, toolkit,
> >> editor, loadedState, map);
> >> +                       ModifyListener listener = new ModifyListener() {
> >> +                               @Override
> >> +                               public void modifyText(ModifyEvent e) {
> >> +                                       Map<Result,
> >> DataPageDescriptor> map = createResultMap(text.getText());
> >> +                                       table.updateInput(map);
> >> +                               }
> >> +                       };
> >> +                       text.addModifyListener(listener);
> >>                 }
> >> * The additions to the Table UI done above should occur in the Table
> >> UI code, rather than in the overview which is managing the HTML UI and
> >> the Table UI, ie. the above should be within ResultTableUi.java
> >>
> >> * When switching to the Table and then back to the HTML, the resulting
> >> view is strange; see the linked image [1]. This may have to do with
> >> how the form's layout is modified by your addition. This form is the
> >> parent for the ResultTableUi. I would add children to it with custom
> >> layouts, but I would not modify the 'parent' layout itself.
> >>
> >> https://imgur.com/a/nS1m2T2
> >>
> >>
> >> Regards,
> >>
> >> >
> >> > Regards,
> >> > Carmine
> >> >
> >> > [0] https://bugs.openjdk.java.net/browse/JMC-5473
> >> >
> >> > --
> >> > Carmine Vincenzo Russo
> >
> >
> >
> > --
> > Carmine Vincenzo Russo

From jkang at redhat.com  Thu Aug 29 13:58:36 2019
From: jkang at redhat.com (Jie Kang)
Date: Thu, 29 Aug 2019 09:58:36 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26vO9y73PkmVvOpYYxgMVBvtpW7mTzshuy1X_y4SNmNPHA@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
 <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
 <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>
 <CA+tA26uCqLWCKJvipuvKNY113afJuQM5cyRParLKXhA8HPbZCg@mail.gmail.com>
 <CA+tA26vO9y73PkmVvOpYYxgMVBvtpW7mTzshuy1X_y4SNmNPHA@mail.gmail.com>
Message-ID: <CAEBeOcp6y5GUAHsy9f=J0SKcV6m7UsqDB6VRsJNoByvWOnx0jw@mail.gmail.com>

On Tue, Aug 27, 2019 at 1:41 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> Hello all,
>
> The following is the updated webrev. Several issues mentioned in this
> thread are addressed:
> - wildcard imports were replaced with single class imports
> - unnecessary white spaces were removed
> - indentations were changed to using tabs instead of spaces
> - removed mIsUpdatingModel guard
> - removed getHeapSize and mHeapSize in BaseViewer
> - declared setHeapSize in BaseViewer abstract
> - initialized mHeapSize to 1 to avoid division by zero
> - numbers are now rounded instead of truncated
> - number displays are now comma-separated
> - removed global jfx dependencies (javafx.osgi, p2 repo, target platforms)
> - refactored sub-component calls
> - used a more contrasting color palette for pie charts
>
> Webrev:
> https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.02/

Hi all,

I talked with Arvin through chat for some issues but for archive
purposes I will list them, as well as some other issues here:

* The rounding of KB values close to zero makes the data completely
lost as the result shown is 0 KB. It would be nice if it had a few
decimal points and a tooltip that showed the exact value.
* When entering and exiting a table entry with mouse, the colour
palette now rotates through the colours so they can no longer match
the pie chart
* After the alters to the spotbugs excludes file an error [1] now
shows up. The match for org.openjdk.jmc.joverflow.ui.FXMain was
written incorrectly with "OR" instead of "Or" so I guess it matched
everything. Now that it's gone, a proper exclusion needs to be added
to keep spotbugs happy.

* I have opened a JMC instance which automatically re-opens a hprof
file I had opened in a previous run of the application. When I use
Window -> Show View -> Other -> JOverflow -> JOverflow Instances, I
see the instances panel load with an NPE [2]. Note if I then close and
re-open JMC where both the hprof file and the instances panel are
loaded, this doesn't occur.
* After seeing the NPE in the instances panel, when clicking around
somewhat randomly in the view of a hprof file and repeatedly pressing
the "Reset" button in the top-right corner, I see a Problem Occurred
pop-up showing an NPE [3]. It occurs consistently when clicking an
element in the Object Selection table (top left corner). The "Reset"
button also no longer causes the views to reset.
* If I have the Instances panel open before I open a hprof file it
seems okay for the most part. I have also checked the previous
revision and Similar behaviour also occurs

[1]

[INFO] --- spotbugs-maven-plugin:3.1.10:check (default) @
org.openjdk.jmc.commands ---
[INFO] BugInstance size is 1
[INFO] Error size is 0
[INFO] Total bugs: 1
[ERROR] org.openjdk.jmc.commands.internal.executables.Version.execute(Statement,
PrintStream) invokes System.exit(...), which shuts down the entire
virtual machine
[org.openjdk.jmc.commands.internal.executables.Version] At
Version.java:[line 47] DM_EXIT

[2]

java.lang.NullPointerException
at org.openjdk.jmc.joverflow.ui.JavaThingPage.allIncluded(JavaThingPage.java:80)
at org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:141)
at org.openjdk.jmc.joverflow.ui.JOverflowUi.addModelListener(JOverflowUi.java:158)
at org.openjdk.jmc.joverflow.ui.InstancesPageBookView.lambda$0(InstancesPageBookView.java:59)
at org.openjdk.jmc.joverflow.ui.JOverflowEditor.addUiLoadedListener(JOverflowEditor.java:271)
at org.openjdk.jmc.joverflow.ui.InstancesPageBookView.doCreatePage(InstancesPageBookView.java:59)
[truncated...]

[3]

java.lang.NullPointerException
at org.openjdk.jmc.joverflow.ui.JavaThingPage.allIncluded(JavaThingPage.java:80)
at org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:141)
at org.openjdk.jmc.joverflow.ui.viewers.BaseViewer.notifyFilterChangedListeners(BaseViewer.java:24)
at org.openjdk.jmc.joverflow.ui.viewers.OverheadTypeViewer.setCurrentType(OverheadTypeViewer.java:90)
at org.openjdk.jmc.joverflow.ui.viewers.OverheadTypeViewer.lambda$0(OverheadTypeViewer.java:33)
at org.eclipse.jface.viewers.Viewer$1.run(Viewer.java:151)
[truncated...]


Regards,


>
> Thanks to Jie for updating the webrev.
>

From jkang at redhat.com  Thu Aug 29 17:04:08 2019
From: jkang at redhat.com (Jie Kang)
Date: Thu, 29 Aug 2019 13:04:08 -0400
Subject: RFR: JMC-6534 String deduplication rule assumes only G1 has
 feature
In-Reply-To: <CADFkdVQv0ZvMVbcuh5WHak3DEkF_Fhiz-4FC5BwBtZcrvNJRhw@mail.gmail.com>
References: <CAEBeOcpUjLR1arYWzVSaoFT8nQ6h3jKeepREoBxc3JW6D5JEBw@mail.gmail.com>
 <CADFkdVQv0ZvMVbcuh5WHak3DEkF_Fhiz-4FC5BwBtZcrvNJRhw@mail.gmail.com>
Message-ID: <CAEBeOcpvfWwJ4_wMH20ePpZ56skQnPyUAiO55x5PNtc+ffZC3w@mail.gmail.com>

On Fri, Aug 16, 2019 at 10:17 AM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>
> Hi Jie,
>
> This change looks good to me!

Thanks for reviewing this! I have found some volunteers to offer
translations (non-professional) for Chinese and Japanese. Marcus, what
needs to be done to get these translations accepted? I have also
switched some links to https instead of http.

Updated Webrev:
https://cr.openjdk.java.net/~jkang/jmc-6534/webrev.02/
JIRA:
https://bugs.openjdk.java.net/browse/JMC-6534


Regards,


>
>
> Cheers,
> Henrik Dafg?rd
>
>
> On Fri, 16 Aug 2019 at 16:11, Jie Kang <jkang at redhat.com> wrote:
>>
>> Hi,
>>
>> Please review this update to the String Deduplication rule. It now
>> also checks for Shenandoah GC and the messages have been updated
>> appropriately. I would also like to request translation assistance for
>> said messages for Chinese and Japanese. Specifically:
>>
>> StringDeduplicationRule_RESULT_LONG_DESCRIPTION
>> StringDeduplicationRule_RESULT_GC_LONG
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jkang/jmc-6534/webrev.01/
>> JIRA:
>> https://bugs.openjdk.java.net/browse/JMC-6534
>>
>>
>> Regards,

From marcus at hirt.se  Fri Aug 30 07:54:08 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 30 Aug 2019 09:54:08 +0200
Subject: Sv: RFR: JMC-6534 String deduplication rule assumes only G1 has
 feature
In-Reply-To: <CAEBeOcpvfWwJ4_wMH20ePpZ56skQnPyUAiO55x5PNtc+ffZC3w@mail.gmail.com>
References: <CAEBeOcpUjLR1arYWzVSaoFT8nQ6h3jKeepREoBxc3JW6D5JEBw@mail.gmail.com>
 <CADFkdVQv0ZvMVbcuh5WHak3DEkF_Fhiz-4FC5BwBtZcrvNJRhw@mail.gmail.com>
 <CAEBeOcpvfWwJ4_wMH20ePpZ56skQnPyUAiO55x5PNtc+ffZC3w@mail.gmail.com>
Message-ID: <020401d55f08$1abd7a60$50386f20$@hirt.se>

Hi David,

Would you perhaps be able to verify the Japanese translations?

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Jie Kang
Skickat: den 29 augusti 2019 19:04
Till: Henrik Dafg?rd <hdafgard at gmail.com>; Marcus Hirt <marcus.hirt at datadoghq.com>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: RFR: JMC-6534 String deduplication rule assumes only G1 has feature

On Fri, Aug 16, 2019 at 10:17 AM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>
> Hi Jie,
>
> This change looks good to me!

Thanks for reviewing this! I have found some volunteers to offer translations (non-professional) for Chinese and Japanese. Marcus, what needs to be done to get these translations accepted? I have also switched some links to https instead of http.

Updated Webrev:
https://cr.openjdk.java.net/~jkang/jmc-6534/webrev.02/
JIRA:
https://bugs.openjdk.java.net/browse/JMC-6534


Regards,


>
>
> Cheers,
> Henrik Dafg?rd
>
>
> On Fri, 16 Aug 2019 at 16:11, Jie Kang <jkang at redhat.com> wrote:
>>
>> Hi,
>>
>> Please review this update to the String Deduplication rule. It now 
>> also checks for Shenandoah GC and the messages have been updated 
>> appropriately. I would also like to request translation assistance 
>> for said messages for Chinese and Japanese. Specifically:
>>
>> StringDeduplicationRule_RESULT_LONG_DESCRIPTION
>> StringDeduplicationRule_RESULT_GC_LONG
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jkang/jmc-6534/webrev.01/
>> JIRA:
>> https://bugs.openjdk.java.net/browse/JMC-6534
>>
>>
>> Regards,


From marcus at hirt.se  Fri Aug 30 10:42:52 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Fri, 30 Aug 2019 12:42:52 +0200
Subject: Moving to GitHub (project Skara)
Message-ID: <02c101d55f1f$acc20900$06461b00$@hirt.se>

Hi all,

Three OpenJDK projects are now in the process of moving over to GitHub. 

	Loom:
	
https://mail.openjdk.java.net/pipermail/loom-dev/2019-August/000682.html

	OpenJFX: 
	
https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-August/023510.html

	Mobile: 
	
https://mail.openjdk.java.net/pipermail/mobile-dev/2019-June/000584.html

I think the JMC project should be next. There are many good reasons for
moving, but for me one of the strongest is that open source development is a
social activity, and the biggest network of developers are on GitHub.

Please let me know what you think!

Kind regards,
Marcus


From klara at kth.se  Fri Aug 30 11:43:05 2019
From: klara at kth.se (Klara Ward)
Date: Fri, 30 Aug 2019 13:43:05 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <02c101d55f1f$acc20900$06461b00$@hirt.se>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
Message-ID: <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>

+1 for GitHub

 ?// Klara

On 2019-08-30 12:42, Marcus Hirt wrote:
> Hi all,
>
> Three OpenJDK projects are now in the process of moving over to GitHub.
>
> 	Loom:
> 	
> https://mail.openjdk.java.net/pipermail/loom-dev/2019-August/000682.html
>
> 	OpenJFX:
> 	
> https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-August/023510.html
>
> 	Mobile:
> 	
> https://mail.openjdk.java.net/pipermail/mobile-dev/2019-June/000584.html
>
> I think the JMC project should be next. There are many good reasons for
> moving, but for me one of the strongest is that open source development is a
> social activity, and the biggest network of developers are on GitHub.
>
> Please let me know what you think!
>
> Kind regards,
> Marcus
>


From 48161430 at qq.com  Tue Aug 13 03:15:00 2019
From: 48161430 at qq.com (Huanglq)
Date: Tue, 13 Aug 2019 03:15:00 -0000
Subject: Can jmc-agent be used to manipulate JFR recording in a
 programmatically way instead of cmd via shell?
Message-ID: <9C939AEA-D30D-4B21-9DF9-8FD39C65A60A@qq.com>+BE85524A33B7EB15

Hi there,

?????? Does jmc source code(https://github.com/JDKMissionControl/jmc) provide APIs to manipulate JFR recording in a programmatically way?

?????? I'm working on implementing an java agent to manipulate the JFR recording instead of cmd via shell. Then I have read the description of the wiki and the README file in source code. But I'm not sure whether jmc-agent can achieve my purpose. Any suggestions would be appreciated.

 

Regards,

Huanglq