[DESCOBERTO, BUG!] JavaFx consome memória RAM até travar no kernel 4.4.3-300 Fedora 23

Uma viagem, simplesmente atualizei o fedora, aí veio com o kernel 4.3-300.
Achei tudo indo até que quando eu abro o netbeans e rodo meu app em javafx. #F****! O bicho começa a consumir RAM até travar.
Segue o link abaixo do vídeo.
https://youtu.be/mfgZo1bKiRI

Aguém passando por isso também? O que fez? Como proceder? Será que vou ficar no fedora só um dia... rsrsrr,

Grato.

Me parece que o Fedora é o ofendido e não o ofensor. Já analisou se está ocorrendo "Out of Memory" nos logs do netbeans?

Já sim, tudo certo com o netbeans, apenas com o uso de tasks javafx que acontece isso.
AGora que terminou o upload do vídeo, bica só!
[youtube]https://youtu.be/mfgZo1bKiRI[/youtube]

se você utilizar a opção -Dprism.verbose=true na execução de qualquer app java que faça uso de threads e que tenha um visual mais refinado, perceberá que a aceleração por hardware vem habilitado como primeira opção. Logo basta desabilitar, utilizando a -Dprism.order=sw,j2d e já resolverá o problema de vazamento de memória.

Farei um vídeo comparando as opções para que fique claro o que estou passando, realmente não é problema do Fedora em si. Mas sim da versão do openGL/Mesa/Driver VGA intel.

Isto é muito importante além de muito grave.
O que deve receber correção: o JavaFX ou o kernel do Fedora?

----------------------------------------------------------------------------------------------------------------
http://24.media.tumblr.com/tumblr_m62bwpSi291qdlh1io1_250.gif

Creio que seja a javafx. Pois quando eu atualizei o manjaro linux em um outro pc para kernel 4.3.x, lembro-me de perceber o mesmo problema. Ao executar um app javafx, java -Dprism.verbose=true Ensemble8.jar, por exemplo. Ele mostra o seguinte:

Prism pipeline init order: es2 sw 

Using java-based Pisces rasterizer

Using dirty region optimizations

Not using texture mask for primitives

Not forcing power of 2 sizes for textures

Using hardware CLAMP_TO_ZERO mode

Opting in for HiDPI pixel scaling

Prism pipeline name = com.sun.prism.es2.ES2Pipeline

Loading ES2 native library ... prism_es2

	succeeded.

GLFactory using com.sun.prism.es2.X11GLFactory

(X) Got class = class com.sun.prism.es2.ES2Pipeline

Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline

Maximum supported texture size: 8192

Maximum texture size clamped to 4096

Non power of two texture support = true

Maximum number of vertex attributes = 16

Maximum number of uniform vertex components = 16384

Maximum number of uniform fragment components = 16384

Maximum number of varying components = 128

Maximum number of texture units usable in a vertex shader = 32

Maximum number of texture units usable in a fragment shader = 32

Graphics Vendor: Intel Open Source Technology Center

       Renderer: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 

        Version: 3.0 Mesa 11.1.0 (git-525f3c2)

 vsync: true vpipe: true

ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag

ES2ResourceFactory: Prism - createStockShader: FillPgram_LinearGradient_PAD.frag

ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag

new alphas

ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag

PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4

ES2ResourceFactory: Prism - createStockShader: Texture_LinearGradient_PAD.frag

ES2ResourceFactory: Prism - createStockShader: FillRoundRect_LinearGradient_PAD.frag

new alphas

new alphas

ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag

ES2ResourceFactory: Prism - createStockShader: Solid_TextureSecondPassLCD.frag

ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag

ES2ResourceFactory: Prism - createStockShader: FillRoundRect_Color.frag 

Fica claro as informações do renderizador gráfico:
Graphics Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
Version: 3.0 Mesa 11.1.0 (git-525f3c2)

Já executando de forma a desabilitar a aceleração por hardware[ java -Dprism.verbose=true -Dprism.order=sw,j2d -jar Ensemble8.jar ] temos a seguinte saída:
Prism pipeline init order: sw j2d
Using java-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
*** Fallback to Prism SW pipeline
Prism pipeline name = com.sun.prism.sw.SWPipeline
(X) Got class = class com.sun.prism.sw.SWPipeline
Initialized prism pipeline: com.sun.prism.sw.SWPipeline
vsync: true vpipe: false


Sei que no Ubuntu 14.04 com o kernel 4.2.xx não acontece o problema.
Outro detalhe interessante ao observar é que geralmente o estouro de memória acontece se vc estiver utilizando alguma Thread do javafx na amistosidade de seu app, como carregar informações em segundo plano em um gráfico, ou um progressIndicator, algo do tipo.

A minha opinião é que o javafx ainda não acompanhou as mudanças ou novidades das apis gráficas de aceleração por hardware com "eficiência"... Pelo menos de S.O com kernel 4.3 ou superior.

Esta usando o OpenJDK ou o Java da Oracle?
--
LinuxCounter: #596371

Java da Oracle.