This cannot be answered in general, but following topics have impact on the memory:

1. XML parser technology in use: You should use a streaming parser like Xpp3 or StAX. DOM-based parsers process the complete XML and create their document model in memory before the first converter of XStream is called.
2. Your object model: Is it necessary to keep the complete object graph in memory at once? As alternative you might use object streams or write custom converters that can LOAD and save objects of your object model on the fly without adding them to the object graph physically. As example see the implementation of the XmlArrayList in COMBINATION with the FileStreamStrategy from XStream's persistence package to keep parts of the object graph separate.
3. REFERENCES: By default XStream supports references to the same object in an object graph. This IMPLIES that XStream keeps track of all serialized and deserialized objects internally. These references are kept with WeakReferences, so that the memory can be freed as soon as nobody references these objects anymore.
4. XML values: Any tag and attribute value that is converted into a Java String in the object graph will use by default the same String instance unless it exceeds 38 characters (length of a UUID string representation).
5. XStream caches: To increase performance XStream caches quite a lot like classes, converters to use, aliasing, tag names. All those caches make usage of WeakReferences or will exist only while marshalling one object graph resp. unmarshalling one input stream.

This cannot be answered in general, but following topics have impact on the memory: