Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36545 > unrolled thread

Re: Jigsaw

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Jigsaw j4n bur53 <janburse@fastmail.fm> - 2017-04-28 00:26 +0200
    Re: Jigsaw j4n bur53 <janburse@fastmail.fm> - 2017-04-28 00:43 +0200
      Re: Jigsaw j4n bur53 <janburse@fastmail.fm> - 2017-04-28 00:52 +0200
      Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-27 21:27 -0400
        Re: Jigsaw j4n bur53 <janburse@fastmail.fm> - 2017-04-28 12:30 +0200
          Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-28 08:18 -0400
        Re: Jigsaw v_borchert@despammed.com (Volker Borchert) - 2017-04-28 20:01 +0000
          Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-28 19:20 -0400
    Re: Jigsaw Arne Vajhøj <arne@vajhoej.dk> - 2017-04-27 21:07 -0400

#36545 — Re: Jigsaw

My first experience with JDK 9:

The following code didn't work anymore:

         if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel) {

On a windows machine it barked that I am not allowed
to access the class WindowsLookAndFeel.

I did the following workaround:

         if (LAF_ID.equals(UIManager.getLookAndFeel().getID())) {

I have mixed feelings towards JDK 9. It also
run 50% slower than JDK 8. I was running my usual
benchmark all of them were significantly slower.

I did these tests 2-3 months ago, maybe the
performance problem is now fixed. Dunno.

Stefan Ram schrieb:
>   No, my post is not about Scott Stark's blog entry,
>   but rather about this sentence:
>
>       »The previously monolithic runtime library rt.jar is
>       now split up in Java 9.«
>       ¯¯¯¯¯¯¯¯¯¯¯¯
>   Didn't I hear that some years before? Wait!
>   Yes - here it is:
>
>       »Java SE 6 Update 10 consists of several technologies
>       that improve the user experience related to installing
>       the JRE, and to deploying and running rich-client Java
>       (and JavaFX) programs: · Java Kernel Online Installer
>       - The JRE is now divided into small bundles.«.
>                    ¯¯¯¯¯¯¯¯¯¯¯
>

[toc] | [next] | [standalone]

#36546

Still performance issue:

JDK 8: Total	in 5994	(44 gc) ms
JDK 9: Total	in 9668	(16 gc) ms

Versions used:

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+167)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+167, mixed mode)

j4n bur53 schrieb:
> My first experience with JDK 9:
>
> The following code didn't work anymore:
>
>         if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel) {
>
> On a windows machine it barked that I am not allowed
> to access the class WindowsLookAndFeel.
>
> I did the following workaround:
>
>         if (LAF_ID.equals(UIManager.getLookAndFeel().getID())) {
>
> I have mixed feelings towards JDK 9. It also
> run 50% slower than JDK 8. I was running my usual
> benchmark all of them were significantly slower.
>
> I did these tests 2-3 months ago, maybe the
> performance problem is now fixed. Dunno.
>
> Stefan Ram schrieb:
>>   No, my post is not about Scott Stark's blog entry,
>>   but rather about this sentence:
>>
>>       »The previously monolithic runtime library rt.jar is
>>       now split up in Java 9.«
>>       ¯¯¯¯¯¯¯¯¯¯¯¯
>>   Didn't I hear that some years before? Wait!
>>   Yes - here it is:
>>
>>       »Java SE 6 Update 10 consists of several technologies
>>       that improve the user experience related to installing
>>       the JRE, and to deploying and running rich-client Java
>>       (and JavaFX) programs: · Java Kernel Online Installer
>>       - The JRE is now divided into small bundles.«.
>>                    ¯¯¯¯¯¯¯¯¯¯¯
>>
>

[toc] | [prev] | [next] | [standalone]

#36547

By a quick chekk I dont find any tickets on the internet
discussing slow application performance of JDK 9.

But a couple of discussions about slow compilation
performance. But I guess the two are related,

the compiler is just another application.

j4n bur53 schrieb:
> Still performance issue:
>
> JDK 8: Total    in 5994    (44 gc) ms
> JDK 9: Total    in 9668    (16 gc) ms
>
> Versions used:
>
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+167)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+167, mixed mode)
>
> j4n bur53 schrieb:
>> My first experience with JDK 9:
>>
>> The following code didn't work anymore:
>>
>>         if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel) {
>>
>> On a windows machine it barked that I am not allowed
>> to access the class WindowsLookAndFeel.
>>
>> I did the following workaround:
>>
>>         if (LAF_ID.equals(UIManager.getLookAndFeel().getID())) {
>>
>> I have mixed feelings towards JDK 9. It also
>> run 50% slower than JDK 8. I was running my usual
>> benchmark all of them were significantly slower.
>>
>> I did these tests 2-3 months ago, maybe the
>> performance problem is now fixed. Dunno.
>>
>> Stefan Ram schrieb:
>>>   No, my post is not about Scott Stark's blog entry,
>>>   but rather about this sentence:
>>>
>>>       »The previously monolithic runtime library rt.jar is
>>>       now split up in Java 9.«
>>>       ¯¯¯¯¯¯¯¯¯¯¯¯
>>>   Didn't I hear that some years before? Wait!
>>>   Yes - here it is:
>>>
>>>       »Java SE 6 Update 10 consists of several technologies
>>>       that improve the user experience related to installing
>>>       the JRE, and to deploying and running rich-client Java
>>>       (and JavaFX) programs: · Java Kernel Online Installer
>>>       - The JRE is now divided into small bundles.«.
>>>                    ¯¯¯¯¯¯¯¯¯¯¯
>>>
>>
>

[toc] | [prev] | [next] | [standalone]

#36549

On 4/27/2017 6:43 PM, j4n bur53 wrote:
> Still performance issue:
>
> JDK 8: Total    in 5994    (44 gc) ms
> JDK 9: Total    in 9668    (16 gc) ms
>
> Versions used:
>
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+167)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+167, mixed mode)

