Menu
▾
▴
#145 instantiate java.lang.Class objects during bootimagewriting
Recent changes to the bootimage writer should allow us
to correctly translate instances of java.lang.Class
from bootimage writing time to runtime.
Using this facility, eliminate the current code that
defers the create of java.lang.Class instances from
booimage writing time to runtime.
(see VM.boot, and follow the code paths from there).
Also, we should restructure VM_Type such that
java.lang.Class instances are created for all VM_Class
and VM_Array instances as part of instatiation. The
way GNU classpath is structured now, we end up creating
java.lang.Class objects anyways as part of
classloading, so we may as well go ahead and do it up
front instead of via the current convoluted mechanism.
Logged In: YES
user_id=308843
I'm looking at removing VM.createClassObjects for class
literals currently. I'm not entirely sure of the
difficulties in removing this for static synchronized methods.
Ian
Logged In: YES
user_id=1215435
Hi Ian,
It should be mostly a matter of code deletion, but don't
feel obligated to do it. I opened this mainly as "TODO" so
I wouldn't forget that I wanted this to get cleaned up
before the next release. It's the kind of thing I think I
can slam through in about 30 minutes, but don't have time to
do this week. Spending my Jikes RVM time mainly on
bootimage writer classpath issues right now.
Logged In: YES
user_id=1215435
Of course, if you want to do it go ahead...
the static synch methods is much the same as class literals.
The compilers make a call to create(or defer the creation)
of a class object when they compile a static sync method.
Just change it to always create should do it.
The other change is for creating them unconditionally during
instantiation is slightly more involved.
Feel free to do as much or little of this as you want. I'll
finish off whatever is left over the weekend or next week.
Logged In: YES
user_id=308843
This is fixed in patch #1570936
Logged In: YES
user_id=308843
As of 10944 we do this. When it appears we're passing
regressions again I'd like to close this.
Ian
Logged In: YES
user_id=308843
Originator: NO
Fixed?
Logged In: YES
user_id=1215435
Originator: YES
agreed.
Administrative question; I think you should be to change the state of this to closed yourself (possibly only after assigning it to yourself?). If you can't do that let me know since it means that there's something in the way your account is setup that isn't right.
Logged In: YES
user_id=308843
Originator: NO
Hi Dave, no way to assign this bug to myself. Don't know why, maybe I can only assign bugs I create. Sorry, Ian