You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Cleber Muramoto (JIRA)" <ji...@apache.org> on 2015/11/12 00:47:11 UTC
[jira] [Updated] (WICKET-6033) [Possible Memory Leak]RepeatingView
Should not use String.intern
[ https://issues.apache.org/jira/browse/WICKET-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cleber Muramoto updated WICKET-6033:
------------------------------------
Description:
RepeatingView uses String.intern in order to generate sequential ids.
There are two problems with this approach:
1)It doesn't actually prevent Object allocation (A new String is created before it is replaced by the interned one)
2)It can fill the JVM StringTable (whose size can be configured with -XX:StringTableSize)
Usually the counter will not grow too large, however when using AjaxSelfUpdatingBehavior this might happen.
Let's suppose one have has to provide a screen which displays a self-updating table with about 30 rows, to an user with no session timeout. Every Ajax update will cause 30 new ids to be generated, unless the RepeatingView is re-created from scratch. If the refresh rate is about 10s, in a 24h period that little repeater will cause 259200 strings to be interned!
I think that it might be better if Wicket used an id cache in order to optimize the mapping int->String.
public static final String[] IDS = new String[Integer.getInteger("some_property", 1024)];
public static final String id(final int ix) {
String id = null;
if (ix < IDS.length) {
id = IDS[ix];
if (id == null) {
id = String.valueOf(ix);
IDS[ix] = id;
}
} else {
id = String.valueOf(ix);
}
return id;
}
This approach would prevent Object allocation and won't mess with JVM String table.
was:
RepeatingView uses String.intern in order to generate sequential ids.
There are two problems with this approach:
1)It doesn't actually prevent Object allocation (A new String is created before it is replaced by the interned one)
2)It can fill the JVM StringTable (whose size can be configured with -XX:StringTableSize)
Usually the counter will not grow too large, however when using AjaxSelfUpdatingBehavior this might happen.
Let's suppose one have has to provide a screen which displays a self-updating table with about 30 rows, to an user with no session timeout. Every Ajax update will cause 30 new ids to be generated, unless the RepeatingView is re-created from scratch. If the refresh rate is about 10s, in a 24h period that little repeater will cause 259200 strings to be interned!
I think that it might be better if Wicket used an id cache in order to resolve to map int->String.
public static final String[] IDS = new String[Integer.getInteger("some_property", 1024)];
public static final String id(final int ix) {
String id = null;
if (ix < IDS.length) {
id = IDS[ix];
if (id == null) {
id = String.valueOf(ix);
IDS[ix] = id;
}
} else {
id = String.valueOf(ix);
}
return id;
}
This approach would prevent Object allocation and won't mess with JVM String table.
> [Possible Memory Leak]RepeatingView Should not use String.intern
> ----------------------------------------------------------------
>
> Key: WICKET-6033
> URL: https://issues.apache.org/jira/browse/WICKET-6033
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 7.1.0
> Reporter: Cleber Muramoto
> Priority: Trivial
>
> RepeatingView uses String.intern in order to generate sequential ids.
> There are two problems with this approach:
> 1)It doesn't actually prevent Object allocation (A new String is created before it is replaced by the interned one)
> 2)It can fill the JVM StringTable (whose size can be configured with -XX:StringTableSize)
> Usually the counter will not grow too large, however when using AjaxSelfUpdatingBehavior this might happen.
> Let's suppose one have has to provide a screen which displays a self-updating table with about 30 rows, to an user with no session timeout. Every Ajax update will cause 30 new ids to be generated, unless the RepeatingView is re-created from scratch. If the refresh rate is about 10s, in a 24h period that little repeater will cause 259200 strings to be interned!
> I think that it might be better if Wicket used an id cache in order to optimize the mapping int->String.
> public static final String[] IDS = new String[Integer.getInteger("some_property", 1024)];
> public static final String id(final int ix) {
> String id = null;
> if (ix < IDS.length) {
> id = IDS[ix];
> if (id == null) {
> id = String.valueOf(ix);
> IDS[ix] = id;
> }
> } else {
> id = String.valueOf(ix);
> }
> return id;
> }
> This approach would prevent Object allocation and won't mess with JVM String table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)