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

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

Java 7 vs 8 speed issues on Win7?

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

Contents

  Java 7 vs 8 speed issues on Win7? Knute Johnson <eternal@knutejohnson.com> - 2014-10-22 10:18 -0700
    Re: Java 7 vs 8 speed issues on Win7? Silvio <silvio@internet.com> - 2014-10-24 11:10 +0200
    Re: Java 7 vs 8 speed issues on Win7? Roedy Green <see_website@mindprod.com.invalid> - 2014-11-05 04:36 -0800
      Re: Java 7 vs 8 speed issues on Win7? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2014-11-05 08:23 -0800
        Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-05 20:47 +0100
          Re: Java 7 vs 8 speed issues on Win7? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2014-11-05 17:32 -0800
            Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-05 21:37 -0500
              Re: Java 7 vs 8 speed issues on Win7? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2014-11-05 20:00 -0800
                Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-05 23:32 -0500
                  Re: Java 7 vs 8 speed issues on Win7? Robert Klemme <shortcutter@googlemail.com> - 2014-11-06 08:48 +0100
                  Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 15:09 +0100
                    Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-06 09:50 -0500
                      Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 18:21 +0100
                        Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 18:34 +0100
                        Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-06 23:03 +0100
                          Re: Java 7 vs 8 speed issues on Win7? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-11-06 17:21 -0500
                            Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-07 00:07 +0100
                              Re: Java 7 vs 8 speed issues on Win7? "Bob(but not" THAŢ "Bob)" <nobody@nowhere.net> - 2014-11-07 08:48 +0000
                                Re: Java 7 vs 8 speed issues on Win7? Jan Burse <janburse@fastmail.fm> - 2014-11-08 11:28 +0100
          Re: Java 7 vs 8 speed issues on Win7? Roedy Green <see_website@mindprod.com.invalid> - 2014-11-20 03:12 -0800
            Re: Java 7 vs 8 speed issues on Win7? Silvio <silvio@internet.com> - 2014-11-20 13:24 +0100
              Re: Java 7 vs 8 speed issues on Win7? Robert Klemme <shortcutter@googlemail.com> - 2014-11-20 19:06 +0100
                Re: Java 7 vs 8 speed issues on Win7? Silvio <silvio@internet.com> - 2014-11-20 22:54 +0100
                  Re: Java 7 vs 8 speed issues on Win7? Brixomatic <brixomatic@yahoo.com> - 2014-11-22 08:54 +0100
                    Re: Java 7 vs 8 speed issues on Win7? Brixomatic <brixomatic@yahoo.com> - 2014-11-22 09:19 +0100
      Re: Java 7 vs 8 speed issues on Win7? Fredrik Jonson <fredrik@jonson.org> - 2014-11-29 07:44 +0000

Page 1 of 2  [1] 2  Next page →

#30161 — Java 7 vs 8 speed issues on Win7?

We had a failure of a computer and the replacement has Win7 on it.  The 
old computer had XP.  I installed Java 7u71 on the new computer and it 
performed very poorly.  I replaced the Java 7 with 8u25 and the 
performance improved considerably.  Anybody have an idea what's up with 
that?  The original computer had Java 6 but we've made some updates to 
the program and to use the latest we need 7+.

Thanks,

-- 

Knute Johnson

[toc] | [next] | [standalone]

#30169

On 10/22/2014 07:18 PM, Knute Johnson wrote:
> We had a failure of a computer and the replacement has Win7 on it.  The
> old computer had XP.  I installed Java 7u71 on the new computer and it
> performed very poorly.  I replaced the Java 7 with 8u25 and the
> performance improved considerably.  Anybody have an idea what's up with
> that?  The original computer had Java 6 but we've made some updates to
> the program and to use the latest we need 7+.
>
> Thanks,
>

