[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [jdt-dev] Read access to enclosing field is emulated by a syn thetic accesso r method. Increasing its visibility will improve your pe r f ormance

You need to get the Inner Classes Specifications (part of the JDK1.1
documentation on the Sun web site).

If an inner class is accessing a private member from the enclosing class,
the compiler will generate an access method inside the enclosing class.

It states this from the specs:
"Names of generated variables and methods
As we have seen previously, if an inner class uses a variable from an
enclosing scope, the name expression will be transformed, into a reference
either to a field of an enclosing instance, or to a field of the current
instance which provides the value of a final local variable. A reference to
an enclosing instance, in turn, is transformed into a reference to a field
in a more accessible current instance. These techniques require that the
compiler synthesize hidden fields in inner classes.


There is one more category of compiler-generated members. A private member
m of a class C may be used by another class D, if one class encloses the
other, or if they are enclosed by a common class. Since the virtual machine
does not know about this sort of grouping, the compiler creates a local
protocol of access methods in C to allow D to read, write, or call the
member m. These methods have names of the form access$0, access$1, etc.
They are never public. Access methods are unique in that they may be added
to enclosing classes, not just inner classes.


All generated variables and methods are declared in a class file attribute,
so that the 1.1 compilers can prevent programs from referring to them
directly. "


If you want more details, please retrieve the whole specs (part of the
JDK1.1 documentation on the Sun web site).





Of course it works without changing the visibility. The compiler simply
gives a warning that the user needs to be aware that an acces method needs
to be invoked to get the private member value or to set the value of a
private member.


To the first question, the answer is:


The performance issue is a consequence of the JLS specification for inner
classes. All java compilers use these access methods.


That's all. I won't try to convince people to change the visibility to get
rid of these warnings. The generated .class files contain  an access method
that can be targetted by malicious code to change the value of a private
member. Even if a java compiler might prevent from compiling such code, it
is not difficult to generate a .class file without a java compiler that
could use these access methods. So the argument of not changing the
visibility to prevent illegal access is wrong.


Hope this help,


Olivier





                                                                                                                                                    
                      Gary Gregory                                                                                                                  
                      <ggregory@seagull        To:       "'jdt-dev@xxxxxxxxxxx'" <jdt-dev@xxxxxxxxxxx>                                              
                      sw.com>                  cc:                                                                                                  
                      Sent by:                 Subject:  RE: [jdt-dev] Read access to enclosing field is emulated by a syn              thetic      
                      jdt-dev-admin@ecl         accesso r method. Increasing its visibility will improve your pe     r     f ormance                
                      ipse.org                                                                                                                      
                                                                                                                                                    
                                                                                                                                                    
                      04/23/03 02:22 PM                                                                                                             
                      Please respond to                                                                                                             
                      jdt-dev                                                                                                                       
                                                                                                                                                    
                                                                                                                                                    




Olivier,


Thanks for the quick reply.


I am discussing whether or not we should code to remove these warnings with
folks on the Apache Jakarta Commons Dev mailing list. The current questions
I get back are:


        "Small Q: Are these really compiler warnings, or due to some plugin
in eclipse? i.e. are the performance implications due to java specs, or a
particular jvm implementation etc."


        "I don't see a problem here because the code compiles and works.
This
warning shouldn't be the sole basis for making fields more visible."


        "Moreover, this "warning" is suggesting that we change the level of
visibility here.  This is more than style, changing from private to
protected is a semantic difference."


I took a look at the JLS and JVM specs but could not find the behavior
described ("a method invocation each time you access the member at
runtime").


Could you give me an 'official' Java reference in a spec on this?


Thank you,
Gary


-----Original Message-----
From: Olivier Thomann [mailto:Olivier_Thomann@xxxxxxxxxx]
Sent: Tuesday, April 22, 2003 1:15 PM
To: jdt-dev@xxxxxxxxxxx
Subject: RE: [jdt-dev] Read access to enclosing field is emulated by a syn
thetic accesso r method. Increasing its visibility will improve your per f
ormance


You get this warning as soon as you access a private member (fields or
methods) of the enclosing class inside an inner class (anonymous, local or
member classes).


The compiler uses a static access method to access the private member in
order to workaround the VM access violation. You cannot access directly a
private member from another class. From the VM point of view, an inner
class is a different class and has no relation with its enclosing class.


So doing this access to a private member you pay the price of a method
invocation each time you access the member at runtime. This is not the case

if the member is package visible.


HTH,


Olivier








                      Gary Gregory


                      <ggregory@seagull        To:
"'jdt-dev@xxxxxxxxxxx'" <jdt-dev@xxxxxxxxxxx>


                      sw.com>                  cc:


                      Sent by:                 Subject:  RE: [jdt-dev] Read
access to enclosing field is emulated by a syn        thetic accesso r


                      jdt-dev-admin@ecl         method. Increasing its
visibility will improve your per  f ormance


                      ipse.org






                      04/22/03 02:12 PM


                      Please respond to


                      jdt-dev











Could anyone comment on what this compiler warning and its performance
implication is all about?





Read access to enclosing field GenericObjectPool._evictionCursor is
emulated by a synthetic accessor method. Increasing its visibility will
improve your performance





Thank you,





Gary





-----Original Message-----
From: Gary Gregory [mailto:ggregory@xxxxxxxxxxxxx]
Sent: Friday, March 21, 2003 9:25 AM
To: 'jdt-dev@xxxxxxxxxxx'
Subject: RE: [jdt-dev] Read access to enclosing field is emulated by a syn
thetic accesso r method. Increasing its visibility will improve your perf
ormance





So sorry! Mille sabords! Je m'excuse.
Gary
-----Original Message-----
From: Jerome Lanneluc [mailto:jerome_lanneluc@xxxxxxxxxx]
Sent: Friday, March 21, 2003 3:24 AM
To: jdt-dev@xxxxxxxxxxx
Subject: Re: [jdt-dev] Read access to enclosing field is emulated by a
synthetic accesso r method. Increasing its visibility will improve your
performance





Gary,
You didn't attach your test case class.
Jerome





|---------+---------------------------->
|         |           Gary Gregory     |
|         |           <ggregory@seagull|
|         |           sw.com>          |
|         |           Sent by:         |
|         |           jdt-dev-admin@ecl|
|         |           ipse.org         |
|         |                            |
|         |                            |
|         |           03/21/2003 01:07 |
|         |           AM               |
|         |           Please respond to|
|         |           jdt-dev          |
|         |                            |
|---------+---------------------------->
  >
------------------------------------------------------------------------------------------------------------------------|






|                                                                                                                        







  |       To:       "'jdt-dev@xxxxxxxxxxx'" <jdt-dev@xxxxxxxxxxx>
|





  |       cc:
|





  |       Subject:  [jdt-dev] Read access to enclosing field is emulated by

a synthetic accesso r method. Increasing its   |





  |        visibility will improve your performance
|






|                                                                                                                        







  >
------------------------------------------------------------------------------------------------------------------------|








Hello All,





In some code I get eclipse compiler warnings like:





Read access to enclosing field GenericObjectPool._evictionCursor is
emulated by a synthetic accessor method. Increasing its visibility will
improve your performance    GenericObjectPool.java  Jakarta
Commons/pool/src/java/org/apache/commons/pool/impl      line 1005





I have created the attached test in order to see what improvements we are
talking about. I tried to make the test as simple as possible. On the JRE
1.4.1, sometimes but not always, using "a synthetic accessor method" is
slower, sometimes faster. Can you explain what is going on here? On JRE
1.3.1, the synthetic version is always slower (good). Can this be explained


away by GC? Or some other internal process?





Thank you,
Gary





Eclipse Platform
Version: 2.1.0
Build id: 200303071024





Test results:





Running Java 1.3.1_07-b02 on Windows XP 5.1 null





iterations = 1000
withWarningMsecs = 0
noWarningMsecs = 0
no difference





iterations = 10000
withWarningMsecs = 10
noWarningMsecs = 0
no warning class is faster by 10 msecs





iterations = 100000
withWarningMsecs = 10
noWarningMsecs = 0
no warning class is faster by 10 msecs





iterations = 1000000
withWarningMsecs = 30
noWarningMsecs = 20
no warning class is faster by 10 msecs





iterations = 10000000
withWarningMsecs = 290
noWarningMsecs = 241
no warning class is faster by 49 msecs





iterations = 100000000
withWarningMsecs = 2663
noWarningMsecs = 2354
no warning class is faster by 309 msecs





Done.





----------------------------------------------------------





Running Java 1.4.1_02-b06 on Windows XP 5.1 Service Pack 1





iterations = 1000
withWarningMsecs = 10
noWarningMsecs = 0
no warning class is faster by 10 msecs





iterations = 10000
withWarningMsecs = 0
noWarningMsecs = 0
no difference





iterations = 100000
withWarningMsecs = 10
noWarningMsecs = 10
no difference





iterations = 1000000
withWarningMsecs = 90
noWarningMsecs = 90
no difference





iterations = 10000000
withWarningMsecs = 811
noWarningMsecs = 821
no warning class is SLOWER by 10 msecs





iterations = 100000000
withWarningMsecs = 8152
noWarningMsecs = 8092
no warning class is faster by 60 msecs





Done.












_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-dev










_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-dev