That is a huge difference.

I don't see such a big difference when I do my benchmark.

C:\Code\JVMPerf>java JvmTest
Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.121-b13
472.28 million integer operations per second
471.70 million integer operations per second
472.72 million integer operations per second
472.72 million integer operations per second
473.08 million integer operations per second
472.75 million integer operations per second
472.72 million integer operations per second
473.08 million integer operations per second
472.72 million integer operations per second
470.06 million integer operations per second
208.16 million floating point operations per second
208.20 million floating point operations per second
207.68 million floating point operations per second
207.17 million floating point operations per second
207.94 million floating point operations per second
207.81 million floating point operations per second
207.60 million floating point operations per second
208.03 million floating point operations per second
207.21 million floating point operations per second
207.94 million floating point operations per second
7.59 million string operations per second
8.22 million string operations per second
8.98 million string operations per second
9.29 million string operations per second
9.16 million string operations per second
9.29 million string operations per second
9.29 million string operations per second
9.16 million string operations per second
9.29 million string operations per second
9.16 million string operations per second

C:\Code\JVMPerf>\sun\64bit\jdk-9\bin\java JvmTest
Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 9-ea+167
472.39 million integer operations per second
473.08 million integer operations per second
472.72 million integer operations per second
472.72 million integer operations per second
472.37 million integer operations per second
471.32 million integer operations per second
469.42 million integer operations per second
470.28 million integer operations per second
469.81 million integer operations per second
471.39 million integer operations per second
208.03 million floating point operations per second
208.81 million floating point operations per second
208.81 million floating point operations per second
208.12 million floating point operations per second
208.81 million floating point operations per second
208.81 million floating point operations per second
208.77 million floating point operations per second
208.16 million floating point operations per second
203.54 million floating point operations per second
208.77 million floating point operations per second
6.32 million string operations per second
6.77 million string operations per second
7.04 million string operations per second
6.97 million string operations per second
6.89 million string operations per second
6.91 million string operations per second
6.97 million string operations per second
6.76 million string operations per second
6.93 million string operations per second
7.01 million string operations per second

The only difference is that the string operations
seems to be somewhat slower.

But what can we conclude?

That one programs performance characteristics can
not be predicted by another programs performance characteristics?

We already knew that.

That some change 8->9 have a have a huge negative
impact on the performance of your program?

That is obvious.

Will you see the same effect in final 9?

No way to tell. Maybe you will or maybe they will
have fixed something. They may not even need to
change any code - if the performance degradation is due
to the EA version being built for easy debugging and
the final version is being built for performance, then
it may go away by itself. We will first know when
final is out.

Arne

[toc] | [prev] | [next] | [standalone]

#36550

Maybe a problem with GC throughput,

the faster JDK does 4 times more GC.

I am testing on a 8-core machine.

Arne Vajhøj schrieb:
> On 4/27/2017 6:43 PM, j4n bur53 wrote:
>> JDK 8: Total    in 5994    (44 gc) ms
>> JDK 9: Total    in 9668    (16 gc) ms
> That is a huge difference.
>
> I don't see such a big difference when I do my benchmark.

[toc] | [prev] | [next] | [standalone]

#36551

On 4/28/2017 6:30 AM, j4n bur53 wrote:
> Arne Vajhøj schrieb:
>> On 4/27/2017 6:43 PM, j4n bur53 wrote:
>>> JDK 8: Total    in 5994    (44 gc) ms
>>> JDK 9: Total    in 9668    (16 gc) ms
>> That is a huge difference.
>>
>> I don't see such a big difference when I do my benchmark.
 >
> Maybe a problem with GC throughput,
>
> the faster JDK does 4 times more GC.
>
> I am testing on a 8-core machine.

Could be. My benchmark is compute intensive but
not so much GC intensive.

Sorry to ask, but are you tests using the same GC?

(if I remember correct then the default in 8 is
parallel and the default in 9 is G1)

Arne

[toc] | [prev] | [next] | [standalone]

#36552

Arne Vajh??j wrote:

> The only difference is that the string operations
> seems to be somewhat slower.

Maybe CompactString related?

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#36553

On 4/28/2017 4:01 PM, Volker Borchert wrote:
> Arne Vajh??j wrote:
>> The only difference is that the string operations
>> seems to be somewhat slower.
>
> Maybe CompactString related?

-XX:-CompactStrings

does not seem to make a difference.

But let us see how final version behaves.

Arne

[toc] | [prev] | [next] | [standalone]

#36548

On 4/27/2017 6:26 PM, j4n bur53 wrote:
> My first experience with JDK 9:
>
> The following code didn't work anymore:
>
>         if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel) {
>
> On a windows machine it barked that I am not allowed
> to access the class WindowsLookAndFeel.

Those that have been using SUN internal classes will get a very
bad experience when going Java 9.

The module system in practice.

com.sun.java.swing.plaf.windows.WindowsLookAndFeel is not exported
to the world, so no access.

It is not the only one.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web