[rvm-core] status/timing of 2.9.3 release

[David P Grove]

Looking at the JIRA items still targeted for a 2.9.3 fix, I think 3 of them
may be potential release blockers (or at least need some investigation
before we decide we really can afford to push them to 2.9.4).  RVM-352 and
RVM-355 may be indicative of problems our users are actually going to
notice.  I'm not thrilled with regressing compress performance (RVM-446)
but if that was the only thing left, we might be able to live with it since
performance is up on a number of other benchmarks.

RVM-325 is probably just an indication that we are slightly underestimating
how much heap it takes to run jack (especially if the opt compiler kicks in
at exactly the wrong moment), so a tweak to the test parameters might be
all that is needed.

RVM-432 would be a really good thing to get in, but it is not a regression
over 2.9.2 so it doesn't have to be a release blocker.

RVM-315, RVM-266, and RVM-391 seem like they are not blockers.

We also have new sanity failures last night on lnxppc32 (lots of timeouts)
and some newly reported failures that are showing up due to the fix in the
testing harness that still need to be tiraged.  So, we're at least 24 hours
from being able to declare a release even if we decide to fix none of these
items.

My opinion is that we'd be better served by really trying to put a few days
of real effort into investigating & fixing problems before declaring a
release to increase the odds 2.9.3 a strict improvement over 2.9.2.
Personally, I can't do this next week, but would have some time the week
after.  Hopefully other people will have some time as well over the next
two weeks and we can put a concerted effort into squashing a bunch of
issues so that 2.9.3 will be a very solid release.

What do others think?

--dave


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

On 24/04/2008, David P Grove <groved@...> wrote:

>
>  Looking at the JIRA items still targeted for a 2.9.3 fix, I think 3 of them
>  may be potential release blockers (or at least need some investigation
>  before we decide we really can afford to push them to 2.9.4).  RVM-352 and
>  RVM-355 may be indicative of problems our users are actually going to
>  notice.  I'm not thrilled with regressing compress performance (RVM-446)
>  but if that was the only thing left, we might be able to live with it since
>  performance is up on a number of other benchmarks.
>
>  RVM-325 is probably just an indication that we are slightly underestimating
>  how much heap it takes to run jack (especially if the opt compiler kicks in
>  at exactly the wrong moment), so a tweak to the test parameters might be
>  all that is needed.
>
>  RVM-432 would be a really good thing to get in, but it is not a regression
>  over 2.9.2 so it doesn't have to be a release blocker.
>
>  RVM-315, RVM-266, and RVM-391 seem like they are not blockers.
>
>  We also have new sanity failures last night on lnxppc32 (lots of timeouts)
>  and some newly reported failures that are showing up due to the fix in the
>  testing harness that still need to be triaged.  So, we're at least 24 hours
>  from being able to declare a release even if we decide to fix none of these
>  items.
>
>  My opinion is that we'd be better served by really trying to put a few days
>  of real effort into investigating & fixing problems before declaring a
>  release to increase the odds 2.9.3 a strict improvement over 2.9.2.
>  Personally, I can't do this next week, but would have some time the week
>  after.  Hopefully other people will have some time as well over the next
>  two weeks and we can put a concerted effort into squashing a bunch of
>  issues so that 2.9.3 will be a very solid release.
>
>  What do others think?
>
>  --dave
>
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Jikesrvm-core mailing list
>  Jikesrvm-core@...
>  https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

RVM-266 is a blocker, because the implementation is half there and the
current patchset added to Classpath introduces a bug.  It either needs
to be finished or the patches rolled out. Finishing it would actually
be pretty simple; I have the patches here.  However, as I mentioned
earlier this week, I can't seem to build the RVM at the moment without
hacking build.xml.  Is there any resolution on this yet? I can't get a
clean build on two different machines to work anymore with the same
setup that worked a few weeks back when I was committing stuff.
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[David P Grove]

