[jira] [Resolved] (WICKET-6033) [Possible Memory Leak]RepeatingView Should not use String.intern

["Martin Grigorov (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-6033.
-------------------------------------
    Resolution: Won't Fix

Thank you for the ticket!

I'll close it as "Won't fix" due to the following reasons:
- as the article linked by Sven explains the internals of String#intern() are greatly improved since JDK 7_40.
- even with Wicket 6.x most deployments out there actually use Java 7+.
- AbstractItem uses String#intern() since a very long time. The introduction of #intern() in RepeatingView is 3 years old now. So far no one had real problems due to this
- as the article explains there is a way to create a bigger StringTable by using JVM options, so there is no need of custom properties

> [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
>            Assignee: Martin Grigorov
>            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 wouldn't mess with JVM's String table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)