Hi Jochen
Thanks for your feedback -
Yes I like the idea of perhaps using 2 factory implementations, but I think
there is a strong argument that the default factory should intern -
Perhaps there are some reasons not to intern which I am not aware of (I am
sure people will make me aware shortly!)
Here is the rationale - as I see it:
Our application will run with approximately 1/5th of the previous memory
with the interns in (which is the difference between total success of the
project and total failure)
I think this may not be all that unusual, since I guess applications using
XML RPC will tend to send a lot of Strings across.
There may be a small performance penalty from intern due to the native
synchronization performed around by intern calls, but I think this is
probably a very small decrease (perhaps 1%, we could test this?)
Is the peformance issue the only reason not to intern?
If so it seems to me that the memory consumption issue outweighs this, and
in most cases it may be better to go a little slower than to run out of
memory and have the app crash.
I suppose the other potential issue might be the VM holding on to interned
strings and not releasing them for GC:
So far as I understand, although the Java spec does not mandate that the
virtual machine garbage collects interned strings, in practise VMs do this
OK, once there are no reachable references -
so there should be no issue with interned strings hogging memory
unnecessarily.
Certainly this is the case for us using Sun's JDK1.4.2_04
Could you let me know what you think regarding the above and have I missed
some obvious drawback of intern()?
As suggested, I will post issues in separate threads in future and will use
context diffs.
Nick
---------------------- Forwarded by Nick EBBUTT/UK/EUROPE/GROUP on
05/10/2005 17:03 ---------------------------
05/10/2005 09:37 Rory MCGARRIGLE
ValRisk
London
Fixed Income
10 Harewood Ave
tel : +44 207 595 4792 fax : +44 207 595 5070
------------------------------------------------------------
To: Nick EBBUTT
cc:
Subject: Fw: [PATCH] suggested patches for memory issues
Dunno why he's sending me this !
---------------------- Forwarded by Rory MCGARRIGLE/UK/EUROPE/GROUP on
05/10/2005 09:36 ---------------------------
Internet
[EMAIL PROTECTED] - 04/10/2005 22:05
To: xmlrpc-dev
cc: Rory MCGARRIGLE
Subject: Re: [PATCH] suggested patches for memory issues
Hi, Rory,
first of all, I support Henri's suggestion to post context diffs.
Besides, I strongly advice you to split your suggestions into various
separate postings, that can be handled one by one. Even better: How
about opening a Jira issue for each separate item?
Regardless of the above, here are my impressions:
> The class XmlRpcClientResponseProcessor currently fails to set the field
> 'result' to null at the end of the decodeResponse method.
I understand, that this has no side effects and will possibly help in
rare situations. No problem to accept.
> We had a memory problem caused by Strings in our client application not
> being interned, and made some changes so that the XML RPC processor
> interned Strings (both values and the keys in Maps).
To me, the value of intern() depends *very* clearly on the application.
Other applications will definitely see a negative impact.
I'd vote against a mandatory change. A flag "useIntern" or whatever
seems very special. Do you see a chance to change your patch along the
following line:
- All required handling is done in the type factory.
- The DefaultTypeFactory works basically as it is now.
- There is a new InterningTypeFactory which does what you want
Jochen
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
**********************************************************************************************
BNP Paribas Private Bank London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Fund Services UK Limited is authorised and
regulated by the Financial Services Authority.