Rings no particular bells for me. Lots of stuff has changed though. 
PermGen has disappeared. HashMap changed quite drastically and is 
significantly faster for most use cases. G1 can do string deduplication. 
Etc. etc. All of these can account for (part of) performance 
improvements of 8 over 7.

But since you say that 7 performed poorly in comparison to 6 I would 
suspect something else must have caused that.

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

#30283

On Wed, 22 Oct 2014 10:18:19 -0700, Knute Johnson
<eternal@knutejohnson.com> wrote, quoted or indirectly quoted someone
who said :

>We had a failure of a computer and the replacement has Win7 on it.  The 
>old computer had XP.  I installed Java 7u71 on the new computer and it 
>performed very poorly.  I replaced the Java 7 with 8u25 and the 
>performance improved considerably.  Anybody have an idea what's up with 
>that?  The original computer had Java 6 but we've made some updates to 
>the program and to use the latest we need 7+.

did any java.exe command line switch defaults change?

I wish there were a switch to get them all dumped for java.exe and
javac.exe
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Software gets slower faster than hardware gets faster.
~ Niklaus Wirth (born: 1934-02-15 age: 80) Wirth’s Law

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

#30285

On 11/5/2014 04:36, Roedy Green wrote:
> On Wed, 22 Oct 2014 10:18:19 -0700, Knute Johnson
> <eternal@knutejohnson.com> wrote, quoted or indirectly quoted someone
> who said :
>
>> We had a failure of a computer and the replacement has Win7 on it.  The
>> old computer had XP.  I installed Java 7u71 on the new computer and it
>> performed very poorly.  I replaced the Java 7 with 8u25 and the
>> performance improved considerably.  Anybody have an idea what's up with
>> that?  The original computer had Java 6 but we've made some updates to
>> the program and to use the latest we need 7+.
>
> did any java.exe command line switch defaults change?
>
> I wish there were a switch to get them all dumped for java.exe and
> javac.exe
>

No.  We loaded up a new computer with Win7 and Java 7 and the software 
that had been running under Java 6 ran so slow that we couldn't use it. 
  The new computer was multi-core, more memory and faster but the Java 
code ran so slow we couldn't use it.  Then we install Java 8 and it is 
back to its old self.

Really strange.

knute...

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

#30286

A fundamental change in one of the newer JDKs
is a changed semantics for substring(int, int).

Knute Johnson schrieb:
> On 11/5/2014 04:36, Roedy Green wrote:
>> On Wed, 22 Oct 2014 10:18:19 -0700, Knute Johnson
>> <eternal@knutejohnson.com> wrote, quoted or indirectly quoted someone
>> who said :
>>
>>> We had a failure of a computer and the replacement has Win7 on it.  The
>>> old computer had XP.  I installed Java 7u71 on the new computer and it
>>> performed very poorly.  I replaced the Java 7 with 8u25 and the
>>> performance improved considerably.  Anybody have an idea what's up with
>>> that?  The original computer had Java 6 but we've made some updates to
>>> the program and to use the latest we need 7+.
>>
>> did any java.exe command line switch defaults change?
>>
>> I wish there were a switch to get them all dumped for java.exe and
>> javac.exe
>>
>
> No.  We loaded up a new computer with Win7 and Java 7 and the software
> that had been running under Java 6 ran so slow that we couldn't use it.
>   The new computer was multi-core, more memory and faster but the Java
> code ran so slow we couldn't use it.  Then we install Java 8 and it is
> back to its old self.
>
> Really strange.
>
> knute...
>

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

#30287

On 11/5/2014 11:47, Jan Burse wrote:
> A fundamental change in one of the newer JDKs
> is a changed semantics for substring(int, int).

For better or worse?

knute...

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

#30288

