Compilator translation

[claudiocarcaci]

I have a very simple question.
I am developing a software that give particular focus on performance.
If I have a code like:

do
{
	/* do something */
	sweep++;
}
while (sweep < infos.getTermsList().size() && others conditions)

my question is:
if infos aren't modified during do-while instructions, at compile time the instruction

infos.getTermsList().size()

are converted in to a local variable or it will be called every time?

[Norm]

To see for yourself, add a call to println in getTermsList() that prints a message every time it is called.

[Potato]

It is called every time.

[claudiocarcaci]

You're right, it's a question that I want to solve once forever ;)

[Tolls]

Essentially the compiler has to compile it to call the size() everytime as it has no real way of knowing whether that value (or the termsList one) is changed at all during the execution of the loop. Since it can't make that assumption it creates code that calls it everytime.

[claudiocarcaci]

Essentially the compiler has to compile it to call the size() everytime as it has no real way of knowing whether that value (or the termsList one) is changed at all during the execution of the loop. Since it can't make that assumption it creates code that calls it everytime.

Theoretically with static optimization of code the compiler can know if termsList.
It seems that Java Compiler doesn't make that optimization ;)

[Norm]

What is returned by getTermsList()?
Can its size be changed while the loop is executing?
How can the compiler know that?

[claudiocarcaci]

What is returned by getTermsList()?
Can its size be changed while the loop is executing?
How can the compiler know that?

getTermsList() returns an ArrayList<String>
It's size doesn't change during loop.
With static analysis compiler can know if structures involved in loop changes during execution, but this work if compiler perform this type static analysis during pre-compilation.
The question was: JVM do that?
Unfortunately no :( :(

[Norm]

What about another thread?
Also, I think there can be different versions of the JVM from different sources.

[pbrockway2]

Sorry if I'm missing something, but why not just say

int size = infos.getTermsList().size();

before the loop starts and then use size in the while condition. This also better expresses the assumption that the size will not be changing.

[claudiocarcaci]

What about another thread?
Also, I think there can be different versions of the JVM from different sources.

Static analysis can include milti-thread with shared data ;)

Sorry if I'm missing something, but why not just say

int size = infos.getTermsList().size();

before the loop starts and then use size in the while condition. This also better expresses the assumption that the size will not be changing.

That was done ;)
Thanks :)

[Tolls]

Static analysis can include milti-thread with shared data ;)

No it can't because it can only do that if it knows the class 'infos' is used in a multi-threaded environment or not.
And that is not known at compile time, only at runtime.

Now the JVM itself could do that based on actual execution, but even then it could only do that if it loaded the entire application and analysed it to understand what is going on...at runtime...I know I would not want to take that hit.

[claudiocarcaci]

No it can't because it can only do that if it knows the class 'infos' is used in a multi-threaded environment or not.
And that is not known at compile time, only at runtime.

Now the JVM itself could do that based on actual execution, but even then it could only do that if it loaded the entire application and analysed it to understand what is going on...at runtime...I know I would not want to take that hit.

But multithreaded apps with sharing of infos data are written in static code ;)
http://www.lst.inf.ethz.ch/research/.../PLDI_2003.pdf ;)
It's possible, but JVM doesn't do that :(

[Tolls]

"A compiler for an object-oriented programming language
with multi-threading needs precise information about the
sharing of objects."

Which is exactly what I was saying.
Neither the Java compiler nor the JVM has this information.
To get this information you would have to completely change how Java works, starting with the class loader.

[claudiocarcaci]

"A compiler for an object-oriented programming language
with multi-threading needs precise information about the
sharing of objects."

Which is exactly what I was saying.
Neither the Java compiler nor the JVM has this information.
To get this information you would have to completely change how Java works, starting with the class loader.

Misunderstang, regret :(
:D