Switch from 1.10.19 to 3.8.0 produces OutOfMemoryError

[Norbert Kiesel]

Hi,

I am attempting to convert a rather large system from Mockito 1.10.19 to Mockito 3.8.0.  This system also uses PowerMock extensively, and I upgraded PowerMock from 1.6.4 to 2.0.9.

This broke quite a few tests, mostly because of anyXXX no longer matching null (which is a change I overall like). I had some other hickups. One was that we had a mock for a method expecting a long using anyInt().  Test code called the method with a long value, but Mockito1 intercepted this. Mockito3 no longer does that. Changing the matcher to anyLong() solved this issue.

But now I am stuck with OutOfMemoryError cases.  I added Mockito.framework().clearInlineMocks() calls to @After of all 200+ test classes, but the memory error still exists.  Gradle JVM settings are `-Xmx4g -XX:MaxMetaspaceSize=512m -XX:MaxPermSize=4g` and this works for Mockito1.

Any suggestions?

[Tim van der Lippe]

Could you follow the steps listed in https://github.com/mockito/mockito/issues/2178#issuecomment-764620097 to figure out where most memory is used?

Op do 1 apr. 2021 om 22:12 schreef Norbert Kiesel <nki...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "mockito" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mockito+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mockito/e3c7bb4d-5d0e-4ecd-8fb6-5b06524a3052n%40googlegroups.com.

[Norbert Kiesel]

Other Q: that thread also contains the suggestion to invoke clearAllCaches().  Is that something worth trying?  I assume I could put it in @AfterClass.

[Norbert Kiesel]

Looks like you want me to create a performance trace using e.g. visualvm.  How do I do that for a gradle run?  -- no-daemon  should do the trick, correct?

On Thursday, April 1, 2021 at 2:52:29 PM UTC-7 tvande...@gmail.com wrote:

[Tim van der Lippe]

Yes I think `clearAllCaches` might be helpful.

There are some instructions listed at https://htmlpreview.github.io/?https://raw.githubusercontent.com/visualvm/visualvm.java.net.backup/master/www/applications_local.html on how you can attach VisualVM to a running local Java application (in this case a Gradle test run).

Op vr 2 apr. 2021 om 09:38 schreef Norbert Kiesel <nki...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/mockito/354ccac8-c39b-4a91-a1d4-19f882179069n%40googlegroups.com.

[John Guin]

This might not be useful so keep that in mind - this especially won't help track any memory usage problems.

I also converted a large test project from Mockito 2.x to 3.7. 

We also used Powermockito and after a few weeks of trying to get both tools to work together, I decided it would be easier to just deprecate powermockito at the same time. To be clear, I was not seeing any memory errors: just errors such as ClassNotFound and NPEs.  

I could get past some of these errors by changing the order of the dependencies in the POM, but that felt very fragile and didn't seem like it was addressing the root cause of the two tools conflicting.  Even once I had the existing suite working, any new usage of Mockito would cause the previous errors to resurface.  Instead of trying to track down why the two frameworks did not work together, I decided to remove PowerMockito at the same time as updating to Mockito 3.7.7

This actually worked and moved us to (just) Mockito 3.7.7.  The advantages were:
1. we now have just one mocking framework to use and support

2. the conversion got done much more quickly (than if I had spent time trying to track down the conflicts)

Again, this is a little negative and doesn't benefit isolating any defects in mockito or powermockito.  I just thought I would share what I had to do to get a similar update completed.