On 11/5/2014 8:32 PM, Knute Johnson wrote:
> On 11/5/2014 11:47, Jan Burse wrote:
>> A fundamental change in one of the newer JDKs
>> is a changed semantics for substring(int, int).
>
> For better or worse?

     "Yes, probably."

     (Given the amount of data provided, that's really all the
answer one can offer -- and all that's deserved.  C'mon, Knute:
No description of the application, no hint about its hot spots,
no profiling data, not even *one* measurement of any kind at
all ... How in the world can you expect useful feedback when
you've not fed forward?)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#30289

On 11/5/2014 18:37, Eric Sosman wrote:
> On 11/5/2014 8:32 PM, Knute Johnson wrote:
>> On 11/5/2014 11:47, Jan Burse wrote:
>>> A fundamental change in one of the newer JDKs
>>> is a changed semantics for substring(int, int).
>>
>> For better or worse?
>
>      "Yes, probably."
>
>      (Given the amount of data provided, that's really all the
> answer one can offer -- and all that's deserved.  C'mon, Knute:
> No description of the application, no hint about its hot spots,
> no profiling data, not even *one* measurement of any kind at
> all ... How in the world can you expect useful feedback when
> you've not fed forward?)
>

I think we are talking about two different things here.

Unfortunately I can't give any good details because I was working on 
this 250 miles away with VNC.  The customer had a failed computer and we 
had to get it running without any delays.

It is not code that was stretching the previous machine with a single 
processor running XP and Java 6 but when we configured a new computer 
with a multi-core processor, Win7 and Java 7 the code barely ran.  It 
was so slow that it was no longer usable.  Put in Java 8 and it is back 
to its old self, tuning along just fine.  I haven't been able to 
duplicate it in my shop and we can't stop the customer's computers to 
play with them.

As to Jan's comments, there isn't a single call to String.substring() in 
the code anywhere and it runs fine with Java 8, so I don't think that is 
the cause.  But I am still curious about what the "changed semantics" 
are and how they might impact performance.

Thanks,

knute...

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

#30290

On 11/5/2014 11:00 PM, Knute Johnson wrote:
> On 11/5/2014 18:37, Eric Sosman wrote:
>> On 11/5/2014 8:32 PM, Knute Johnson wrote:
>>> On 11/5/2014 11:47, Jan Burse wrote:
>>>> A fundamental change in one of the newer JDKs
>>>> is a changed semantics for substring(int, int).
>>>
>>> For better or worse?
>>
>>      "Yes, probably."
>>
>>      (Given the amount of data provided, that's really all the
>> answer one can offer -- and all that's deserved.  C'mon, Knute:
>> No description of the application, no hint about its hot spots,
>> no profiling data, not even *one* measurement of any kind at
>> all ... How in the world can you expect useful feedback when
>> you've not fed forward?)
>>
>
> I think we are talking about two different things here.
>
> Unfortunately I can't give any good details because I was working on
> this 250 miles away with VNC.  The customer had a failed computer and we
> had to get it running without any delays.

     Yes, sometimes in a crisis there's no opportunity for calm
investigation.  I can quite understand that; I've been in those
situations myself.  Nonetheless, the complete lack of measurement
means you can't expect a diagnosis that's any better than pure
speculation.  It's a casualty of the crisis.

> It is not code that was stretching the previous machine with a single
> processor running XP and Java 6 but when we configured a new computer
> with a multi-core processor, Win7 and Java 7 the code barely ran.  It
> was so slow that it was no longer usable.  Put in Java 8 and it is back
> to its old self, tuning along just fine.  I haven't been able to
> duplicate it in my shop and we can't stop the customer's computers to
> play with them.

     So, all we have is:

     - An application (whose nature, function, size, and performance
       characteristics aren't divulged) performed acceptably on one
       machine with one O/S and one Java version,

     - When the Java version, O/S, and machine were all changed, the
       application performed poorly,

     - When the Java version was changed yet again, things improved.

Three variables, two times two times three equals twelve configurations
of which three were observed, and the only data we have from the
observations are "it performed very poorly" and "the performance
improved considerably."

     Anybody who can draw a diagnosis from so little data has psychic
powers.

> As to Jan's comments, there isn't a single call to String.substring() in
> the code anywhere and it runs fine with Java 8, so I don't think that is
> the cause.  But I am still curious about what the "changed semantics"
> are and how they might impact performance.

     I, too, wonder what he meant by "changed semantics," since as far
as I know the contract of String#substring(int,int) has not changed
since Java 1.0, and perhaps earlier.  The underlying implementations
have changed, I believe, but that's not what I'd call a "semantic"
difference.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#30291

On 06.11.2014 05:32, Eric Sosman wrote:

>      So, all we have is:
>
>      - An application (whose nature, function, size, and performance
>        characteristics aren't divulged) performed acceptably on one
>        machine with one O/S and one Java version,
>
>      - When the Java version, O/S, and machine were all changed, the
>        application performed poorly,
>
>      - When the Java version was changed yet again, things improved.
>
> Three variables, two times two times three equals twelve configurations
> of which three were observed, and the only data we have from the
> observations are "it performed very poorly" and "the performance
> improved considerably."
>
>      Anybody who can draw a diagnosis from so little data has psychic
> powers.

Amen to that.

Even without measurement data there is a lot more information that Knute 
could provide:

- Type of application (UI, server...)
- Type of processing typically done
- Use of threads
- Use of particular libraries or frameworks
etc.

Cheers

	robert

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

#30292

Hi,

Eric Sosman schrieb:
>      I, too, wonder what he meant by "changed semantics," since as far
> as I know the contract of String#substring(int,int) has not changed
> since Java 1.0, and perhaps earlier.  The underlying implementations
> have changed, I believe, but that's not what I'd call a "semantic"
> difference.

I don't think a method signature (=contract) alone
defines any semantics. BTW: There was a thread here on 
comp.lang.java.programmer about the changed semantics
of substring(int,int). One can lookup the results there.

HashMap was mentioned already in this thread, but I think
it was also discussed here before. String deduplication is
also already mentioned, but this has to be activated by 
-XX:+UseStringDeduplication I guess. Maybe there is
somewhere a list of all the differences.

I know about some existing applications that had problem
cz of the substring(int,int) change, in particular a
parser that relied on the semantics that substring(int,int)
does share the original char[] array. But this semantics
has been replaced by another semantics now, where a range
of the char[] array is copied.

Bye

That the semantic has changed can also be seen by the
fields that the String class now features (JDK 8):

     private final char value[];
     private int hash;

(See for example:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/lang/String.java 
)

The field offset and count is now gone. The old
String class featured the following fields (for example
JDK 6):

     private final char value[];
     private int hash;
     private final int offset;
     private final int count;

(See for example:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/String.java 
)

So the internal contract has massively changed.

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

#30293

On 11/6/2014 9:09 AM, Jan Burse wrote:
> Hi,
>
> Eric Sosman schrieb:
>>      I, too, wonder what he meant by "changed semantics," since as far
>> as I know the contract of String#substring(int,int) has not changed
>> since Java 1.0, and perhaps earlier.  The underlying implementations
>> have changed, I believe, but that's not what I'd call a "semantic"
>> difference.
>
> I don't think a method signature (=contract) alone
> defines any semantics.[...]

     I guess we'll just have to accept that "semantics" means something
different to you than it does to me.  It seems you consider the quirks
of a particular implementation are part of the "semantics," while I do
not.  Merriam-Webster offers two capsule definitions:

	the study of the meanings of words and phrases in language

	the meanings of words and phrases in a particular context

... plus more detailed definitions using words like "semiotics"
and "signification."  The use of "semantics" in re programming is
clearly something of an abuse or at least a twist of the actual
meaning, so I doubt there's a usable authority to whom we can
appeal to resolve our different understandings of the word.  We'll
just have to accept that we differ -- and that You're Wrong!!!  :)

> That the semantic has changed can also be seen by the
> fields that the String class now features (JDK 8):
>
>      private final char value[];
>      private int hash;

     Note the keyword `private'.  Thought experiment: If `hash'
were declared before `value' instead of after, would that be a
"semantic" change?  What if the fields were renamed to `data'
and `code'; would that be a "semantic" change?

> So the internal contract has massively changed.

     If there's any such thing as an "internal contract," this is
the first I've heard of it.  The entire premise of "write to the
interface, not the implementation" is that such contracts do *not*
exist!  As a practical matter they sometimes sort of do: We expect
an Iterator's implementation of next() to take approximately constant
time, or maybe logarithmic at the worst, although there's nothing
in any contract anywhere that actually makes such a promise.  I'm
not denying that the supposedly-invisible internals sometimes make
themselves apparent and present problems or opportunities; I'm just
resisting the attempt to refer to such things as part of a "contract"
or to call them "semantics."

     Thought experiment: If the next JVM patch improves the JIT so
sparse `switch' blocks on `char' values are compiled more efficiently,
is that a change in the "semantics" of `switch'?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#30295

Eric Sosman schrieb:
>
>      If there's any such thing as an "internal contract," this is
> the first I've heard of it.

You're welcome.

I give you an example of internal contracts from
real world. Assume you are employed by an employer
and sign a job contract. This is actually an internal
contract, it might contain matters that are not supposed
to be seen outside of the company, or it might contain
matters that you personally wouldn't like to be seen
everywhere, for example the salary figure.

It similar with a class. The modifiers private,
package local /* omission of a modifier */, public,
protected are just contract modifiers, defining how
internal and how external the interface is.

> I'm
> not denying that the supposedly-invisible internals sometimes make
> themselves apparent and present problems or opportunities; I'm just
> resisting the attempt to refer to such things as part of a "contract"
> or to call them "semantics."

Call it potato. I don't care how you call it.
Some other software has a tool called nitpick.
Maybe they add a tool called sosman in the future.

>  Thought experiment: If the next JVM patch improves the JIT so
> sparse `switch' blocks on `char' values are compiled more efficiently,
> is that a change in the "semantics" of `switch'?

Yes its a bigger potato than before. The potato
has changed. For example the compiler will accept
certain programs which he didn't accept before.

And this acceptance is not on grounds of syntax,
but on grounds of allowed types in the switch
argument. So if you accept that types are closer
to semantics, sorry potatos, than well you might
also accepts that this switch change concerns
potatos.

But to be frankly, I don't care a bit whether
you accept this view. Since as long as there is
no tool named after your name, you are anyway
not authorative. But there are chances that a
tool is named after you. Since you are asking the
right questions about semantics, oh sorry potatos.

Bye

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

#30296

Jan Burse schrieb:
> It similar with a class. The modifiers private,
> package local /* omission of a modifier */, public,
> protected are just contract modifiers, defining how
> internal and how external the interface is.

Some more nitpicking. One might say a class is not
an interface. Well this is the case in Java, classes
and interfaces are distinct entities.

But a class can be viewed as entity where interface
and implementation coincide. Where the interface
is defined parallel to an implementation.(*)

So a class is basically also a contract entity. This
is seen in many places, for example in inheritance,
and of course in normal use of classes.

Bye

(*)
Actually practically a class can also have multiple
implementations, not in a parallel existing in the
same application.

But if you add to the class path just an other realization
of the same class, your application will use this
other implementation.

All the other classes will not know, they just see
the same interface. But there is a couple of programming
techniques that would make such variation points
more explicit or plugable.

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

#30297

Jan Burse schrieb:
>>  Thought experiment: If the next JVM patch improves the JIT so
>> sparse `switch' blocks on `char' values are compiled more efficiently,
>> is that a change in the "semantics" of `switch'?
>
> Yes its a bigger potato than before. The potato
> has changed. For example the compiler will accept
> certain programs which he didn't accept before.
>
> And this acceptance is not on grounds of syntax,
> but on grounds of allowed types in the switch
> argument. So if you accept that types are closer
> to semantics, sorry potatos, than well you might
> also accepts that this switch change concerns
> potatos.

Oops, correction. I was reading "char" as string.
No compiler optimizations are usually semantics
preserving. Are not really considered as semantic
changes of a language construct.

Bye

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

#30298

On 11/6/2014 5:03 PM, Jan Burse wrote:
> Jan Burse schrieb:
>>>  Thought experiment: If the next JVM patch improves the JIT so
>>> sparse `switch' blocks on `char' values are compiled more efficiently,
>>> is that a change in the "semantics" of `switch'?
>>
>> Yes its a bigger potato than before. The potato
>> has changed. For example the compiler will accept
>> certain programs which he didn't accept before.
>> [...]
> Oops, correction. I was reading "char" as string.
> No compiler optimizations are usually semantics
> preserving. Are not really considered as semantic
> changes of a language construct.

     Thanks for the correction; you had me even more confused
than is my default state.

     However, the correction leaves me wondering just what *does*
constitute a "semantic" change, in your estimation.  On the one
hand you maintain that a change in the `private' behavior of
String is a "semantic" change, although its only externally-
visible effect is on performance, not on function.  On the other,
you hold that a hypothetical change to `switch' would *not* be a
"semantic" change, since it only affects performance but does not
change the outcome.  I cannot see what distinguishes the two cases,
why one function-preserving-but-performance-altering change is
"semantic" and the other is not.

     Perhaps, as you suggest, it's just "potato" versus "spud."

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#30299

Eric Sosman schrieb:
>
>      However, the correction leaves me wondering just what *does*
> constitute a "semantic" change, in your estimation.  On the one
> hand you maintain that a change in the `private' behavior of
> String is a "semantic" change, although its only externally-
> visible effect is on performance, not on function.  On the other,
> you hold that a hypothetical change to `switch' would *not* be a
> "semantic" change, since it only affects performance but does not
> change the outcome.  I cannot see what distinguishes the two cases,
> why one function-preserving-but-performance-altering change is
> "semantic" and the other is not.

Typically a compiler optimization leads to a better
non-functional result, which is not considered a semantic
change, although it is. On the other hand what happend
with String.substring did degenerate the performance
in many cases. So it gets a different attention.

That there is probably problem a in being precise in
non-functional requirements has already been recognized.
Here is a particular example, in a 10 years framework.
You see the initial conception of this here:

Research Abstract: Semantic Concepts for the Specification of 
Non-functional Properties of Component-Based Software
by Steffen Zschaler

I guess it is from 2002. And it begins with:

	"The area of semantics for functional specifications has been well 
understood for quite a long time already. In contrast, for 
non-functional specifications there exists—to the best of my 
knowledge—no commonly accepted understanding of what constitutes a 
definition of semantics. Various specialized approaches can be found in 
the literature (e.g., [10, 7, 8]), but they are either incomplete or 
very domain specific. Secondly, component-based software development 
[11] is an important trend in software engineering. Its main promises 
are reusability and exchangeability of components in a system. Both are 
achieved through a principle of locality: Every component needs to 
explicitly specify what services it provides and what it needs in order 
to provide."

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.148.6537

Then later, actually more then 10 years later one finds:

On the Reusable Specification of Non-functional
Properties in DSLs

	"In this paper, we discuss how such building blocks can
be constructed for the specification and analysis
of a range of non-functional properties, such as,
for example, throughput, response time, or reliability
properties. We assume DSL semantics to be provided
through a set of transformation rules, which enables a
range of analyses based on model checking."

http://www.steffen-zschaler.de/publications/sle2012.pdf

Looks like things have gotten even more complex. To
formally make accessible non functional requirements
in Java, I would probably use the Java annontation
mechanism. And what we would see for substring(int,int)
would be that the corresponding annotation would
change, and warn us about that now char[] is copied,

but for a better switch statement, a better
compilation I wouldn't know where to lookup
this annotation. And even if the Hotspot JVM can
do it, probably my Dalvik JVM will not do it, to
conserve battery life, it will do no JITing
at all.

Bye

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

#30302

On Fri, 07 Nov 2014 00:07:26 +0100, Jan Burse wrote:

> but for a better switch statement, a better compilation I wouldn't know
> where to lookup this annotation. And even if the Hotspot JVM can do it,
> probably my Dalvik JVM will not do it, to conserve battery life, it will
> do no JITing at all.

That's a false economy: whatever CPU cycle associated battery consumption 
is saved up front by not JITting, more is lost running interpreted 
instead of JITted code down the line in many instances.

Anyway I heard that Dalvik is obsolete and being replaced by something 
called ART, which the source I read implied will be JITting.

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

#30312

Bob(but not THAŢ Bob) schrieb:
> On Fri, 07 Nov 2014 00:07:26 +0100, Jan Burse wrote:
>
>> but for a better switch statement, a better compilation I wouldn't know
>> where to lookup this annotation. And even if the Hotspot JVM can do it,
>> probably my Dalvik JVM will not do it, to conserve battery life, it will
>> do no JITing at all.
>
> That's a false economy: whatever CPU cycle associated battery consumption
> is saved up front by not JITting, more is lost running interpreted
> instead of JITted code down the line in many instances.
>
> Anyway I heard that Dalvik is obsolete and being replaced by something
> called ART, which the source I read implied will be JITting.
>

According to this post Dalvik has JIT since 2.2, but
one has to explicitly enable it. Something along(*):

	dalvik.vm.heapsize=256M
	dalvik.vm.execution-mode=init:jit

I never tried it. But I guess one cannot do it on an
unrooted device, since it resides in build.prop(**).

On the other hand ART seems to have AOT and not JIT(***).
And the source says:

	"A technology preview of ART debuted as an
	alternative runtime environment in Android
	4.4 "KitKat". In the next major Android
	release, Android 5.0 "Lollipop", Dalvik was
	entirely replaced by ART.

But my point was an entirely different one. I only
wanted to give proof that nowadays there is not
"that particular" compiler optimization.

Even in the old days C compilers offered different
options -O<level>. Nowadays an application is typically
compiled to byte code and then further optimized on
the runtime platform (i.e. Java example).

So thats why its hard to talk for byte code based
languages about "that particular" semantic compiler
optimization change, since such changes typically can
depend on the runtime platform whether they are
available or not.

Unfortunately its also difficult to talk about
"that particular" substring(int,int) change in
general. Since the class String is part of the
Java runtime, and this runtime although it is
to a large part byte code, might also change from
platform to platform.

For example even if I compile my Android application
with JDK 8, this doesn't mean that the APK later
runs with the new semantic of substring(int,int).
Since the APK might run in an environment where
another String class implementation is used.

So I guess current developers, when they develop
for multiple platforms, face a new challenge.
They have to think in multiple semantics, and
choose designs that fit all, or give the best
compromise.

Bye

(*)
http://www.mobileread.com/forums/showthread.php?t=234339

(**)
http://www.droidwiki.de/Build.prop

(***)
http://en.wikipedia.org/wiki/Android_Runtime

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

#30368

On Wed, 05 Nov 2014 20:47:18 +0100, Jan Burse <janburse@fastmail.fm>
wrote, quoted or indirectly quoted someone who said :

>A fundamental change in one of the newer JDKs
>is a changed semantics for substring(int, int).

see http://mindprod.com/jgloss/substring.html

For a discussion on how the change affects performance.
For me it is usually negative.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Software gets slower faster than hardware gets faster.
~ Niklaus Wirth (born: 1934-02-15 age: 80) Wirth’s Law

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web