> RVM-266 is a blocker, because the implementation is half there and the
> current patchset added to Classpath introduces a bug.  It either needs
> to be finished or the patches rolled out. Finishing it would actually
> be pretty simple; I have the patches here.  However, as I mentioned
> earlier this week, I can't seem to build the RVM at the moment without
> hacking build.xml.  Is there any resolution on this yet? I can't get a
> clean build on two different machines to work anymore with the same
> setup that worked a few weeks back when I was committing stuff.

ok.  I raised the priority of 266.

Is there a JIRA entry for your build problem?  I'm not sure if there's
anything we can do to help you debug it (it's working for me just fine),
but I didn't even realize you were having a problem.

--dave


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

I think we're about ready to start tagging for the 2.9.3 release. The
current issues are [1]:

RVM-266     Investigate GCJ's StringBuffer
RVM-456     Clean build broken
RVM-432     Fix GNU classpath build on x86_64

I believe Andrew is solving RVM-266 and I think both RVM-432 and RVM-456
are best postponed until we're more comfortable with what make good
build defaults (the proposed patches don't work on either my or Dave's
machine set up). I'd like to think we can have a release tagged and
ready next week.

I have some structural changes I'd like to fast track for the 2.9.4
release to improve the modularity of the object model. These will
support research at Manchester and hopefully the University of Texas.
I'd like to get these in ASAP as they will support research and improve
the feel of the code base. The quality of our software engineering will
be an ever more important aspect of the RVM with other clones of RVM
coming out like [2].

Regards,
Ian

[1]
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=11591&fixfor=13726
[2]
http://www28.cplan.com/cc191/session_details.jsp?isid=295169&ilocation_id=191-1&ilanguage=english
--
Third International Workshop on Implementation, Compilation,
Optimization of Object-Oriented Languages, Programs and Systems
(ICOOOLPS 2008)
July 7, Paphos (Cyprus) http://icoolps.loria.fr

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

On 26/04/2008, Ian Rogers <rogers.email@...> wrote:

> I think we're about ready to start tagging for the 2.9.3 release. The
>  current issues are [1]:
>
>  RVM-266     Investigate GCJ's StringBuffer
>  RVM-456     Clean build broken
>  RVM-432     Fix GNU classpath build on x86_64
>
>  I believe Andrew is solving RVM-266 and I think both RVM-432 and RVM-456
>  are best postponed until we're more comfortable with what make good
>  build defaults (the proposed patches don't work on either my or Dave's
>  machine set up). I'd like to think we can have a release tagged and
>  ready next week.
>
>  I have some structural changes I'd like to fast track for the 2.9.4
>  release to improve the modularity of the object model. These will
>  support research at Manchester and hopefully the University of Texas.
>  I'd like to get these in ASAP as they will support research and improve
>  the feel of the code base. The quality of our software engineering will
>  be an ever more important aspect of the RVM with other clones of RVM
>  coming out like [2].
>
>  Regards,
>  Ian
>
>  [1]
>  http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=11591&fixfor=13726
>  [2]
>  http://www28.cplan.com/cc191/session_details.jsp?isid=295169&ilocation_id=191-1&ilanguage=english
>
> --
>  Third International Workshop on Implementation, Compilation,
>  Optimization of Object-Oriented Languages, Programs and Systems
>  (ICOOOLPS 2008)
>  July 7, Paphos (Cyprus) http://icoolps.loria.fr
>
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Jikesrvm-core mailing list
>  Jikesrvm-core@...
>  https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

Unfortunately, postponing some form of fix for RVM-456 means I can't
actually go out and fix RVM-266... On the positive side, I think I
have a patch.  If someone with a proprietary old-style javah can test
this and confirm it works for them too, I'll commit it.  Note that I
still find the issue odd as I was using OpenJDK to build before (which
should be the same or newer than OpenJDK6) without seeing these
issues, but that this actually highlights an implicit dependency we
had on the naming of the header files which I think is broken in
itself.

I don't think RVM-432 is a blocker, given it seems to be a feature
enhancement (graphical support for x86_64) and this wasn't supported
in the previous release.  For me, the longer term fix for this would
seem to be to properly support x86_64; what is the news on this port?
I believe we suggest it as a SoC project for 2007, but haven't heard
of it recently.

RVM-266 is pretty much a matter of porting over patches.  Once I have
a build that works against pure SVN, this is not a problem.

Ian, how does Maxine 'clone the RVM'? I don't see a reference to
JikesRVM in that abstract.  Do you simply mean that it is a Java-based
VM?

Thanks,
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Steve Blackburn]

