• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Method inlining and field accesibility.

 
Ranch Hand
Posts: 157
Netbeans IDE Postgres Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello:

I'd like to know how method inlining deals with the accessibility of object's fields or members. For example, let's suppose a class with one private field and a simple setter:



Could the line this.myField = myField be inlined into the caller method, even although the caller hasn't got access to the field myField. Or is the accessibility constraint applicable at compiling time only but no at runtime?

Thank you.
 
Ranch Hand
Posts: 375
1
Python Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Avor Nadal wrote:Could the line this.myField = myField be inlined into the caller method


What do you mean by inlined here? Are you talking about some automatic inlining done by the compiler as in C++? If yes, then that feature is not available in Java.

Avor Nadal wrote:Or is the accessibility constraint applicable at compiling time only but no at runtime?


Compiler only shows error for the things, that would never work at runtime. A private field is not visible outside a class.
 
Avor Nadal
Ranch Hand
Posts: 157
Netbeans IDE Postgres Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

R. Jain wrote:Are you talking about some automatic inlining done by the compiler as in C++? If yes, then that feature is not available in Java.



I'm sorry. I should have clarified it. I meant the JIT compiler of the JVM. I've read that it's able to inline methods under certain conditions. Many getters and setters are simple and short methods used everywhere, so I was wondering if they also may be electable for inlining or the private accessibility of the field/member prevent that from happening.
 
