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

Root_
(usa Ubuntu)

Enviado em 04/03/2016 - 14:28h

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.

removido
(usa Nenhuma)

Enviado em 04/03/2016 - 15:28h

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

Root_
(usa Ubuntu)

Enviado em 04/03/2016 - 17:27h

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]

Root_
(usa Ubuntu)

Enviado em 08/03/2016 - 01:15h

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.

removido
(usa Nenhuma)

Enviado em 08/03/2016 - 01:34h

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

Root_
(usa Ubuntu)

Enviado em 08/03/2016 - 08:24h

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.

removido
(usa Nenhuma)

Enviado em 08/03/2016 - 08:28h

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

Root_
(usa Ubuntu)

Enviado em 08/03/2016 - 09:39h

Java da Oracle.