[
https://issues.apache.org/jira/browse/TAP5-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikkie Folts updated TAP5-2694:
-------------------------------
Description:
I have completed a memory profile of our Tapestry application, and found that
the PlasticClassPool & PropBinding have lots of duplicate Strings in memory.
h2. PropBinding
Seems that both the `toString` and `expression` constructor parameters of
PropBinding should be interned in the constructor.
!Screen Shot 2021-09-30 at 4.58.19 PM.png!
h2. PlasticClassPool
After some investigation, it seems that the `InheritanceData#getValue()` method
is the likely culprit.
h4. Example Strings:
"toString:()"
"get:(Ljava/lang/Object;)"
"getPropertyName:()"
h4. The current method:
{code:java}
/**
* Combines a method name and its desc (which describes parameter types and
return value) to form
* a value, which is how methods are tracked.
*/
private static String toValue(String name, String desc)
{
// TAP5-2268: ignore return-type to avoid methods with the same number
(and type) of parameters but different
// return-types which is illegal in Java.
// desc is something like "(I)Ljava/lang/String;", which means: takes
an int, returns a String. We strip
// everything after the parameter list.
int endOfParameterSpecIdx = desc.indexOf(')');
return name + ":" + desc.substring(0, endOfParameterSpecIdx+1);
}
{code}
h4. The change is simple one-liner to the return statement:
{code}
return (name + ":" + desc.substring(0, endOfParameterSpecIdx+1)).intern();
{code}
h2. PageElementFactoryImpl$LiteralStringProvider
The constructor for LiteralStringProvider should intern the string.
h2. Also, Duplicate InheritanceData
The profile also showed that there are lots of "duplicate" InheritanceData
objects... the interning will help with their size, but why have so many
duplicate?
was:
I have completed a memory profile of our Tapestry application, and found that
the PlasticClassPool & PropBinding have lots of duplicate Strings in memory.
h2. PropBinding
Seems that both the `toString` and `expression` constructor parameters of
PropBinding should be interned in the constructor.
!Screen Shot 2021-09-30 at 4.58.19 PM.png!
h2. PlasticClassPool
After some investigation, it seems that the `InheritanceData#getValue()` method
is the likely culprit.
h4. Example Strings:
"toString:()"
"get:(Ljava/lang/Object;)"
"getPropertyName:()"
h4. The current method:
{code:java}
/**
* Combines a method name and its desc (which describes parameter types and
return value) to form
* a value, which is how methods are tracked.
*/
private static String toValue(String name, String desc)
{
// TAP5-2268: ignore return-type to avoid methods with the same number
(and type) of parameters but different
// return-types which is illegal in Java.
// desc is something like "(I)Ljava/lang/String;", which means: takes
an int, returns a String. We strip
// everything after the parameter list.
int endOfParameterSpecIdx = desc.indexOf(')');
return name + ":" + desc.substring(0, endOfParameterSpecIdx+1);
}
{code}
h4. The change is simple one-liner to the return statement:
{code}
return (name + ":" + desc.substring(0, endOfParameterSpecIdx+1)).intern();
{code}
The profile also showed that there are lots of "duplicate" InheritanceData
objects... the interning will help with their size, but why have so many
duplicate?
> Tapestry PlasticClassPool & PropBinding & LiteralStringProvider make
> thousands of duplicate strings
> ---------------------------------------------------------------------------------------------------
>
> Key: TAP5-2694
> URL: https://issues.apache.org/jira/browse/TAP5-2694
> Project: Tapestry 5
> Issue Type: Improvement
> Components: plastic
> Affects Versions: 5.7.3
> Reporter: Nikkie Folts
> Assignee: Thiago Henrique De Paula Figueiredo
> Priority: Major
> Attachments: Screen Shot 2021-09-29 at 4.02.26 PM.png, Screen Shot
> 2021-09-29 at 4.03.04 PM.png, Screen Shot 2021-09-29 at 5.23.53 PM.png,
> Screen Shot 2021-09-30 at 4.58.19 PM.png, Screen Shot 2021-10-04 at 2.07.35
> PM.png
>
>
> I have completed a memory profile of our Tapestry application, and found that
> the PlasticClassPool & PropBinding have lots of duplicate Strings in memory.
> h2. PropBinding
> Seems that both the `toString` and `expression` constructor parameters of
> PropBinding should be interned in the constructor.
> !Screen Shot 2021-09-30 at 4.58.19 PM.png!
> h2. PlasticClassPool
> After some investigation, it seems that the `InheritanceData#getValue()`
> method is the likely culprit.
> h4. Example Strings:
> "toString:()"
> "get:(Ljava/lang/Object;)"
> "getPropertyName:()"
> h4. The current method:
> {code:java}
> /**
> * Combines a method name and its desc (which describes parameter types
> and return value) to form
> * a value, which is how methods are tracked.
> */
> private static String toValue(String name, String desc)
> {
> // TAP5-2268: ignore return-type to avoid methods with the same
> number (and type) of parameters but different
> // return-types which is illegal in Java.
> // desc is something like "(I)Ljava/lang/String;", which means: takes
> an int, returns a String. We strip
> // everything after the parameter list.
> int endOfParameterSpecIdx = desc.indexOf(')');
> return name + ":" + desc.substring(0, endOfParameterSpecIdx+1);
> }
> {code}
> h4. The change is simple one-liner to the return statement:
> {code}
> return (name + ":" + desc.substring(0, endOfParameterSpecIdx+1)).intern();
> {code}
> h2. PageElementFactoryImpl$LiteralStringProvider
> The constructor for LiteralStringProvider should intern the string.
> h2. Also, Duplicate InheritanceData
> The profile also showed that there are lots of "duplicate" InheritanceData
> objects... the interning will help with their size, but why have so many
> duplicate?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
