harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rogers <ian.rog...@manchester.ac.uk>
Subject Re: [M9] Downloads page
Date Wed, 15 Apr 2009 21:46:34 GMT
Thanks Tim! I've got it, I will update MRP to use Harmony M9, I'm just
wrestling with the fact RVM never implemented parts of the JNI spec.

2009/4/15 Jin Mingjian <jin.phd@gmail.com>

> Hi, Ian, interesting project, seem new effort on windows jikesrvm. Can the
> svn codes of this project be built successfully now?
>  "reduced use of C code" is a good principle. In my testing, One thing is
> that the harmony VM/classlibrary heavily use the native port layer.



Hi Jin,

I've not done rigorous testing of the git repository, it's where I'm keeping
my working code which shouldn't have too many hard wired paths (other than
in the appropriate property files). With the current MRP code it can run
part way through the boot sequence before failing with JNI problems. The
biggest problem I've yet to solve is with the Windows signal handlers. The
previous scheme relied upon using sigaltstack, to specify a stack to be used
by a thread's signal handler. In the current RVM there are 3 stacks per
thread (actually there is another that is a memory leak), the 1st stack is
the native thread's stack, then a stack allocated in the Java heap is used
for running Java code and finally a 3rd stack is used for the thread's
signal handler. A consequence of this approach is it allows the compiler not
to maintain ESP pointing to the bottom of the stack frame (the optimizing
compiler takes advantage of this). This approach can't work on Windows as
there is no sigaltstack equivalent, there is something in the DRLVM code
base but I don't believe that's as generic as sigaltstack and just handles
tricky stack overflow exceptions for DRLVM. I know naively switching stacks
(swapping the values of EBP and ESP) can't work as I tracked memory
corruption bugs in Windows system calls down to this. The whole stack, stack
overflow and signal handling mechanism needs a rethink.

As you say I'm heavily using the portability library, so I'm turning up some
issues [1]. It's a shame there were no GSoC applicants for the project to
clean up the portability library. I'll try to document this at some point so
other/future VMs can avoid porting pain.

If you don't mind some pain then I would certainly like help on the MRP code
base.

Regards,
Ian

[1] http://issues.apache.org/jira/browse/HARMONY-6138


> regards,
> Jin
>
>
>
> 2009/4/15 Ian Rogers <ian.rogers@manchester.ac.uk>
>
> > Sorry to be a little off topic, would it be possible when making the
> > binaries to generate the pdb debugger symbols? I'm trying to debug a
> built
> > Harmony M8 with my VM [1]. I'm using the binary drop as I don't want to
> > rely
> > on Visual C, just the express edition which doesn't come with ATL needed
> > for
> > a Harmony build.
> >
> > Thanks,
> > Ian
> >
> > [1] http://mrp.codehaus.org/
> >
> > 2009/4/15 Tim Ellison <t.p.ellison@gmail.com>
> >
> > > yeah, sorry, I meant AMD64  :-) i.e. what in our build system we label
> > > as "x86_64"
> > >
> > > It would be good to provide a set of "windows-x86_64" binaries.
> > >
> > > Regards,
> > > Tim
> > >
> > > Nathan Beyer wrote:
> > > > Ugh. I can't keep up anymore. IA-64 used to mean Intel Itanium
> > > > Architecture and Intel64 used to be EM64T.
> > > >
> > > > -Nathan
> > > >
> > > > On Tue, Apr 14, 2009 at 3:05 PM, Gregory Shimansky
> > > > <gshimansky@apache.org> wrote:
> > > >> On 14 April 2009 Nathan Beyer wrote:
> > > >>> Is IA64 itanium or x86-64?
> > > >> I guess it is x86-64 although the official naming for this platform
> by
> > > intel
> > > >> is intel64 (don't ask me why). Harmony verfion for Itanium on
> windows
> > is
> > > even
> > > >> less supported than Itanium on linux which means most likely it
> > doesn't
> > > even
> > > >> compile.
> > > >>
> > > >>> Sent from my iPhone
> > > >>>
> > > >>> On Apr 14, 2009, at 5:55 AM, Tim Ellison <t.p.ellison@gmail.com>
> > > wrote:
> > > >>>> I'm just in the process of updating our download page with
links
> to
> > > >>>> Milestone M9 (r761593).
> > > >>>>
> > > >>>> As a courtesy we usually include multiple binary downloads
too.
> >  I've
> > > >>>> got binaries for Windows and Linux IA32, and Linux IA64. 
We
> usually
> > > >>>> include a few more, so if anyone can help build the following
I'd
> > like
> > > >>>> to include them too:
> > > >>>>
> > > >>>> - Linux IA32 for systems with libstdc++.so.5
> > > >>>> - Linux IA64 for systems with libstdc++.so.5
> > > >>>> - Windows IA64
> > > >>>> - Debian packages
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Tim
> > > >>
> > > >>
> > > >> --
> > >
> >
> >
> > > >> Gregory
> > > >>
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message