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/compiler/ciReplay/TestSAClient.java open/test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java


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;
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


Reply via email to