Memory Leaks
Kevin Rushforth
kevin.rushforth at oracle.com
Mon Oct 22 05:26:45 PDT 2012
To elaborate on this a bit...
With every JDK 7-update release there will be a corresponding JavaFX
release. There are only a few security bug fixes in 2.2.3 beyond what is
in 2.2.0 -- functionally they are the same, which is why there was no
big announcement.
With the recent release renaming(s) you almost need a secret decoder
ring or a Rosetta stone to keep track of them, but basically it is this:
JDK 7u10 / FX 2.2.4 -- very limited update release in December; any bug
that isn't already fixed and doesn't cause your computer to catch fire
isn't going to make this release.
JDK 7u11 / FX 2.2.5 -- security release in February
JDK 7u12 / FX 2.2.6 -- limited update release next spring (I'm not sure
if the exact dates are nailed down); this is the next opportunity for
non-security-related critical bug fixes. A memory leak would be a good
candidate for this.
As Jonathan indicated, our resources are focused on FX 8, but there is
an opportunity to fix a few of the more serious bugs in 2.2.6.
-- Kevin
Scott Palmer wrote:
> Thanks for the response. 8.0 is too far away. I need to ship my app in a
> few weeks. 2.2.3 may be old to you guys, but I just found 2.2.3
> yesterday. We were on 7u7 and then I discovered that there was a new
> JavaFX runtime in 7u9.. Would have been nice to know! 7u7 shipped not too
> long ago with 2.2.0 and I didn't see any sort of announcements that there
> was anything newer.
>
> I will try to isolate the leak. We think we are seeing
> com.sun.javafx.css.StyleHelper$CacheEntry and
> com.sun.javafx.css.StyleHelper$CalculatedValue leaking (at least).
>
> jvisualvm shows the number of those objects are always growing. Comparing
> heap dumps we have never observed the number to decrease.
>
> I'm currently only able to connect to the machine running my test via
> Remote Desktop, and the screen saver probably keep kicking in, I think that
> is affecting the test. Is JavaFX smart enough to not render when the
> screen is blanked?
>
> I will try to produce a test case. But if anyone has knowledge about this
> that wants to share, any info is appreciated.
>
> Thanks,,
> Scott
>
> On Sat, Oct 20, 2012 at 5:16 PM, Jonathan Giles
> <jonathan.giles at oracle.com>wrote:
>
>
>> David Grieve is the go-to expert on all things CSS, but from a
>> higher-level perspective the general answer is always: you tell us! :-)
>> There might be a leak we don't know about, or can't easily reproduce, and
>> you might have just the information we need to finally get rid of that
>> annoying leak you mention.
>>
>> So, please, file Jira bugs on us and we'll get to looking at them as soon
>> as possible. If you can provide a reproducible test case that would be
>> hugely appreciated too.
>>
>> Finally, from our point of view JavaFX 2.2.3 is rather old code - we've
>> been actively developing in the 8.0 branch for quite a long time now, and
>> one of our primary focuses during this time has been performance (CPU and
>> memory). In other words, there is a chance it may already be resolved (or
>> minimised) in the 8.0 branch. I know it is a lot to ask, but there are 8.0
>> builds available that you can test with. If you have the time and
>> inclination, it might be worth testing against these builds to see if it is
>> resolved.
>>
>> Thanks,
>> -- Jonathan
>>
>>
>> On 21/10/2012 2:10 a.m., Scott Palmer wrote:
>>
>>
>>> Are there known leaks in 2.2.3 with regards to CSS and style cache stuff?
>>> In my application I add and remove style classes to highlight objects in
>>> the scene graph that are in various states (selected, active, disabled,
>>> etc). It seems that every time the style class list is changed that there
>>> is a small leak. Since while the app runs and process data (a process that
>>> may run indefinitely) the state of objects in the graph changes as data is
>>> processed, this is a significant issue. Our customers may have the app
>>> fail after several hours or a few days because of these leaks.
>>>
>>> Scott
>>>
>>>
>>
More information about the openjfx-dev
mailing list