These changes look good. I agree that the Developer's Guide doesn't have any pre-existing sections which fit this topic. I think your additions to the Reference and Tuning guides are sufficient.
Some other comments follow...
statements kept in memory -> prepared statements kept in memory
I would add more description to the Function section:
"For more information on the statement cache, see the 'Using the statement cache' subsection of the Derby Tuning Guide.
This property controls the number of pre-compiled statements which Derby keeps in its statement cache. Consider raising this number if statement preparation is taking too much time."
If you are going to include the paragraph about setting the property to 0, then I would add a comment to
DERBY-4279 so that we will remember to remove that paragraph after we fix that issue.
Similar comments: The real point of adjusting derby.language.statementCacheSize is to reduce the amount of time spent preparing statements. The property lets you balance preparation time against the memory consumed by pre-compiled statements. Setting the property to 0 is a hack which works around the bug described by
DERBY-4279. When that bug is fixed, we should stop talking about the hack.