You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/06/15 17:55:40 UTC
[drlvm] build - first round done
Ok, first round is committed.
It's been tested on winXP, not linux, and will get to that later, there
still are some tweaks...
First, this is pretty primitive, and some things are really crude. I'm
sure we'll collectively fix and evolve.
The two main things :
1) it uses a property to find the classlib on the local filesystem, it
doesn't build it, and assumes that it's done.
2) it works (according to build test) w/ the newest version of classlib
I'm going to keep drilling on it. I'd like to reuse the work that was
there to help get a shared dependency cache for all components of Harmony.
I'm also going to take a swipe at doing the 'federation' we talked about
last week.
Suggestions and discussion always welcome.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Rana Dasgupta <rd...@gmail.com>.
On 6/16/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> > >Talking of this maybe enable debug by default for DRL VM? It is used by
> > >developers for development for the most part at the moment so
> assertions and
> >> symbol info may be quite useful. Also debug is built faster because it
> is not
> >> optimized.
>
> >Makes sense. So how do we do it? :)
Here's the table for switching compiler and build mode...
On Windows*: | On Linux*:
---------------------------
--------------------------
MSVC compiler : set CXX=msvc # | N/A
Intel(R) compiler : set CXX=icl | export
CXX=icc
GCC compiler : N/A | export
CXX=gcc #
Release : set BUILD_CFG=release # | export
BUILD_CFG=release #
Debug : set BUILD_CFG=debug | export
BUILD_CFG=debug
# - default values
Thanks,
Rana
geir
>
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [drlvm] build - first round done
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Gregory Shimansky wrote:
> On Friday 16 June 2006 16:29 Gregory Shimansky wrote:
>> 2006/6/16, Geir Magnusson Jr <ge...@pobox.com>:
>>> Gregory Shimansky wrote:
>>>> Sorry for delay, JIRA is painfully slow for me today. I submitted
>>>> HARMONY-612.
>>>>
>>>> The reason I didn't do it immidiatelly is that I thought I am missing
>>>> something and you have the fix already somewhere as you wrote that VM
>>>> worked
>>>> on WinXP for you.
>>> 'worked' is an overstatement. It survived the smoke test.
>> This is strange because for it it failed on hello world application and in
>> the very beginning of it. Could it be that some jar file with old API
>> version was floating around, maybe from CLASSLIB build (which checked out
>> some old revision of classlib) which was done by VM itself?
>
> Answering to myself. I've guessed the difference why you didn't have assertion
> fails. I've enabled debug build mode when all assertions are enabled. You
> built release with assertions disabled so everything worked for you.
>
> Talking of this maybe enable debug by default for DRL VM? It is used by
> developers for development for the most part at the moment so assertions and
> symbol info may be quite useful. Also debug is built faster because it is not
> optimized.
Makes sense. So how do we do it? :)
geir
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 16 June 2006 16:29 Gregory Shimansky wrote:
> 2006/6/16, Geir Magnusson Jr <ge...@pobox.com>:
> > Gregory Shimansky wrote:
> > > Sorry for delay, JIRA is painfully slow for me today. I submitted
> > > HARMONY-612.
> > >
> > > The reason I didn't do it immidiatelly is that I thought I am missing
> > > something and you have the fix already somewhere as you wrote that VM
> > > worked
> > > on WinXP for you.
> >
> > 'worked' is an overstatement. It survived the smoke test.
>
> This is strange because for it it failed on hello world application and in
> the very beginning of it. Could it be that some jar file with old API
> version was floating around, maybe from CLASSLIB build (which checked out
> some old revision of classlib) which was done by VM itself?
Answering to myself. I've guessed the difference why you didn't have assertion
fails. I've enabled debug build mode when all assertions are enabled. You
built release with assertions disabled so everything worked for you.
Talking of this maybe enable debug by default for DRL VM? It is used by
developers for development for the most part at the moment so assertions and
symbol info may be quite useful. Also debug is built faster because it is not
optimized.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Gregory Shimansky <gs...@gmail.com>.
On Saturday 17 June 2006 14:07 Geir Magnusson Jr wrote:
> Gregory Shimansky wrote:
> > On Friday 16 June 2006 22:31 Rana Dasgupta wrote:
> >> Also, are we incrementally fixing all the 1.5 related issues as we find
> >> them?
> >
> > This is not exactly 1.5 issue yet. It is 1.5 classlib compiled as 1.4
> > issue :)
>
> I don't understand that statement. These changes are there supporting
> the evolution in java.lang.Class from 1.4 to 1.5 right?
I meant that the problem was not in some special 1.5 functionality like class
file format or new types. It was just new classes which are handled in the
same 1.4 way.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Gregory Shimansky wrote:
> On Friday 16 June 2006 22:31 Rana Dasgupta wrote:
>
>> Also, are we incrementally fixing all the 1.5 related issues as we find
>> them?
>
> This is not exactly 1.5 issue yet. It is 1.5 classlib compiled as 1.4 issue :)
I don't understand that statement. These changes are there supporting
the evolution in java.lang.Class from 1.4 to 1.5 right?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Rana Dasgupta wrote:
> Pls see below...
>
> On 6/17/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>>
>>
>> >> In which case, we may be better off updating DRLVM to
>> >>handle the full 1.5 compile instead of doing these hardloads.
>> >What is a "hardload"?
>
>
> Typo :-) hardcoding the creation of the lang/Class superinterfaces.
Ah. yeah, I was pondering that too. It would be nice if we could code
generate from the classlib as part of the build process or something..
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Rana Dasgupta <rd...@gmail.com>.
Pls see below...
On 6/17/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
>
> >> In which case, we may be better off updating DRLVM to
> >>handle the full 1.5 compile instead of doing these hardloads.
> >What is a "hardload"?
Typo :-) hardcoding the creation of the lang/Class superinterfaces.
> > And we can just treat these hard changes as partial fixes to keep
> things
> >> working, pending the full DRLVM update, and drop completely the need to
> >> keep
> >> a version 1.4 compatible. Could someone advise if that is OK?
>
> >We don't really *need* to be 1.4 compatible.
OK, thanks for clarifying.
Thanks,
Rana
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [drlvm] build - first round done
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Rana Dasgupta wrote:
> On 6/16/06, Gregory Shimansky <gshimansky@gmail.com > wrote:
>>> Also, are we incrementally fixing all the 1.5 related issues as we find
>> >> them?
>>
>> >This is not exactly 1.5 issue yet. It is 1.5 classlib compiled as
>> 1.4issue :)
>>
>> >Actually there is a question of whether we want the VM to still work
>> with
>> 1.4
>> >*only* classlib. Adding hardcoded loads for 1.5 only interfaces to the
>> code
>> >will make it unable to work with classlib which doesn't have these
>> classes. I
>> >am not sure if it is bad or not.
>
>
> Yes, that was my question also, about this incremental move to 1.5. The
> way we are compiling the classlibs currently... with
> source=1.5target=jsr14|1.4 flags is surely just a temporary step on
> the way to fully
> switching to 1.5?
Or course.
> In which case, we may be better off updating DRLVM to
> handle the full 1.5 compile instead of doing these hardloads.
What is a "hardload"?
> And we can just treat these hard changes as partial fixes to keep things
> working, pending the full DRLVM update, and drop completely the need to
> keep
> a version 1.4 compatible. Could someone advise if that is OK?
We don't really *need* to be 1.4 compatible.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Rana Dasgupta <rd...@gmail.com>.
On 6/16/06, Gregory Shimansky <gshimansky@gmail.com > wrote:
>
> >This won't make anything good. The class_handle which is a pointer to
> java
> >heap object of type java.lang.Class is used very often, I am even
> surprised
> >that hello world even worked without java.lang.Class superinterfaces
> >instances, but perhaps they aren't used much yet. If class_handle for
> Class
> >struct is not initialized with an object instance pointer it will be null
> and
> >who knows when the object is needed. Reflection may surely trigger
> request
> >for it.
OK, thanks Gregory.
>> Also, are we incrementally fixing all the 1.5 related issues as we find
> >> them?
>
> >This is not exactly 1.5 issue yet. It is 1.5 classlib compiled as 1.4issue :)
>
> >Actually there is a question of whether we want the VM to still work with
> 1.4
> >*only* classlib. Adding hardcoded loads for 1.5 only interfaces to the
> code
> >will make it unable to work with classlib which doesn't have these
> classes. I
> >am not sure if it is bad or not.
Yes, that was my question also, about this incremental move to 1.5. The
way we are compiling the classlibs currently... with
source=1.5target=jsr14|1.4 flags is surely just a temporary step on
the way to fully
switching to 1.5? In which case, we may be better off updating DRLVM to
handle the full 1.5 compile instead of doing these hardloads.
And we can just treat these hard changes as partial fixes to keep things
working, pending the full DRLVM update, and drop completely the need to keep
a version 1.4 compatible. Could someone advise if that is OK?
Thanks,
Rana
> --
> Gregory Shimansky, Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [drlvm] build - first round done
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 16 June 2006 22:31 Rana Dasgupta wrote:
> I am also trying to understand the flow here. But since this is a dummy
> bootstrap case, would it make sense to just disable this assert instead of
> instantiating all the new interfaces and resolving everything, or is this
> instantiation necessary for the bootstrap in which case the assert of
> course makes sense?
This won't make anything good. The class_handle which is a pointer to java
heap object of type java.lang.Class is used very often, I am even surprised
that hello world even worked without java.lang.Class superinterfaces
instances, but perhaps they aren't used much yet. If class_handle for Class
struct is not initialized with an object instance pointer it will be null and
who knows when the object is needed. Reflection may surely trigger request
for it.
> Also, are we incrementally fixing all the 1.5 related issues as we find
> them?
This is not exactly 1.5 issue yet. It is 1.5 classlib compiled as 1.4 issue :)
Actually there is a question of whether we want the VM to still work with 1.4
*only* classlib. Adding hardcoded loads for 1.5 only interfaces to the code
will make it unable to work with classlib which doesn't have these classes. I
am not sure if it is bad or not.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Rana Dasgupta <rd...@gmail.com>.
Sorry for these multiple postbacks ....
On 6/16/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
> >The assert makes sense as a safety, IMO.
>
> >Notice how it caught this which hinted at work that had to be done
> >elsewhere.
Yes, but the assert should not be giving us misleading information. If it is
> running fine in release but asserts in debug on the same program ... that
> should be saying that the assert is either overactive or may be bypassed.
> Unless there were other code changes ? Probably I am confused. I will build
> and try it both ways after a good night's sleep :-)
Thanks,
Rana
---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [drlvm] build - first round done
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Rana Dasgupta wrote:
> Hi Gregory/Geir,
> Sorry for jumping in, but I have a question...
>
>
> On 6/16/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> >This method as the name says allocates a java.lang.Class instance for
>> the
>> >requested class and assigns class handle to the C native Class struct.
>> But
>> >java.lang.Class cannot be allocated before java.lang.Class class is
>> loaded
>> >by VM, so there is a special bootstrap case which doesn't create any
>> object.
>>
>> >Now that I've written this I realized that the patch is not complete
>> since
>> >it doesn't create instances for these new java.lang.Class
>> superinterfaces
>> as
>> >it is done for Object, Serializable and Class itself. It is necessary to
>> do
>> >allocation it in different place. I'll correct it right now and
>> attach an
>> >additional patch to HARMONY-612.
>
>
> I am also trying to understand the flow here. But since this is a dummy
> bootstrap case, would it make sense to just disable this assert instead of
> instantiating all the new interfaces and resolving everything, or is this
> instantiation necessary for the bootstrap in which case the assert of
> course
> makes sense?
The assert makes sense as a safety, IMO.
Notice how it caught this which hinted at work that had to be done
elsewhere.
:)
> Also, are we incrementally fixing all the 1.5 related issues as we find
> them?
Probably not. But this is just because we want to to keep up w/ the
class lib. We need to do a small push to get DRLVM to understand 1.5
classfile format as a first step.
geir
>
> Thanks,
> Rana
>
> --
>> Gregory Shimansky, Intel Middleware Products Division
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Rana Dasgupta <rd...@gmail.com>.
Hi Gregory/Geir,
Sorry for jumping in, but I have a question...
On 6/16/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> >This method as the name says allocates a java.lang.Class instance for the
> >requested class and assigns class handle to the C native Class struct.
> But
> >java.lang.Class cannot be allocated before java.lang.Class class is
> loaded
> >by VM, so there is a special bootstrap case which doesn't create any
> object.
>
> >Now that I've written this I realized that the patch is not complete
> since
> >it doesn't create instances for these new java.lang.Class superinterfaces
> as
> >it is done for Object, Serializable and Class itself. It is necessary to
> do
> >allocation it in different place. I'll correct it right now and attach an
> >additional patch to HARMONY-612.
I am also trying to understand the flow here. But since this is a dummy
bootstrap case, would it make sense to just disable this assert instead of
instantiating all the new interfaces and resolving everything, or is this
instantiation necessary for the bootstrap in which case the assert of course
makes sense?
Also, are we incrementally fixing all the 1.5 related issues as we find
them?
Thanks,
Rana
--
> Gregory Shimansky, Intel Middleware Products Division
>
>
Re: [drlvm] build - first round done
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/6/16, Geir Magnusson Jr <ge...@pobox.com>:
>
>
>
> Gregory Shimansky wrote:
> > Sorry for delay, JIRA is painfully slow for me today. I submitted
> > HARMONY-612.
> >
> > The reason I didn't do it immidiatelly is that I thought I am missing
> > something and you have the fix already somewhere as you wrote that VM
> > worked
> > on WinXP for you.
>
> 'worked' is an overstatement. It survived the smoke test.
This is strange because for it it failed on hello world application and in
the very beginning of it. Could it be that some jar file with old API
version was floating around, maybe from CLASSLIB build (which checked out
some old revision of classlib) which was done by VM itself?
I'm learning.
>
> Ok, so let me learn some more. I'll apply the patch, but can you
> explain why we need this? I know that w/ the 1.5 change to Class.java,
> we now implement AnnotatedElement, GenericDeclaration and Type.
>
> Can you give some background on what this method does, and why we need
> these added? Is it because we need to register those three as well when
> Class itself is registered?
>
This method as the name says allocates a java.lang.Class instance for the
requested class and assigns class handle to the C native Class struct. But
java.lang.Class cannot be allocated before java.lang.Class class is loaded
by VM, so there is a special bootstrap case which doesn't create any object.
Now that I've written this I realized that the patch is not complete since
it doesn't create instances for these new java.lang.Class superinterfaces as
it is done for Object, Serializable and Class itself. It is necessary to do
allocation it in different place. I'll correct it right now and attach an
additional patch to HARMONY-612.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] build - first round done
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Gregory Shimansky wrote:
> Sorry for delay, JIRA is painfully slow for me today. I submitted
> HARMONY-612.
>
> The reason I didn't do it immidiatelly is that I thought I am missing
> something and you have the fix already somewhere as you wrote that VM
> worked
> on WinXP for you.
'worked' is an overstatement. It survived the smoke test.
I'm learning.
Ok, so let me learn some more. I'll apply the patch, but can you
explain why we need this? I know that w/ the 1.5 change to Class.java,
we now implement AnnotatedElement, GenericDeclaration and Type.
Can you give some background on what this method does, and why we need
these added? Is it because we need to register those three as well when
Class itself is registered?
geir
>
> 2006/6/16, Geir Magnusson Jr <ge...@pobox.com>:
>>
>> can you shove that into a JIRA please? I'll apply immediately. Thanks
>>
>> I'm sure there are more problems to be discovered. :)
>>
>> geir
>>
>>
>> Gregory Shimansky wrote:
>> > Hello Geir
>> >
>> > I've tried to build drlvm with your most recent upadtes to build
>> (revision
>> > 414775) and everything compiled fine but running hello world
>> application
>> > failed on assertion in class loader. I had to patch assertion to
>> include
>> > superinterfaces for java.lang.Class from 1.5 like this:
>> >
>> > Index: drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp
>> > ===================================================================
>> > --- drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp
>> (revision
>> > 414775)
>> > +++ drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp (working
>> > copy)
>> > @@ -1102,7 +1102,10 @@
>> > if(env->InBootstrap()) {
>> > assert((clss->name == env->JavaLangObject_String)
>> > || (strcmp(clss->name->bytes, "java/io/Serializable")
>> == 0)
>> > - || (clss->name == env->JavaLangClass_String));
>> > + || (clss->name == env->JavaLangClass_String)
>> > + || (strcmp(clss->name->bytes,
>> > "java/lang/reflect/AnnotatedElement") == 0)
>> > + || (strcmp(clss->name->bytes,
>> > "java/lang/reflect/GenericDeclaration") == 0)
>> > + || (strcmp(clss->name->bytes,
>> "java/lang/reflect/Type") ==
>> > 0));
>> > clss->class_handle = NULL;
>> > } else {
>> > Class* root_class = env->JavaLangClass_Class;
>> >
>> > The other approach would be to remove this assertion completely, but
>> either
>> > way it seems to me that to work the VM code has to be patched.
>> >
>> > 2006/6/15, Geir Magnusson Jr <ge...@pobox.com>:
>> >>
>> >> Ok, first round is committed.
>> >>
>> >> It's been tested on winXP, not linux, and will get to that later,
>> there
>> >> still are some tweaks...
>> >>
>> >> First, this is pretty primitive, and some things are really crude.
>> I'm
>> >> sure we'll collectively fix and evolve.
>> >>
>> >> The two main things :
>> >>
>> >> 1) it uses a property to find the classlib on the local filesystem, it
>> >> doesn't build it, and assumes that it's done.
>> >>
>> >> 2) it works (according to build test) w/ the newest version of
>> classlib
>> >>
>> >>
>> >> I'm going to keep drilling on it. I'd like to reuse the work that was
>> >> there to help get a shared dependency cache for all components of
>> >> Harmony.
>> >>
>> >> I'm also going to take a swipe at doing the 'federation' we talked
>> about
>> >> last week.
>> >>
>> >>
>> >> Suggestions and discussion always welcome.
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Gregory Shimansky <gs...@gmail.com>.
Sorry for delay, JIRA is painfully slow for me today. I submitted
HARMONY-612.
The reason I didn't do it immidiatelly is that I thought I am missing
something and you have the fix already somewhere as you wrote that VM worked
on WinXP for you.
2006/6/16, Geir Magnusson Jr <ge...@pobox.com>:
>
> can you shove that into a JIRA please? I'll apply immediately. Thanks
>
> I'm sure there are more problems to be discovered. :)
>
> geir
>
>
> Gregory Shimansky wrote:
> > Hello Geir
> >
> > I've tried to build drlvm with your most recent upadtes to build
> (revision
> > 414775) and everything compiled fine but running hello world application
> > failed on assertion in class loader. I had to patch assertion to include
> > superinterfaces for java.lang.Class from 1.5 like this:
> >
> > Index: drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp
> > ===================================================================
> > --- drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp (revision
> > 414775)
> > +++ drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp (working
> > copy)
> > @@ -1102,7 +1102,10 @@
> > if(env->InBootstrap()) {
> > assert((clss->name == env->JavaLangObject_String)
> > || (strcmp(clss->name->bytes, "java/io/Serializable") == 0)
> > - || (clss->name == env->JavaLangClass_String));
> > + || (clss->name == env->JavaLangClass_String)
> > + || (strcmp(clss->name->bytes,
> > "java/lang/reflect/AnnotatedElement") == 0)
> > + || (strcmp(clss->name->bytes,
> > "java/lang/reflect/GenericDeclaration") == 0)
> > + || (strcmp(clss->name->bytes, "java/lang/reflect/Type") ==
> > 0));
> > clss->class_handle = NULL;
> > } else {
> > Class* root_class = env->JavaLangClass_Class;
> >
> > The other approach would be to remove this assertion completely, but
> either
> > way it seems to me that to work the VM code has to be patched.
> >
> > 2006/6/15, Geir Magnusson Jr <ge...@pobox.com>:
> >>
> >> Ok, first round is committed.
> >>
> >> It's been tested on winXP, not linux, and will get to that later, there
> >> still are some tweaks...
> >>
> >> First, this is pretty primitive, and some things are really crude. I'm
> >> sure we'll collectively fix and evolve.
> >>
> >> The two main things :
> >>
> >> 1) it uses a property to find the classlib on the local filesystem, it
> >> doesn't build it, and assumes that it's done.
> >>
> >> 2) it works (according to build test) w/ the newest version of classlib
> >>
> >>
> >> I'm going to keep drilling on it. I'd like to reuse the work that was
> >> there to help get a shared dependency cache for all components of
> >> Harmony.
> >>
> >> I'm also going to take a swipe at doing the 'federation' we talked
> about
> >> last week.
> >>
> >>
> >> Suggestions and discussion always welcome.
>
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] build - first round done
Posted by Geir Magnusson Jr <ge...@pobox.com>.
can you shove that into a JIRA please? I'll apply immediately. Thanks
I'm sure there are more problems to be discovered. :)
geir
Gregory Shimansky wrote:
> Hello Geir
>
> I've tried to build drlvm with your most recent upadtes to build (revision
> 414775) and everything compiled fine but running hello world application
> failed on assertion in class loader. I had to patch assertion to include
> superinterfaces for java.lang.Class from 1.5 like this:
>
> Index: drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp
> ===================================================================
> --- drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp (revision
> 414775)
> +++ drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp (working
> copy)
> @@ -1102,7 +1102,10 @@
> if(env->InBootstrap()) {
> assert((clss->name == env->JavaLangObject_String)
> || (strcmp(clss->name->bytes, "java/io/Serializable") == 0)
> - || (clss->name == env->JavaLangClass_String));
> + || (clss->name == env->JavaLangClass_String)
> + || (strcmp(clss->name->bytes,
> "java/lang/reflect/AnnotatedElement") == 0)
> + || (strcmp(clss->name->bytes,
> "java/lang/reflect/GenericDeclaration") == 0)
> + || (strcmp(clss->name->bytes, "java/lang/reflect/Type") ==
> 0));
> clss->class_handle = NULL;
> } else {
> Class* root_class = env->JavaLangClass_Class;
>
> The other approach would be to remove this assertion completely, but either
> way it seems to me that to work the VM code has to be patched.
>
> 2006/6/15, Geir Magnusson Jr <ge...@pobox.com>:
>>
>> Ok, first round is committed.
>>
>> It's been tested on winXP, not linux, and will get to that later, there
>> still are some tweaks...
>>
>> First, this is pretty primitive, and some things are really crude. I'm
>> sure we'll collectively fix and evolve.
>>
>> The two main things :
>>
>> 1) it uses a property to find the classlib on the local filesystem, it
>> doesn't build it, and assumes that it's done.
>>
>> 2) it works (according to build test) w/ the newest version of classlib
>>
>>
>> I'm going to keep drilling on it. I'd like to reuse the work that was
>> there to help get a shared dependency cache for all components of
>> Harmony.
>>
>> I'm also going to take a swipe at doing the 'federation' we talked about
>> last week.
>>
>>
>> Suggestions and discussion always welcome.
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] build - first round done
Posted by Gregory Shimansky <gs...@gmail.com>.
Hello Geir
I've tried to build drlvm with your most recent upadtes to build (revision
414775) and everything compiled fine but running hello world application
failed on assertion in class loader. I had to patch assertion to include
superinterfaces for java.lang.Class from 1.5 like this:
Index: drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp
===================================================================
--- drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp (revision
414775)
+++ drlvm/trunk/vm/vmcore/src/class_support/classloader.cpp (working
copy)
@@ -1102,7 +1102,10 @@
if(env->InBootstrap()) {
assert((clss->name == env->JavaLangObject_String)
|| (strcmp(clss->name->bytes, "java/io/Serializable") == 0)
- || (clss->name == env->JavaLangClass_String));
+ || (clss->name == env->JavaLangClass_String)
+ || (strcmp(clss->name->bytes,
"java/lang/reflect/AnnotatedElement") == 0)
+ || (strcmp(clss->name->bytes,
"java/lang/reflect/GenericDeclaration") == 0)
+ || (strcmp(clss->name->bytes, "java/lang/reflect/Type") ==
0));
clss->class_handle = NULL;
} else {
Class* root_class = env->JavaLangClass_Class;
The other approach would be to remove this assertion completely, but either
way it seems to me that to work the VM code has to be patched.
2006/6/15, Geir Magnusson Jr <ge...@pobox.com>:
>
> Ok, first round is committed.
>
> It's been tested on winXP, not linux, and will get to that later, there
> still are some tweaks...
>
> First, this is pretty primitive, and some things are really crude. I'm
> sure we'll collectively fix and evolve.
>
> The two main things :
>
> 1) it uses a property to find the classlib on the local filesystem, it
> doesn't build it, and assumes that it's done.
>
> 2) it works (according to build test) w/ the newest version of classlib
>
>
> I'm going to keep drilling on it. I'd like to reuse the work that was
> there to help get a shared dependency cache for all components of Harmony.
>
> I'm also going to take a swipe at doing the 'federation' we talked about
> last week.
>
>
> Suggestions and discussion always welcome.
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Gregory Shimansky, Intel Middleware Products Division