R. Jain
Ranch Hand
Posts: 375
1
Python Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Although it's no where written which methods the JIT will inline, and which it won't. It is completely based on some heuristics that JIT compiler applies to decide whether to inline a method call or not. For example, JIT might try to identify small methods (With small I mean, 2 or 3, but I'm not sure about the limit), which are called many times. That threshold I guess you can set using some VM arguments. But the point is, it will identify the hot methods, and will inline them if only it is not going to break the code. More often, it will try to inline first the final methods, because those cannot be overridden. Yes, only those methods that has not been overridden will be inlined, which is obvious.

Now, as for the getters and setters accessing private fields, I don't think JIT will inline such methods, as that will break the code. However, it might inline the call that are made in the same class.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Avor Nadal wrote:I'd like to know how method inlining deals with the accessibility of object's fields or members.


These two things do not have anything to do with each other.

The check whether a field is accessible or not is done by the compiler, at compile time. Inlining is done later, at runtime, by the JIT, long after the compiler has translated the source code to byte code.

There's no way that inlining could break accessibility rules.

Avor Nadal wrote:Could the line this.myField = myField be inlined into the caller method, even although the caller hasn't got access to the field myField. Or is the accessibility constraint applicable at compiling time only but no at runtime?


Yes and yes, and it doesn't violate any accessibility rules. The inlining that the JIT does is a low-level optimization.

R. Jain wrote:Now, as for the getters and setters accessing private fields, I don't think JIT will inline such methods, as that will break the code.


How will that break the code? From the point of view of the source code, the accessibility rules are still followed. What the JIT does at runtime to optimize things, doesn't affect the rules of the language.
 
R. Jain
Ranch Hand
Posts: 375
1
Python Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesper de Jong wrote:

R. Jain wrote:Now, as for the getters and setters accessing private fields, I don't think JIT will inline such methods, as that will break the code.


How will that break the code? From the point of view of the source code, the accessibility rules are still followed. What the JIT does at runtime to optimize things, doesn't affect the rules of the language.


But even at byte code level, the private field shouldn't be accessible outside the class right? Accessibility rule should still comply by, or am I missing something? I thought, if the JIT inlines the getters invoked outside the class, that would mean that it is making that code to directly access the private field. May be you can give some more insight into the JIT inlining.
 
Avor Nadal
Ranch Hand
Posts: 157
Netbeans IDE Postgres Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesper de Jong wrote:These two things do not have anything to do with each other.

The check whether a field is accessible or not is done by the compiler, at compile time. Inlining is done later, at runtime, by the JIT, long after the compiler has translated the source code to byte code.


Yes, I do know that the accessibility check and the inlining process happens at different levels. Indeed, that's why I also asked if the accessibility notion exists only at compiling time, not at runtime.


Jesper de Jong wrote:Yes and yes, and it doesn't violate any accessibility rules. The inlining that the JIT does is a low-level optimization.


That's exactly what I wanted to know! If the JVM could do things that from the point of view of the Java language would be "illegal".


R. Jain wrote:...


Really what made me ask this question was the fact that the JVM is used to run "other languages" too. Some of them haven't got the same notion about field accessibility that Java has. So I wondered if the JVM had to deal with accessibility or was just a concept from "higher" levels. I hope that Jesper comments more about this.
 
Master Rancher
Posts: 4806
72
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Avor Nadal wrote:Really what made me ask this question was the fact that the JVM is used to run "other languages" too. Some of them haven't got the same notion about field accessibility that Java has. So I wondered if the JVM had to deal with accessibility or was just a concept from "higher" levels.


The JVM Specification does require the JVM to check accessibility too - see here. Other languages that don't use accessibility the same way can just compile their code to not include private, protected, etc. If those tags do occur on a field or method as defined in the class file, the JVM is required to respect them.

That said, I would think JIT optimizations are still possible here, as long as the JIT can prove to itself that the results are no different than if the optimization had not been performed. If class A uses an instance of class B and calls a method in B which accesses a private variable of B, and this method call takes up enough time to draw the JIT's attention, it might be inlined to class A, why not? The JIT would have to be sure that the method in B is not overridable, or it would have to be sure that in the place where A uses B, the instance is always a true B, not a subclass of B. But in either of these cases, the JIT could be sure that the method call would not be replaced by some other method call. As long as that's the case, inlining the method call should have no functional difference, just performance.

I don't know offhand whether this particular optimization really occurs, or how often. But I see no reason why it shouldn't be possible.
 
Avor Nadal
Ranch Hand
Posts: 157
Netbeans IDE Postgres Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mike Simmons: Thank you. That's a very interesting information. It clarifies my doubt about field accessibility at the bytecode level.

What you commented about the JVM making its own assumptions (if they're safe) makes sense to me too. I didn't know whether the JVM considered the bytecode generated by javac already safe in this sense or needed to do its own analysis before. But reading the specifications that you've linked, it's more clear. After having checked the bytecode, I guess that a JVM considers the new code derived (optimised) from it also safe, Right?. After all, it's generated by itself and would be a no-sense.


All: Thank you for taking part in this thread and helping me with my doubts ;) .
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Avor Nadal wrote:What you commented about the JVM making its own assumptions (if they're safe) makes sense to me too. I didn't know whether the JVM considered the bytecode generated by javac already safe in this sense or needed to do its own analysis before. But reading the specifications that you've linked, it's more clear. After having checked the bytecode, I guess that a JVM considers the new code derived (optimised) from it also safe, Right?.


No idea. And TBH, I wonder if it shouldn't be added to the DontSweatIt page.

Optimization is the compiler's (or JVM's) business, not mine; and all I can hope is that any inlining or other stuff like "happens-before" that it works out doesn't have any effect on what my code does. The mere fact that the language has been around for 20 years without too many problems seems like a reasonable indication that that's true.

Indeed, most problems seem to crop up when people try to code in a particular way, based on assumptions about what they do. Anyone remember the "double-check" idiom?

Winston
 
Avor Nadal
Ranch Hand
Posts: 157
Netbeans IDE Postgres Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:Indeed, most problems seem to crop up when people try to code in a particular way, based on assumptions about what they do.



Touché! It's one of my defects. I always need to know why things work as they do, he he he. Thank you for your help .
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Avor Nadal wrote:Touché! It's one of my defects....Thank you for your help .


You're most welcome.

Winston
 
reply
    Bookmark Topic Watch Topic
  • New Topic