On 27/04/2008, at 2:26 AM, Ian Rogers wrote:
> I think we're about ready to start tagging for the 2.9.3 release. The
> current issues are [1]:

OK.  I expect to commit the new Immix garbage collector in the next 24  
hrs, and would like it in the release.  All the background commits are  
already done, so this is a simple addition.  I've been performance and  
sanity testing it and refining it over the past month.  Right now I'm  
just tidying up the code, so I can actually push it out the door at  
any moment modulo a bit of code ugliness.  The collector is  
significantly faster than the other full heap collectors and is also  
slightly faster on the bottom line compared to our production  
collector, so should give our bottom line a minor improvement (though  
I don't propose flipping production over to using Immix until after  
2.9.3).

> I have some structural changes I'd like to fast track for the 2.9.4
> release to improve the modularity of the object model.

OK.  Let's discuss the proposed changes before diving in with  
changes.  Both Dave and I have historically done a fair bit of work in  
that area (Dave in his previous work with various object models, and  
me with the Moxie work, where we successfully built a pluggable object  
model abstraction).

Moreover, the engineering of that particular aspect of the VM affects  
lots of people, so it is particularly important that we work together  
to get it right.

Thanks,

--Steve

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Andrew John Hughes wrote:

> Unfortunately, postponing some form of fix for RVM-456 means I can't
> actually go out and fix RVM-266... On the positive side, I think I
> have a patch.  If someone with a proprietary old-style javah can test
> this and confirm it works for them too, I'll commit it.  Note that I
> still find the issue odd as I was using OpenJDK to build before (which
> should be the same or newer than OpenJDK6) without seeing these
> issues, but that this actually highlights an implicit dependency we
> had on the naming of the header files which I think is broken in
> itself.
>  

Ok, I've put a variant of the fix in to solve issue RVM-456. This keeps
the status quo but works around the naming convention bug in OpenJDK 6.
Do you have an ETA on RVM-266? I believe you've already done the
complicated leg work so it should be reasonable to get it in prior to 2.9.3?

> I don't think RVM-432 is a blocker, given it seems to be a feature
> enhancement (graphical support for x86_64) and this wasn't supported
> in the previous release.  For me, the longer term fix for this would
> seem to be to properly support x86_64; what is the news on this port?
> I believe we suggest it as a SoC project for 2007, but haven't heard
> of it recently.
>  

So I have a student working on a new baseline compiler, this is because
our current one differs greatly between the PPC and x86 and is
sub-optimal on both. I want a framework that is closer to the old quick
compiler but not PPC specific. I hope to get this work into a branch in
the next few weeks/months. The assembler and opt compiler have already
had some work done to support x86_64 and this should be brought across.

I think the real issue with RVM-432 is that we could be using linux32 as
a wrapper to build GNU Classpath and this may better enable GNU
Classpath configure options to work, like GTk peers, when compiling for
32bit on a 64bit architecture. I don't think this will get done for
2.9.3 so I've rescheduled the issue for 2.9.4.

Regards,
Ian


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Steve Blackburn wrote:

