Actually, I left it now running further.. (with cmd file, using the
aggressiveheap, etc.)
After some time the following message occurs, so it indeed seems to be
a memory leak issue..

Exception occurred during event dispatching:
java.lang.OutOfMemoryError: Java heap space
        at java.lang.StringBuilder.toString(Unknown Source)
        at com.sun.java.swing.plaf.windows.TMSchema
$Part.getControlName(Unknown
Source)
        at com.sun.java.swing.plaf.windows.XPStyle
$SkinPainter.paintToImage(Unkn
own Source)
        at sun.swing.CachedPainter.paint0(Unknown Source)
        at sun.swing.CachedPainter.paint(Unknown Source)
        at com.sun.java.swing.plaf.windows.XPStyle
$Skin.paintSkinRaw(Unknown Sou
rce)
        at com.sun.java.swing.plaf.windows.AnimationController
$AnimationState.pa
intSkin(Unknown Source)
        at
com.sun.java.swing.plaf.windows.AnimationController.paintSkin(Unknown
 Source)
        at com.sun.java.swing.plaf.windows.XPStyle
$Skin.paintSkin(Unknown Source
)
        at
com.sun.java.swing.plaf.windows.WindowsButtonUI.paintXPButtonBackgrou
nd(Unknown Source)
        at
com.sun.java.swing.plaf.windows.WindowsButtonUI.paint(Unknown Source)

        at javax.swing.plaf.ComponentUI.update(Unknown Source)
        at javax.swing.JComponent.paintComponent(Unknown Source)
        at javax.swing.JComponent.paint(Unknown Source)
        at javax.swing.JComponent.paintToOffscreen(Unknown Source)
        at javax.swing.RepaintManager
$PaintManager.paintDoubleBuffered(Unknown S
ource)
        at javax.swing.RepaintManager$PaintManager.paint(Unknown
Source)
        at javax.swing.RepaintManager.paint(Unknown Source)
        at javax.swing.JComponent._paintImmediately(Unknown Source)
        at javax.swing.JComponent.paintImmediately(Unknown Source)
        at javax.swing.RepaintManager.paintDirtyRegions(Unknown
Source)
        at javax.swing.RepaintManager.paintDirtyRegions(Unknown
Source)
        at javax.swing.RepaintManager.seqPaintDirtyRegions(Unknown
Source)
        at javax.swing.SystemEventQueueUtilities
$ComponentWorkRequest.run(Unknow
n Source)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
Source)
        at java.awt.Dialog$1.run(Unknown Source)
        at java.awt.Dialog$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
Exception in thread "Thread-4" java.lang.OutOfMemoryError: Java heap
space
        at sun.util.resources.TimeZoneNames_de.getContents(Unknown
Source)
        at
sun.util.resources.OpenListResourceBundle.loadLookup(Unknown Source)
        at
sun.util.resources.OpenListResourceBundle.loadLookupTablesIfNecessary
(Unknown Source)
        at
sun.util.resources.OpenListResourceBundle.handleGetObject(Unknown Sou
rce)
        at
sun.util.resources.TimeZoneNamesBundle.handleGetObject(Unknown Source
)
        at java.util.ResourceBundle.getObject(Unknown Source)
        at java.util.ResourceBundle.getStringArray(Unknown Source)
        at sun.util.TimeZoneNameUtility.retrieveDisplayNames(Unknown
Source)
        at sun.util.TimeZoneNameUtility.retrieveDisplayNames(Unknown
Source)
        at java.util.TimeZone.getDisplayNames(Unknown Source)
        at java.util.TimeZone.getDisplayName(Unknown Source)
        at java.text.SimpleDateFormat.subFormat(Unknown Source)
        at java.text.SimpleDateFormat.format(Unknown Source)
        at java.text.SimpleDateFormat.format(Unknown Source)
        at java.text.DateFormat.format(Unknown Source)
        at
com.jbooktrader.platform.report.EventReport.report(EventReport.java:4
9)
        at
com.jbooktrader.platform.report.EventReport.report(EventReport.java:6
6)
        at
com.jbooktrader.platform.util.MessageDialog.showError(MessageDialog.j
ava:30)
        at
com.jbooktrader.platform.backtest.BackTestStrategyRunner.run(BackTest
StrategyRunner.java:49)
        at java.lang.Thread.run(Unknown Source)

On 6 Jun., 13:36, Klaus <[email protected]> wrote:
> Dear Eugene,
>
> made further experiments.
> If I run it directly with aggressiveHeap disabled (otherwise it takes
> too much memory),
> it is running even much earlier into trouble: backtest for defender1
> fine, but comes to a crawl
> (factor 10 and more slower) for defender2 backtest.
> (Java grows to ~300 MB)
>
> If I enable aggressiveheap, same picture: at ~49% of defender2 timelag
> becomes unbearable.
> Max size ~300 MB
>
> If I run it through eclipse with -Xmx512M it easily does defender1,
> defender2, Directional, ..
> slowing along the way and getting finally stuck with equalizer..
> Each of those it does very rapidly if I start directly with it.
> So, it is not a problem of the strategy, but rather there a very
> negative side effects after doing
> a backtest. And I am wondering what they might be..
> (Java grows to 550 MB)
>
> In all cases, the system is significantly slower already for the
> second backtest. The time when I said, I stop
> is basically when it requires dozens of second even for a single
> percentage point of progress. It can even become hard / impossible to
> stop the system, as everything hangs.
>
> Sorry, I am not a java guru. But to me this looks very much like for
> some reason the garbage collector can at some point not find enough
> space and is running over and over again. I would normally say some
> kind of memory leak: memory is not freed after running of a backtest.
> But I am not sure whether and how such things can happen with Java. It
> but is clear: the number of strategies you run
> with small problems depend on the total memory it is willing to use.
> Once it is getting close to the uper boundary
> (depending on parameters) the system increasingly stalls..
> - I only do not understand why required memory depends on strategies
> previously backtested.
>
> I am running Win7 32, 4GB (out of which 3 are available and ~1 is
> needed for the system, leaving 2GB for JBT max.)
> Installed is Java 6 Update 18 and Java SE Development Kit 6 Update 16.
> I understand that I can alleviate the problem by adding parameters
> that allow JBT to grab more memory.
> But it seems this only increases the number of systems I can run until
> it gets unusable, so I would
> consider this more a hack than a solution. The key issue seems to be:
> why are there so strong
> side-effects from previously run strategies?
>
> BTW. The problem does also seem to happen if I repeatedly run the same
> strategy.
> Strongly reducing the usefulness of backtesting (of course I can
> always stop the system and rerun it..)
>
> Thanks
>    Klaus
>
> On 6 Jun., 01:49, Eugene Kononov <[email protected]> wrote:
>
>
>
> > > (BTW, I start JBT directly from Eclipse)
>
> > JBT will run faster if you start it as a stand-alone process. See the script
> > in the /run directory.

-- 
You received this message because you are subscribed to the Google Groups 
"JBookTrader" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jbooktrader?hl=en.

Reply via email to