RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

[Daniel Fuchs]

Hi Jeremy,

I'm not sure I understand exactly what is going on there.
I wonder if this has anything to do with an issue I noticed some
time back when the jvisualvm for JDK 8 and JDK 9 were still out
of sync:
https://bugs.openjdk.java.net/browse/JDK-8167099

I stumbled on that because at the time I was hacking my
developer's build of JDK 9 and trying to make it generate
JDK 8 CompositeDatas. But then as far as I could see that
bug (JDK-8167099) could not be observed in a regular
environment - it was just tickled by my hacks.

Now I'm wondering if what you're seeing is more or less
related to that issue (it might not).

In any case - one possibility if you don't want to create
a new CompositeType might be to pass a filtering lambda
to isTypeMatched.

Something like a BiPredicate<CompositeType, String> that
would take a composite type and a field name and tell
whether to include it or not in the comparison.

best regards,

-- daniel


On 16/02/2018 05:01, Jeremy Manson wrote:
> 
> 
> On Thu, Feb 15, 2018 at 6:40 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 16/02/2018 11:12 AM, Jeremy Manson wrote:
> 
>         Previous bug:
> 
>         https://bugs.openjdk.java.net/browse/JDK-6588467
>         <https://bugs.openjdk.java.net/browse/JDK-6588467>
> 
>         And the review thread:
> 
>         http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-January/016356.html
>         <http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-January/016356.html>
> 
>         I don't think the bug would have been obvious to a reviewer (or,
>         indeed, the author of the patch!), because we would have had to
>         think about how ticd.isCurrentVersion worked, and noticed the
>         fact that some of the fields are optional.
> 
> 
>     I misunderstood the connection to the old bug and review. This is a
>     pre-existing issue that wasn't noticed last time this code was
>     updated - right?
> 
> 
> Sort of.  The uses of isCurrentVersion() didn't happen to need to 
> exclude optional values before I made my changes.  It falls under the 
> category of unstated assumptions.  The method could have been called 
> "isCurrentVersionAndDoesntIgnoreOptionalValues".  :)
> 
> Jeremy