BeanUtils.copyProperties() consumes large amount of memory

[HashJang]

After upgrade from 5.2.x to 5.3.x, we observed large increase in YoungGC caused by huge amount of object created. After test we found that is because BeanUtils.copyProperties().

In 5.3.x, using ResolvableType to increase fitness but there is no cache which would cause there are many ResolvableType objects created and result in large memory consuming. And there is a comparasion:

TestBean testBean1 = new TestBean("1", "2", "3", "4", "5", "6", "7", "8", "1", "2", "3", "4", "5", "6", "7", "8");
TestBean testBean2 = new TestBean();
for (int i = 0; i > -1; i++) {
    BeanUtils.copyProperties(testBean1, testBean2);
    System.out.println(i);
}

the VM option is -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx512m, the program will exit when the memory run out.

For 5.2.x, the last i is:

444489

For 5.3.x, the last i is:

27456

That's a huge memory consuming.

[alefq]

Can you post your TestBean source code? What JDK version are you using?

I'm not a spring framework contributor, just trying to help with triage; you could fork the repo; and adapt the unit test to your scenario.

Running corresponding test on both versions, time for test execution is less than 0.0s :

• v5.2.16.RELEASE

spring-framework/spring-beans$ gradle -v

------------------------------------------------------------
Gradle 5.6.4
------------------------------------------------------------

Build time:   2019-11-01 20:42:00 UTC
Revision:     dd870424f9bd8e195d614dc14bb140f43c22da98

Kotlin:       1.3.41
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.14 compiled on March 12 2019
JVM:          11.0.11 (Ubuntu 11.0.11+9-Ubuntu-0ubuntu2)
OS:           Linux 5.11.0-25-generic amd64

Time:

  <testcase name="testCopyProperties()" classname="org.springframework.beans.BeanUtilsTests" time="0.0"/>

• v5.3.9

------------------------------------------------------------
Gradle 6.8.1
------------------------------------------------------------

Build time:   2021-01-22 13:20:08 UTC
Revision:     31f14a87d93945024ab7a78de84102a3400fa5b2

Kotlin:       1.4.20
Groovy:       2.5.12
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM:          11.0.11 (Ubuntu 11.0.11+9-Ubuntu-0ubuntu2)
OS:           Linux 5.11.0-25-generic amd64

Time

  <testcase name="copyProperties()" classname="org.springframework.beans.BeanUtilsTests" time="0.0"/>

[HashJang]

I am sorry, but I'm afraid that you did not get what I was meaning.

I want to point out that there were large amount of objects created by BeanUtils.copyProperties() after upgrade(And the object is ResolvableType Indeed).

By the way, the TestBean has only 16 String field with getter and setter.

And in my test, I set JVM flag as -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx512m which means the program will exit when the 512m memory run out and there would not be any GC. The memory run out after 444489 loops for 5.2.x, but 27456 loops for 5.3.x. Therefore, it would cause rather high YoungGC pressure if we switch from 5.2.x to 5.3.x.

[alefq]

I'm trying to help with triage, help the community.
Normally you would need a unit test (TDD) or a consistent case to reproduce the issue.
BeanUtils rely heavily on introspection, uses cache techniques; profiling might be the way to pinpoint the problem; but a test case scenario is needed.
By using experimental VM options; you are in a very specific case; normally the issue should be reproduced with production ready environment; when making a library it is customary to use the most stable tech stack possible.
This is what triage is all about.
Regards.

[HashJang]

Thanks for reply.

BeanUtils rely heavily on introspection, uses cache techniques; profiling might be the way to pinpoint the problem; but a test case scenario is needed.

I checked the source code for 5.3.x, there is no cache for ResolvableType currently which result in Many ResolvableType objects are created while make one call of BeanUtils.copyproeperties

By using experimental VM options; you are in a very specific case; normally the issue should be reproduced with production ready environment; when making a library it is customary to use the most stable tech stack possible.

That's not the point. After upgrade to Spring 5.3.x, we observed large increase in YoungGC frequency (Before upgrade: One YoungGC in every 20s; After upgrade: One YoungGC in every 1s). The objects created(not promoted) is increased from 200MB/s to nearly 2GB/s. Therefore I tried to find the problem and then I found very large amount of ResolvableType objects were created which took up large amount of memory. To prove that, I provided a simple Test here which use Experimental flags (just for limiting the memory and proving there are much more memory used than before). And my Test prove that there are large amount of memory consumed compared with the case not upgraded (If you check jmap -histo, you would find they are taken up mainly by ResolvableType).

[373616885]

It not only consumes a lot of memory, but also has a lot of performance degradation

[quaff]

Please investigate which commit from history cause such regression.

[aiolosgs]

found in e74f868.
BTW, is there any alternatives to BeanUtils.copyProperties?

[quaff]

found in e74f868. BTW, is there any alternatives to BeanUtils.copyProperties?

@sbrannen Could you take a look at this, It seems this commit causes performance regression.

[sdeleuze]

@sbrannen I lack of context to be able to analyze efficiently this potential performance regression, could you please take care of it? The data points shared are pretty significant, so it is IMO worth a deeper look.