RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent

Chris Plummer chris.plummer at oracle.com
Wed Mar 25 19:52:02 UTC 2020


Hi Magus,

I haven't looked at the changes yet, other to see that there are many 
files touched, but after reading below (and only partly understanding 
since I don't know this area well), I was wondering if this issue 
wouldn't be better served with multiple passes made to fix the warnings. 
Start with a straight forward one where you are maybe only making one or 
two types of changes, but that affect a large number of files and don't 
cascade into other more complicated changes. This will get a lot of the 
noise out of the way, and then we can focus on some of the harder issues 
you bring up below.

As for testing, I think the following list will capture all of them, but 
can't say for sure:

open/test/hotspot/jtreg/serviceability/sa
open/test/hotspot/jtreg/resourcehogs/serviceability/sa
open/test/jdk/sun/tools/jhsdb
open/test/jdk/sun/tools/jstack
open/test/jdk/sun/tools/jmap
open/test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
open/test/hotspot/jtreg/compiler/ciReplay/TestSAClient.java 
open/test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java

Chris

On 3/25/20 12:29 PM, Magnus Ihse Bursie wrote:
> With the recent fixes in JDK-8241310, JDK-8237746 and JDK-8241073, and 
> the upcoming fixes to remove the deprecated nashorn and jdk.rmi, the 
> JDK build is very close to producing no warnings when compiling the 
> Java classes.
>
> The one remaining sinner is jdk.hotspot.agent. Most of the warnings 
> here are turned off, but unchecked and deprecation cannot be 
> completely silenced.
>
> Since the poor agent does not seem to receive much love nowadays, I 
> took it upon myself to fix these warnings, so we can finally get a 
> quiet build.
>
> I started to address the unchecked warnings. Unfortunately, this was a 
> much bigger task than I anticipated. I had to generify most of the 
> module. On the plus side, the code is so much better now. And most of 
> the changes were trivial, just tedious.
>
> There are a few places were I'm not entirely happy with the current 
> solution, and that at least merits some discussion.
>
> I have resorted to @SuppressWarnings in four classes: ciMethodData, 
> MethodData, TableModelComparator and VirtualBaseConstructor. All of 
> them has in common that they are doing slightly fishy things with 
> classes in collections. I'm not entirely sure they are bug-free, but 
> this patch leaves the behavior untouched. I did some efforts to sort 
> out the logic, but it turned out to be too hairy for me to fix, and it 
> will probably require more substantial changes to the workings of the 
> code.
>
> To make the code valid, I have moved ConstMethod to extend Metadata 
> instead of VMObject. My understanding is that this is benign (and 
> likely intended), but I really need for someone who knows the code to 
> confirm this. I have also added a FIXME to signal this. I'll remove 
> the FIXME as soon as I get confirmation that this is OK.
> (The reason for this is the following piece of code from 
> Metadata.java: metadataConstructor.addMapping("ConstMethod", 
> ConstMethod.class))
>
> In ObjectListPanel, there is some code that screams "dead" with this 
> change. I added a FIXME to point this out:
>     for (Iterator<Oop> iter = elements.iterator(); iter.hasNext(); ) {
>       if (iter.next() instanceof Array) {
>         // FIXME: Does not seem possible to happen
>         hasArrays = true;
>         return;
>       }
> It seems that if you start pulling this thread, even more dead code 
> will unravel, so I'm not so eager to touch this in the current patch. 
> But I can remove the FIXME if you want.
>
> My first iteration of this patch tried to generify the IntervalTree 
> and related class hierarchy. However, this turned out to be impossible 
> due to some weird usage in AnnotatedMemoryPanel, where there seemed to 
> be confusion as to whether the tree stored Annotations or Addresses. 
> I'm not entirely convinced the code is correct, it certainly looked 
> and smelled very fishy. However, I reverted these changes since I 
> could not get them to work due to this, and it was not needed for the 
> goal of just getting rid of the warning.
>
> Finally, I have done no testing apart from verifying that it builds. 
> Please advice on suitable tests to run.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241618
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.01
>
> /Magnus




More information about the serviceability-dev mailing list