> On 27/04/2008, at 2:26 AM, Ian Rogers wrote:
>  
>> I think we're about ready to start tagging for the 2.9.3 release. The
>> current issues are [1]:
>>    
>
> OK.  I expect to commit the new Immix garbage collector in the next 24  
> hrs, and would like it in the release.  All the background commits are  
> already done, so this is a simple addition.  I've been performance and  
> sanity testing it and refining it over the past month.  Right now I'm  
> just tidying up the code, so I can actually push it out the door at  
> any moment modulo a bit of code ugliness.  The collector is  
> significantly faster than the other full heap collectors and is also  
> slightly faster on the bottom line compared to our production  
> collector, so should give our bottom line a minor improvement (though  
> I don't propose flipping production over to using Immix until after  
> 2.9.3).
>  

Great, it's not showing as a 2.9.3 issue so I'm guessing all the patches
are now already in the code base.

>> I have some structural changes I'd like to fast track for the 2.9.4
>> release to improve the modularity of the object model.
>>    
>
> OK.  Let's discuss the proposed changes before diving in with  
> changes.  Both Dave and I have historically done a fair bit of work in  
> that area (Dave in his previous work with various object models, and  
> me with the Moxie work, where we successfully built a pluggable object  
> model abstraction).
>
> Moreover, the engineering of that particular aspect of the VM affects  
> lots of people, so it is particularly important that we work together  
> to get it right.
>  

Agreed, I have branch for the bidirectional object model where I have
been working on this code. Currently it supports pluggable configuration
of the locking model (thick or thin locks), hashing model but the
interface with GC is still crude. My plan is to extend the cleaned up
model to bidirectional support. I also want a object table model, that
adds an indirection per object access. This has a number of research
uses such as hardware supported GC, dynamically resizing objects becomes
easier, etc. Anyway, I'll move the code into the branch, discuss it and
then start to move it across to 2.9.4.

Regards,
Ian
--
Third International Workshop on Implementation, Compilation,
Optimization of Object-Oriented Languages, Programs and Systems
(ICOOOLPS 2008)
July 7, Paphos (Cyprus) http://icoolps.loria.fr

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Andrew John Hughes wrote:

> On 27/04/2008, Ian Rogers <rogers.email@...> wrote:
>  
>>
>> Ok, I've put a variant of the fix in to solve issue RVM-456. This keeps
>>  the status quo but works around the naming convention bug in OpenJDK 6.
>>  Do you have an ETA on RVM-266? I believe you've already done the
>>  complicated leg work so it should be reasonable to get it in prior to 2.9.3?
>>
>>    
>
> Later today; how's that?
>  

Fan-dabby-dozy!

>> So I have a student working on a new baseline compiler, this is because
>>  our current one differs greatly between the PPC and x86 and is
>>  sub-optimal on both. I want a framework that is closer to the old quick
>>  compiler but not PPC specific. I hope to get this work into a branch in
>>  the next few weeks/months. The assembler and opt compiler have already
>>  had some work done to support x86_64 and this should be brought across.
>>
>>  I think the real issue with RVM-432 is that we could be using linux32 as
>>  a wrapper to build GNU Classpath and this may better enable GNU
>>  Classpath configure options to work, like GTk peers, when compiling for
>>  32bit on a 64bit architecture. I don't think this will get done for
>>  2.9.3 so I've rescheduled the issue for 2.9.4.
>>
>>    
>
> Agreed, although my feeling is if this takes a lot of effort, the same
> effort would be better applied to a true x86_64 port.
>  

I agree, so I'm not spending my time looking into it. This is also why
I'm not looking at extending the current baseline to support 64bits by
the stack slot doubling technique we use on PPC64. I'd rather we had a
proper solution and not spend time/energy on half-way houses.

Regards,
Ian
--
Third International Workshop on Implementation, Compilation,
Optimization of Object-Oriented Languages, Programs and Systems
(ICOOOLPS 2008)
Submissions/Notification/Conference: May 4th/May 19th/July 7th
Paphos (Cyprus) http://icoolps.loria.fr

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[gnu_andrew]

On 27/04/2008, Ian Rogers <rogers.email@...> wrote:

> Andrew John Hughes wrote:
>  > Unfortunately, postponing some form of fix for RVM-456 means I can't
>  > actually go out and fix RVM-266... On the positive side, I think I
>  > have a patch.  If someone with a proprietary old-style javah can test
>  > this and confirm it works for them too, I'll commit it.  Note that I
>  > still find the issue odd as I was using OpenJDK to build before (which
>  > should be the same or newer than OpenJDK6) without seeing these
>  > issues, but that this actually highlights an implicit dependency we
>  > had on the naming of the header files which I think is broken in
>  > itself.
>  >
>
>
> Ok, I've put a variant of the fix in to solve issue RVM-456. This keeps
>  the status quo but works around the naming convention bug in OpenJDK 6.
>  Do you have an ETA on RVM-266? I believe you've already done the
>  complicated leg work so it should be reasonable to get it in prior to 2.9.3?
>

Later today; how's that?

>
>  > I don't think RVM-432 is a blocker, given it seems to be a feature
>  > enhancement (graphical support for x86_64) and this wasn't supported
>  > in the previous release.  For me, the longer term fix for this would
>  > seem to be to properly support x86_64; what is the news on this port?
>  > I believe we suggest it as a SoC project for 2007, but haven't heard
>  > of it recently.
>  >
>
>
> So I have a student working on a new baseline compiler, this is because
>  our current one differs greatly between the PPC and x86 and is
>  sub-optimal on both. I want a framework that is closer to the old quick
>  compiler but not PPC specific. I hope to get this work into a branch in
>  the next few weeks/months. The assembler and opt compiler have already
>  had some work done to support x86_64 and this should be brought across.
>
>  I think the real issue with RVM-432 is that we could be using linux32 as
>  a wrapper to build GNU Classpath and this may better enable GNU
>  Classpath configure options to work, like GTk peers, when compiling for
>  32bit on a 64bit architecture. I don't think this will get done for
>  2.9.3 so I've rescheduled the issue for 2.9.4.
>

Agreed, although my feeling is if this takes a lot of effort, the same
effort would be better applied to a true x86_64 port.

>  Regards,
>
> Ian
>
>
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Jikesrvm-core mailing list
>  Jikesrvm-core@...
>  https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Steve Blackburn]

On 27/04/2008, at 7:35 PM, Ian Rogers wrote:
>> I don't propose flipping production over to using Immix until after
>> 2.9.3).
> Great, it's not showing as a 2.9.3 issue so I'm guessing all the  
> patches
> are now already in the code base.


Yes, I've committed an initial version which is adequate for 2.9.3.  
I've resolved the initial JIRA describing the addition and opened a  
bunch for the various cleanups I plan to do for the next release.  
I'll work on them as soon as I can, but they are not blockers for 2.9.3.

--Steve

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Thanks Andrew and Steve, there are now no outstanding issues for the
2.9.3 release so I propose we wait to get a number of stable
regression runs, fix any issues that arise, and tag the trunk as 2.9.3
next week. I looked at my sourceforge permissions and in the admin
summary it says, "You cannot perform file release operations on this
project." Steve and Mike should have permissions to put the files of
the release onto sourceforge, or to grant permission to me, whilst
Dave is on holiday.

Looking at the DaCapo performance comparison at:
http://jikesrvm.anu.edu.au/~dacapo/index.php?category=release
Jikes RVM 2.9.3 will have comparable DaCapo performance to at least
Sun's JDK 1.5, which is a measure of the work put into improving
performance since 2.9.2.

Regards,
Ian
--
Third International Workshop on Implementation, Compilation,
Optimization of Object-Oriented Languages, Programs and Systems
(ICOOOLPS 2008)
Submissions/Notification/Conference: May 4th/May 19th/July 7th
Paphos (Cyprus) http://icoolps.loria.fr

2008/4/27 Ian Rogers <rogers.email@...>:

