[
http://issues.apache.org/jira/browse/XALANJ-2344?page=comments#action_12450973
]
Brian Minchau commented on XALANJ-2344:
---------------------------------------
I did not approve ElemTextLiteral.patch.txt
The old code is this:
public synchronized String getNodeValue()
{
if(null == m_str)
{
m_str = new String(m_ch);
}
return m_str;
}
Which causes less object churn (only one m_str is created) but at the cost of
synchronization.
Toadie's suggestion is:
public String getNodeValue()
{
return new String(m_ch);
}
which has no synchronization, but which causes object churn. Given that his
performance problem is
related to intel dual-processor and JRE 5 and synchronization I am not so keen
to apply this patch as he
has reported that the IBM JRE 5 does not have nearly the same synchronization
bottleneck.
It is curious that these methods:
public void setChars(char[] v) { m_ch = v; }
public char[] getChars() { return m_ch; }
are not synchronized. Only getNodeValue() and probably only to avoid creating
too many Strings in different threads.
According to the Java Language Specification, Chapter 17 "Threads and Locks" it
says this:
<<
When a thread uses the value of a variable, the value it obtains is in fact a
value stored into the
variable by that thread or by some other thread. This is true even if the
program does not
contain code for proper synchronization ... the variable will subsequently
contain a reference
to one object or the other, not a reference to some other object, or a
corrupted reference value.
>>
I think the 'synchronized' keyword can be dropped from getNodeValue() ... who
cares if
a few extra Strings are created from the same m_ch array. A String is
immutable, and all one can do is compare string or extract value from it. Code
such as if( s1.equals(s2)) is good form, code such as if (s1 == s2) is bad
form with with Strings.
So I think there are two things that need to be done.
1) Make m_ch 'volatile' so that when a thread uses, or assigns a value that
value is coming from main memory, not a value that the thread has cached. In
this way when one thread assigns a value to m_ch they all see it.
2) Drop the synchronize keyword from getNodeValue(). If m_ch is volatile all
threads will get the previously assigned value, however this doesn't impact the
code much since each thread checks m_str against null and only uses m_ch at
most once when creating a String to assign to m_str. Threads might not share
the value they have for their copy of m_str, but who cares, just a little extra
object churn, but not much, just one String per thread.
> Xalan-J should stop using java.util.Vector in some cases (NOT a clone of 2336)
> ------------------------------------------------------------------------------
>
> Key: XALANJ-2344
> URL: http://issues.apache.org/jira/browse/XALANJ-2344
> Project: XalanJ2
> Issue Type: Improvement
> Components: Xalan
> Affects Versions: Latest Development Code
> Reporter: Toadie D
> Attachments: ElemLiteralResult.patch.txt, ElemTextLiteral.patch.txt,
> ElemUse.patch.txt, StylesheetRoot+XSLTSchema.patch.txt,
> StylesheetRoot.patch.txt
>
>
> ref: https://issues.apache.org/jira/browse/XALANJ-2336
> This bug is related to 2336 but is NOT a clone. The patches provided here
> are in addition to the ones in 2336. Furthermore, these patches are created
> AFTER the patch in 2336 are applied.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
