I was asking about the VM not the O/S.
32 bit or 64 bit in this case.
Notably the 32 bit client VM is gone so you get the 32 bit server VM.
That could make a difference, although in theory the server VM performs
better - so
long as it does not run out of memory.
-phil.
On 1/26/17, 6:44 PM, Scott Palmer wrote:
I’ve only tested with Java 9 on Windows 10 64-bit so far.
I have not yet done any profiling to try to isolate where the difference might
be. The application generates data in native code, wrapped in a native
ByteBuffer and passes an object around holding the buffer and map of properties
to go with it. I’m doing virtually no processing on the data and just
measuring the rate that packets are going through the workflow so far. The GUI
is mostly static during the test except for a table and some labels showing
stats that are updated with bitrates, packet rates, timestamps etc.
I’ll continue to try to isolate a test case that I can share as time allows. I
should be able to get some testing done on Mac and Linux as well and will send
a followup email with any new information.
Regards,
Scott
On Jan 26, 2017, at 9:37 PM, Philip Race<philip.r...@oracle.com> wrote:
Scott,
What VM/bitness/platforms show this ? All or just a specific one ?
-phil.
On 1/26/17, 6:08 PM, Kevin Rushforth wrote:
Hi Scott,
Thanks for the report. The only JDK 9 specific performance problems I have seen
is with startup, which would be a good thing to discuss on jigsaw-dev. If you
are seeing actual application slowdown, that might be something else, depending
on where the problem is. Have you profiled your application?
-- Kevin
Scott Palmer wrote:
I finally managed to get my app running on JDK 9. It is based on a plugin
architecture and the plugins are made accessible by modifying the system class
loader at runtime (because that seemed to be the only way to make things like
JAXB able to reach the classes in the plugins). That “hack” broke with the
module system so I had to find an alternative. (Now I’m using a java agent to
get an Instrumentation interface so I can do it in a somewhat supported way via
the appendToSystemClassLoaderSearch method.)
Anyway, I’ve noticed that the application runs slower on Java 9. For a simple
test I see almost a 10% performance drop. However, I’m not sure that it is
Java FX related. I see the same throughput with the default renderer or the
recently added Marlin renderer, always a bit slower than Java 8u121. I use the
same JVM options, including forcing the garbage collector to use the same
algorithm.
Is there any expectation of a performance drop with JDK 9 at this stage? For
example should I expect some unoptimized stuff in the EA builds?
I guess the jigsaw-dev alias the right place to bring this up?
I have a feeling it is going to be difficult to track down. :-(
I have noticed a couple layout issues fixed with JavaFX 9. Stuff that used to
“snap into place” only when I resized a dialog now seems to be correct when the
dialog first appears. Thanks for that!
Regards,
Scott
On Jan 11, 2017, at 2:14 PM, Kevin Rushforth<kevin.rushfo...@oracle.com> wrote:
As you may know JDK 9 has hit the feature extension complete milestone [1]. We
still have a small number of weeks to fix P1-P3 bugs, but we need to know about
them in order to fix them. Our focus will be on bugs that are new in JDK 9
(regressions).
I ask all JavaFX developers to please download JDK 9 early access [2] and test
your application. You can report any bugs via bugs.java.com [3]. If you have
any questions about whether a behavior is a bug or is expected, please ask on
this alias or on the jigsaw-dev alias [4].
Thank you.
-- Kevin
[1] http://openjdk.java.net/projects/jdk9/
[2] https://jdk9.java.net/download/
[3] http://bugreport.java.com/
[4] jigsaw-...@openjdk.java.net
