System.gc

There are a few calls to this scattered around the codebase, mostly after OutOfMemoryError, but also in

AlignFrame.copy_actionPerformed()

Desktop.internalFrameClosed()

Desktop.closeAll_actionPerformed()

OverviewCanvas.draw()

I’m not sure there is ever a good reason to call this routinely. I noticed that if you open a large alignment, then open any panel (say Feature Settings, or PCA Chooser) and then close it, there is a very noticeable pause, and jvisualvm shows a big spike in CPU and GC. It seems to behave like a blocking call to gc() rather than the usual background thread behaviour. Commenting out the call in Desktop.internalFrameClosed() removes the delay. Should we get rid of it?

Mungo

The University of Dundee is a registered Scottish Charity, No: SC015096

···

Email signature

University of Dundee shield logo

Mungo Carstairs
Jalview Computational Scientist

The Barton Group
Division of Computational Biology

School of Life Sciences

University of Dundee, Dundee, Scotland, UK

www.jalview.org

www.compbio.dundee.ac.uk
g.m.carstairs@dundee.ac.uk

University of Dundee FacebookUniversity of Dundee TwitterUniversity of Dundee LinkedInUniversity of Dundee YouTubeUniversity of Dundee InstagramUniversity of Dundee Snapchat
We’re Scottish University of the Year again!
The Times / Sunday Times Good University Guide 2016 and 2017

There are a few calls to this scattered around the codebase, mostly after OutOfMemoryError, but also in

AlignFrame.copy_actionPerformed()

Desktop.internalFrameClosed()

Desktop.closeAll_actionPerformed()

OverviewCanvas.draw()

some of these were historical. Pre java 1.5, calling System.gc explicitly was common - and in the copy action in particular, it tended to save OOM errors, but that was before the ‘correct’ gc of Java 1.8 onwards.

I’m not sure there is ever a good reason to call this routinely. I noticed that if you open a large alignment, then open any panel (say Feature Settings, or PCA Chooser) and then close it, there is a very noticeable pause, and jvisualvm shows a big spike in CPU and GC. It seems to behave like a blocking call to gc() rather than the usual background thread behaviour. Commenting out the call in Desktop.internalFrameClosed() removes the delay. Should we get rid of it?

https://stackoverflow.com/questions/2414105/why-is-it-bad-practice-to-call-system-gc

Explicit GC shouldn’t be needed - a minor task would be to get rid of these. We could even consider GC tuning if you think its worth it, but I suspect there are other problems.

The one exception is in benchmarking of course, when an unexpected GC would affect timings.

j.

The University of Dundee is a registered Scottish Charity, No: SC015096

···

On 04/12/2017 16:53, Mungo Carstairs (Staff) wrote: