harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [build] HWA doesn't work
Date Mon, 04 Dec 2006 11:33:46 GMT
My understanding is that the SetBCPElement() should be a private
member of BootstrapClassLoader but not public. Altering bootclasspath
at runtime after complete initialization is not an allowable thing,
and this should be enforced by design.
So we may leave "inline" pragma in the definition (which is mostly
useless though), and must fix the declaration and an improper use-case
of the method (added recently for magics).
Any objections?

--
Alexey

2006/12/1, Dmitry Irlyanov <irlyanov@gmail.com>:
> Ivan, Geir
>
> I've tested your proposition on revision: 480581. Result is negative.
> File modifying: harmony/trunk/working_vm/vm/vmcore/include/classloader.h
> (
> -    void SetBCPElement(const char *path, apr_pool_t *tmp_pool);
> +    inline void SetBCPElement(const char *path, apr_pool_t *tmp_pool);
> )
> The result is:
> /harmony/trunk/working_vm/build/lnx_ia32_icc_release/deploy/jre/bin/java -cp
> . Hello
> Failed to open JVM DLL:
> /nfs/ims/proj/drl/mrt/users/irlyanov/harmony/trunk/working_vm/build/lnx_ia32_icc_release/deploy/jre/bin/default/harmonyvm
> (/nfs/ims/proj/drl/mrt/users/irlyanov/harmony/trunk/working_vm/build/lnx_ia32_icc_release/deploy/jre/bin/default/libharmonyvm.so:
> undefined symbol: _ZN20BootstrapClassLoader13SetBCPElementEPKcP10apr_pool_t)
>
> Nevertheless, I propose to apply the JIRA-2375 issue due to there is no
> performance waste, but the raise of universality.
> This is release version characteristic only.
> It is the compiler peculiarity (if you will, the bug) but I can't see the
> motive to stop the patch committing.
> Note also that this bug is the reason of windows icl release building, so
> the priority of this issue is higher.
>
>
> 2006/12/1, Geir Magnusson Jr. <geir@pobox.com>:
> >
> > That's a reasonable argument.  Move the definition to the header file
> > then.
> >
> > geir
> >
> >
> > Ivan Volosyuk wrote:
> > > I will call it a bug in source base, because if we define inline
> > > function in cpp file it should only be used inside it. Any public
> > > inline functions should be defined in header files.
> > >
> > > Intel compiler is much more aggressive for optimizations, this require
> > > a cleaner code to be written in order to use it. Some of the
> > > optimizations trigger bugs in source which are happily invisible by
> > > other compilers, I recall one such a case which I have fixed only
> > > after attentive examination of generated machine code.
> > > --
> > > Ivan
> > >
> > > On 11/30/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > >> On 11/30/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >> >
> > >> >
> > >> > I absolutely don't understand how you can claim a "hint" like
> > "inline"
> > >> > can be considered a bug in the source when the sourcebase is being
> > >> > compiled by the same compiler.  can you explain?
> > >> >
> > >> > The only logical reason I can find is a miscommunication between
> > >> compiler
> > >> and linker.
> >
>
>
>
> --
> _______________
> With Best Regards,
> Irlyanov Dmitry
> Intel Corporation
> Middleware Products Division
>
>

Mime
View raw message