> Andrew John Hughes wrote:
>
> >
> > On 27/04/2008, Ian Rogers <rogers.email@...> wrote:
> >
> >
> >
> > >
> > > Ok, I've put a variant of the fix in to solve issue RVM-456. This keeps
> > >  the status quo but works around the naming convention bug in OpenJDK 6.
> > >  Do you have an ETA on RVM-266? I believe you've already done the
> > >  complicated leg work so it should be reasonable to get it in prior to
> 2.9.3?
> > >
> > >
> > >
> >
> > Later today; how's that?
> >
> >
>
>  Fan-dabby-dozy!
>
>
>
> >
> > > So I have a student working on a new baseline compiler, this is because
> > >  our current one differs greatly between the PPC and x86 and is
> > >  sub-optimal on both. I want a framework that is closer to the old quick
> > >  compiler but not PPC specific. I hope to get this work into a branch in
> > >  the next few weeks/months. The assembler and opt compiler have already
> > >  had some work done to support x86_64 and this should be brought across.
> > >
> > >  I think the real issue with RVM-432 is that we could be using linux32
> as
> > >  a wrapper to build GNU Classpath and this may better enable GNU
> > >  Classpath configure options to work, like GTk peers, when compiling for
> > >  32bit on a 64bit architecture. I don't think this will get done for
> > >  2.9.3 so I've rescheduled the issue for 2.9.4.
> > >
> > >
> > >
> >
> > Agreed, although my feeling is if this takes a lot of effort, the same
> > effort would be better applied to a true x86_64 port.
> >
> >
>
>  I agree, so I'm not spending my time looking into it. This is also why I'm
> not looking at extending the current baseline to support 64bits by the stack
> slot doubling technique we use on PPC64. I'd rather we had a proper solution
> and not spend time/energy on half-way houses.
>
>  Regards,
>  Ian
>
>  --
>  Third International Workshop on Implementation, Compilation, Optimization
> of Object-Oriented Languages, Programs and Systems (ICOOOLPS 2008)
>  Submissions/Notification/Conference: May 4th/May 19th/July 7th
>
>
>  Paphos (Cyprus) http://icoolps.loria.fr
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Steve Blackburn]

On 27/04/2008, at 7:35 PM, Ian Rogers wrote:
> Agreed, I have branch for the bidirectional object model where I have
> been working on this code.

OK.  Did you see Robin's implementation?  Robin did a fairly decent  
evaluation of bidirectional headers and had a decent implementation  
(he was in touch with the McGill people).  I don't know the status of  
that or how it relates to yours, and Robin is unavailable...  Anyway,  
it would be good to avoid duplication of effort in that area if we can.

> Currently it supports pluggable configuration
> of the locking model (thick or thin locks), hashing model but the
> interface with GC is still crude.

OK.  One of the things us GC people were moving toward was a more  
simple model of just dedicating a single byte to GC, or complete  
additional words (as is currently the case for reference counting).  
The particular byte could be statically configurable. In other words,  
we'd never request certain bits from the VM; we'd just ask the VM to  
tell us which byte is ours and then we'd do whatever we needed to do  
with that byte.  Daniel may want to chime in here since he did quite a  
bit of thinking about this; although much of our thinking was now a  
year or so ago...

> My plan is to extend the cleaned up
> model to bidirectional support. I also want a object table model, that
> adds an indirection per object access.

Do you mean a handle table, or just indirection, as in a Brooks style  
indirection? Here a pointer is stored in the object header and is  
typically left to point to itself, but when the object is moved during  
concurrent copying collection, the pointer is made to point to the  
forwarded objects.  All object access are in principle indirected  
through the pointer in the header.

> This has a number of research
> uses such as hardware supported GC, dynamically resizing objects  
> becomes
> easier, etc. Anyway, I'll move the code into the branch, discuss it  
> and
> then start to move it across to 2.9.4.

OK.

--Steve

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[David P Grove]

I'm going to gather new compiler DNA since the current numbers are from
July 2007.  Other than that, I think we are more or less ready to go.
Assuming sanity results look good over the next 24 hours I'll plan on
packaging up a release tomorrow.  If anything comes up that you see as a
release blocker please open a JIRA against 2.9.3.

--dave


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core