[rvm-core] Code freeze

[Steve Blackburn]

I think it would be sensible to have a temporary freeze on the trunk,  
avoiding all non-essential commits.

1.  There are at least two critical, apparently unrelated performance  
bugs outstanding:

        http://jira.codehaus.org/browse/RVM-758
        http://jira.codehaus.org/browse/RVM-762

Performance is also significantly (but less dramatically) down on  
jbb2000, luindex, jess, db and javac.  Most of the dips appeared  
around 15301 or so, though it is odd since cattrack says that there  
were two perf regressions against 15301, one of which was fine, and  
the other of which was slow (things have remained slow since 15301).    
As a precaution, Daniel has rebooted habanero (the relevant test  
machine).   Anyway, this is disturbing and I'd really like to see it  
figured out before we move forward.

2. Meanwhile Daniel and Fil are trying to get native threads ready for  
prime time and are now very close, so minimizing churn on the head  
will help a great deal.

I would also like to flip production to GenImmix, but to monitor  
performance etc, it will help if things are stable, though this does  
not require a code freeze, and I'll wait till the performance issues  
are ironed out before I do that.

Cheers,

--Steve

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
> I think it would be sensible to have a temporary freeze on the trunk,
> avoiding all non-essential commits.

I think this is unnecessary, making changes relating to the thread
model currently would be a bad idea though.

> 1.  There are at least two critical, apparently unrelated performance
> bugs outstanding:
>
>        http://jira.codehaus.org/browse/RVM-758
>        http://jira.codehaus.org/browse/RVM-762
>
> Performance is also significantly (but less dramatically) down on
> jbb2000, luindex, jess, db and javac.  Most of the dips appeared
> around 15301 or so, though it is odd since cattrack says that there
> were two perf regressions against 15301, one of which was fine, and
> the other of which was slow (things have remained slow since 15301).
> As a precaution, Daniel has rebooted habanero (the relevant test
> machine).   Anyway, this is disturbing and I'd really like to see it
> figured out before we move forward.

I'm working on it. We have a situation where we are generating less
and tighter code, but performance has regressed. I profiled JBB'05 and
there are no real clues as to where the performance has gone. The
performance of jack is harder to monitor as it completes in a matter
of seconds. On the plus side performance is up for jython, lusearch
and to a lesser extent chart and javac.

We are getting noise on the AIX PPC tests where we appear to be
failing because another process has stolen a CPU.

> 2. Meanwhile Daniel and Fil are trying to get native threads ready for
> prime time and are now very close, so minimizing churn on the head
> will help a great deal.

I'm really worried again by the work on PNT (that I really want to see
in the head). Reading the JIRA traffic I see that we have a new method
called lockDangerously, when would someone want to lockDangerously
rather than just lock? I think the PNT code is quite a way from being
production ready. In doing some donkey work for the PPC implementation
the documentation wasn't sufficient for me to avoid bugs. Some methods
are lacking documentation and a lot of what should be self documenting
isn't. Recent commits on the PNT branch have backed out assertion
checks and had the infamous commit message of "stuff". This is really
not good enough.

I think a code freeze waiting for PNT is going to lead to a protracted
code freeze. I'm avoiding work on Windows and Harmony because it will
conflict with the PNT work. I don't think we should shut down
development of the rest of the code base as well.

> I would also like to flip production to GenImmix, but to monitor
> performance etc, it will help if things are stable, though this does
> not require a code freeze, and I'll wait till the performance issues
> are ironed out before I do that.

This may be a good use of the quarantine branch.

Regards,
Ian

> Cheers,
>
> --Steve
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/3 Ian Rogers <ian.rogers@...>:

> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>> I think it would be sensible to have a temporary freeze on the trunk,
>> avoiding all non-essential commits.
>
> I think this is unnecessary, making changes relating to the thread
> model currently would be a bad idea though.
>
>> 1.  There are at least two critical, apparently unrelated performance
>> bugs outstanding:
>>
>>        http://jira.codehaus.org/browse/RVM-758
>>        http://jira.codehaus.org/browse/RVM-762
>>
>> Performance is also significantly (but less dramatically) down on
>> jbb2000, luindex, jess, db and javac.  Most of the dips appeared
>> around 15301 or so, though it is odd since cattrack says that there
>> were two perf regressions against 15301, one of which was fine, and
>> the other of which was slow (things have remained slow since 15301).
>> As a precaution, Daniel has rebooted habanero (the relevant test
>> machine).   Anyway, this is disturbing and I'd really like to see it
>> figured out before we move forward.
>
> I'm working on it. We have a situation where we are generating less
> and tighter code, but performance has regressed. I profiled JBB'05 and
> there are no real clues as to where the performance has gone. The
> performance of jack is harder to monitor as it completes in a matter
> of seconds. On the plus side performance is up for jython, lusearch
> and to a lesser extent chart and javac.

On a server here I see the difference on JBB '05 (average of 3 quick
runs) as being 6120 (trunk) vs 6289 (r15295), so 2.76%. As the server
had some load this could be noise. The performance difference is far
different to the 40% slow down the habanero regression results are
currently showing up. Hopefully the reboot will clear this up.

Ian

> We are getting noise on the AIX PPC tests where we appear to be
> failing because another process has stolen a CPU.
>
>> 2. Meanwhile Daniel and Fil are trying to get native threads ready for
>> prime time and are now very close, so minimizing churn on the head
>> will help a great deal.
>
> I'm really worried again by the work on PNT (that I really want to see
> in the head). Reading the JIRA traffic I see that we have a new method
> called lockDangerously, when would someone want to lockDangerously
> rather than just lock? I think the PNT code is quite a way from being
> production ready. In doing some donkey work for the PPC implementation
> the documentation wasn't sufficient for me to avoid bugs. Some methods
> are lacking documentation and a lot of what should be self documenting
> isn't. Recent commits on the PNT branch have backed out assertion
> checks and had the infamous commit message of "stuff". This is really
> not good enough.
>
> I think a code freeze waiting for PNT is going to lead to a protracted
> code freeze. I'm avoiding work on Windows and Harmony because it will
> conflict with the PNT work. I don't think we should shut down
> development of the rest of the code base as well.
>
>> I would also like to flip production to GenImmix, but to monitor
>> performance etc, it will help if things are stable, though this does
>> not require a code freeze, and I'll wait till the performance issues
>> are ironed out before I do that.
>
> This may be a good use of the quarantine branch.
>
> Regards,
> Ian
>
>> Cheers,
>>
>> --Steve
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>> build responsive, highly engaging applications that combine the power of local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[David P Grove]

I'd like to see us stablize the trunk and get the native thread code merged in. I've been holding off on new feature work (namely the @Intrinsic implementation of Magic) to avoid making the final merge harder. I think everyone else should do likewise. If Fil and Daniel are close to achieving this merge, we should all pitch in to the extent we can and close this out.

Steve, on a potential switch to GenImmix, there is a blocking issue that it currently fails on some of the PPC platforms. See RVM-625.

--dave

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

Hi Dave,

2009/2/3 David P Grove <groved@...>:
> I'd like to see us stablize the trunk and get the native thread code merged
> in. I've been holding off on new feature work (namely the @Intrinsic
> implementation of Magic) to avoid making the final merge harder. I think
> everyone else should do likewise. If Fil and Daniel are close to achieving
> this merge, we should all pitch in to the extent we can and close this out.

I'd like to see the @Intrinsic code cleaned up. I'm not sure why we
now have a class file reader class, previously we'd always had a
static reader method in each of the class loader elements. Currently
we have static reader methods in all the elements except RVMClass, and
this has meant that some of the hoped for encapsulation on the grubby
internals of the packed constant pool format has been spread amongst
the RVMClass and the ClassFileReader. I'm sure all will become clear.

Wrt PNT, Fil and I merged the PNT branch with the trunk before xmas. I
did a more recent merge as there was a conflict between the Intel
64bit JNI compiler changes and Fil's Intel JNI compiler changes (a
nice thing from this is that Fil's changes went from being hand
crafted asm to Java code). Currently the PNT branch isn't working with
concurrent collectors, Daniel and Fil are fixing this. The PNT branch
is still broken on all PPC platforms, and I would like to see
improvements to the documentation, method names, etc. I'd prefer to
avoid making those changes to the trunk.

The last merge with the trunk I made was at r15258. As some of the
previous merges on the branch weren't performed cleanly there are
issues with bringing the branch up-to-date. This will also cause
difficulties with the merge with the trunk.

The recent changes on trunk (post r15258) have been the start of the
@Intrinsic work and my changes the baseline compiler barriers (which
are sufficiently off the path of PNT that I don't believe will cause
any merge problems).

Regards,
Ian

> Steve, on a potential switch to GenImmix, there is a blocking issue that it
> currently fails on some of the PPC platforms. See RVM-625.
>
> --dave
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[David P Grove]

Ian Rogers <ian.rogers@...> wrote on 02/03/2009 10:37:13 AM:
>
> Wrt PNT, Fil and I merged the PNT branch with the trunk before xmas. I
> did a more recent merge as there was a conflict between the Intel
> 64bit JNI compiler changes and Fil's Intel JNI compiler changes (a
> nice thing from this is that Fil's changes went from being hand
> crafted asm to Java code). Currently the PNT branch isn't working with
> concurrent collectors, Daniel and Fil are fixing this. The PNT branch
> is still broken on all PPC platforms, and I would like to see
> improvements to the documentation, method names, etc. I'd prefer to
> avoid making those changes to the trunk.

I disagree.  I would strongly prefer to see the branch merged in as soon as it is fully functional and deal with any cleanups in documentation in the trunk.  PNT represents a major increase of functionality for Jikes RVM on AIX (where our syscall interception strategy doesn't work) and I'm very interested in having this available.  I also think there may be a significant increase in our chances to get a 2009 SoC project if at least one of the 2008 projects had been successfully mainlined.

--dave

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/3 David P Grove <groved@...>:

> Ian Rogers <ian.rogers@...> wrote on 02/03/2009 10:37:13 AM:
>>
>> Wrt PNT, Fil and I merged the PNT branch with the trunk before xmas. I
>> did a more recent merge as there was a conflict between the Intel
>> 64bit JNI compiler changes and Fil's Intel JNI compiler changes (a
>> nice thing from this is that Fil's changes went from being hand
>> crafted asm to Java code). Currently the PNT branch isn't working with
>> concurrent collectors, Daniel and Fil are fixing this. The PNT branch
>> is still broken on all PPC platforms, and I would like to see
>> improvements to the documentation, method names, etc. I'd prefer to
>> avoid making those changes to the trunk.
>
> I disagree.  I would strongly prefer to see the branch merged in as soon as
> it is fully functional and deal with any cleanups in documentation in the
> trunk.  PNT represents a major increase of functionality for Jikes RVM on
> AIX (where our syscall interception strategy doesn't work) and I'm very
> interested in having this available.

I think this is fine. If you can handle the PPC merge...

Another alternative is on AIX to use Harmony and implement a Jikes RVM
Harmony thread DLL.

>  I also think there may be a
> significant increase in our chances to get a 2009 SoC project if at least
> one of the 2008 projects had been successfully mainlined.

I have BK's work merged with the trunk but it fails pre-commit tests
for reasons that should be fairly easy to clean up. This has been on
hold for the PNT work to get merged. Of course getting PNT merged has
been an ongoing saga. The work on the PNT branch is sporadic - it
doesn't seem fair to merge it into the trunk to force other people to
clean the code up.

Ian

> --dave
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/3 Ian Rogers <ian.rogers@...>:

> 2009/2/3 Ian Rogers <ian.rogers@...>:
>> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>>> I think it would be sensible to have a temporary freeze on the trunk,
>>> avoiding all non-essential commits.
>>
>> I think this is unnecessary, making changes relating to the thread
>> model currently would be a bad idea though.
>>
>>> 1.  There are at least two critical, apparently unrelated performance
>>> bugs outstanding:
>>>
>>>        http://jira.codehaus.org/browse/RVM-758
>>>        http://jira.codehaus.org/browse/RVM-762
>>>
>>> Performance is also significantly (but less dramatically) down on
>>> jbb2000, luindex, jess, db and javac.  Most of the dips appeared
>>> around 15301 or so, though it is odd since cattrack says that there
>>> were two perf regressions against 15301, one of which was fine, and
>>> the other of which was slow (things have remained slow since 15301).
>>> As a precaution, Daniel has rebooted habanero (the relevant test
>>> machine).   Anyway, this is disturbing and I'd really like to see it
>>> figured out before we move forward.
>>
>> I'm working on it. We have a situation where we are generating less
>> and tighter code, but performance has regressed. I profiled JBB'05 and
>> there are no real clues as to where the performance has gone. The
>> performance of jack is harder to monitor as it completes in a matter
>> of seconds. On the plus side performance is up for jython, lusearch
>> and to a lesser extent chart and javac.
>
> On a server here I see the difference on JBB '05 (average of 3 quick
> runs) as being 6120 (trunk) vs 6289 (r15295), so 2.76%. As the server
> had some load this could be noise. The performance difference is far
> different to the 40% slow down the habanero regression results are
> currently showing up. Hopefully the reboot will clear this up.
>
> Ian

http://jikesrvm.anu.edu.au/cattrack/results/habanero.anu.edu.au/perf/7605/performance_report
The reboot of habanero has cleared up the performance issue.

Ian

>> We are getting noise on the AIX PPC tests where we appear to be
>> failing because another process has stolen a CPU.
>>
>>> 2. Meanwhile Daniel and Fil are trying to get native threads ready for
>>> prime time and are now very close, so minimizing churn on the head
>>> will help a great deal.
>>
>> I'm really worried again by the work on PNT (that I really want to see
>> in the head). Reading the JIRA traffic I see that we have a new method
>> called lockDangerously, when would someone want to lockDangerously
>> rather than just lock? I think the PNT code is quite a way from being
>> production ready. In doing some donkey work for the PPC implementation
>> the documentation wasn't sufficient for me to avoid bugs. Some methods
>> are lacking documentation and a lot of what should be self documenting
>> isn't. Recent commits on the PNT branch have backed out assertion
>> checks and had the infamous commit message of "stuff". This is really
>> not good enough.
>>
>> I think a code freeze waiting for PNT is going to lead to a protracted
>> code freeze. I'm avoiding work on Windows and Harmony because it will
>> conflict with the PNT work. I don't think we should shut down
>> development of the rest of the code base as well.
>>
>>> I would also like to flip production to GenImmix, but to monitor
>>> performance etc, it will help if things are stable, though this does
>>> not require a code freeze, and I'll wait till the performance issues
>>> are ironed out before I do that.
>>
>> This may be a good use of the quarantine branch.
>>
>> Regards,
>> Ian
>>
>>> Cheers,
>>>
>>> --Steve
>>>
>>> ------------------------------------------------------------------------------
>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>> build responsive, highly engaging applications that combine the power of local
>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>> _______________________________________________
>>> Jikesrvm-core mailing list
>>> Jikesrvm-core@...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>
>>
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Steve Blackburn]

On 04/02/2009, at 2:50 AM, David P Grove wrote:

> improvements to the documentation, method names, etc. I'd prefer to
> avoid making those changes to the trunk.

I disagree.  I would strongly prefer to see the branch merged in as soon as it is fully functional and deal with any cleanups in documentation in the trunk.  PNT represents a major increase of functionality for Jikes RVM on AIX (where our syscall interception strategy doesn't work) and I'm very interested in having this available.  I also think there may be a significant increase in our chances to get a 2009 SoC project if at least one of the 2008 projects had been successfully mainlined.

I agree with Dave.

 We need to get native threads happening ASAP for a host of strategic reasons.

To make that happen, Tony has paid for Fil to make the journey to ANU and work intensively with Daniel.  Meanwhile Daniel has put his PhD write-up on ice for two weeks for the same reason.

Since Fil arrived, the progress has been dramatic.    After two days they had the native threads branch go from 219/2184 to 11/2184.  This is very close to the head in terms of stability (see most recent kumataka regression result).  Since then they've pushed on PPC and nailed a few more bugs  (see recent commit messages to see the progress they've made on PPC).  Daniel is kicking off another kumataka run now.  So we are now finally very close to having native threads production-ready.

--Steve

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/3 Steve Blackburn <Steve.Blackburn@...>:

>
> On 04/02/2009, at 2:50 AM, David P Grove wrote:
>
>> improvements to the documentation, method names, etc. I'd prefer to
>> avoid making those changes to the trunk.
>
> I disagree.  I would strongly prefer to see the branch merged in as soon as
> it is fully functional and deal with any cleanups in documentation in the
> trunk.  PNT represents a major increase of functionality for Jikes RVM on
> AIX (where our syscall interception strategy doesn't work) and I'm very
> interested in having this available.  I also think there may be a
> significant increase in our chances to get a 2009 SoC project if at least
> one of the 2008 projects had been successfully mainlined.
>
> I agree with Dave.
>  We need to get native threads happening ASAP for a host of strategic
> reasons.
> To make that happen, Tony has paid for Fil to make the journey to ANU and
> work intensively with Daniel.  Meanwhile Daniel has put his PhD write-up on
> ice for two weeks for the same reason.
> Since Fil arrived, the progress has been dramatic.    After two days they
> had the native threads branch go from 219/2184 to 11/2184.  This is very
> close to the head in terms of stability (see most recent kumataka regression
> result).  Since then they've pushed on PPC and nailed a few more bugs  (see
> recent commit messages to see the progress they've made on PPC).  Daniel is
> kicking off another kumataka run now.  So we are now finally very close to
> having native threads production-ready.
> --Steve

Firstly, this is great. It's unfortunate that expense and Daniel's
time has come into it. I'm sure Tony and Fil have told you about the
work merging up done in Kent.

My concern is less about that we'll have something that works and more
that we've regressed in a number of areas that I have spent time and
effort improving. In particular to make the threading model
intelligible. I think with a "quality review" the state of the code in
the PNT branch could be significantly improved. We can lose misleading
concepts like "nicely" and "dangerously" and get back to describing
methods for what they do. We can also decrease the visibility of
fields (good practice and better encapsulation).

Ian

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Steve Blackburn]

Hi Ian,

On 04/02/2009, at 7:32 PM, Ian Rogers wrote:
> My concern is less about that we'll have something that works and more
> that we've regressed in a number of areas that I have spent time and
> effort improving. In particular to make the threading model
> intelligible. I think with a "quality review" the state of the code in
> the PNT branch could be significantly improved.

I think everyone agrees that the more intelligible the code the  
better.  Renaming methods and abstractions that are confusingly named  
is a good idea.

> We can lose misleading
> concepts like "nicely" and "dangerously" and get back to describing
> methods for what they do. We can also decrease the visibility of
> fields (good practice and better encapsulation).

There's not much disagreement about this.   We discussed some of these  
specifically over lunch today.  Choosing the "right" name can be  
troublesome.   Having identified the right name, actually changing the  
code is trivial.  The semantics involved are similar to those  
described by the (un)interruptible / (un)preemptible annotations, so I  
think the plan was to re-name the methods along those lines.    
However, even those names a lot of people (me :-) don't find specially  
intuitive (but then again, I don't have better suggestions).

So I don't think you need be concerned.   Getting these things right  
is important and the more eyes that look over it, the better.

--Steve

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

Hi Steve,

2009/2/4 Steve Blackburn <Steve.Blackburn@...>:

> Hi Ian,
>
> On 04/02/2009, at 7:32 PM, Ian Rogers wrote:
>> My concern is less about that we'll have something that works and more
>> that we've regressed in a number of areas that I have spent time and
>> effort improving. In particular to make the threading model
>> intelligible. I think with a "quality review" the state of the code in
>> the PNT branch could be significantly improved.
>
> I think everyone agrees that the more intelligible the code the
> better.  Renaming methods and abstractions that are confusingly named
> is a good idea.
>
>> We can lose misleading
>> concepts like "nicely" and "dangerously" and get back to describing
>> methods for what they do. We can also decrease the visibility of
>> fields (good practice and better encapsulation).
>
> There's not much disagreement about this.   We discussed some of these
> specifically over lunch today.  Choosing the "right" name can be
> troublesome.   Having identified the right name, actually changing the
> code is trivial.  The semantics involved are similar to those
> described by the (un)interruptible / (un)preemptible annotations, so I
> think the plan was to re-name the methods along those lines.
> However, even those names a lot of people (me :-) don't find specially
> intuitive (but then again, I don't have better suggestions).
>
> So I don't think you need be concerned.   Getting these things right
> is important and the more eyes that look over it, the better.
>
> --Steve

Fantastic news, I'm very happy :-D

The uninterruptible and unpreemptible annotations are hard to
understand. Uninterruptible is a guarantee that code won't yield. That
is, if I call an uninterruptible method and it in any way loses
control to another thread then the code is wrong. Unpreemptible isn't
a guarantee but a guide to the compiler not to generate thread
yielding code. It would be valid for unpreemptible code to call
uninterruptible code, it would be invalid for uninterruptible code to
call unpreemptible code.

As we generate compiler errors to try to enforce these annotations
there are the NoWarn variants, that tell the compiler that the
programmer has a better idea than the compiler does and that actually
the code is uninterruptible or for unpreemptible that we mean to lose
control at a particular point (for example a contended lock).

In general unpreemptible is useful for threading, where scheduling is
being managed by the code anyway.

In general uninterruptible is useful for GC, as the GC is expecting
other threads or the mutator to get scheduled during GC.

I think the only part of the code base not adhering to this is MMTk,
org/jikesrvm/mm/mmtk/FinalizableProcessor.growTables being an example.
I believe I opened a JIRA for this as well, but couldn't find it with
a search :-/

Ian

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Filip Pizlo-2]

Ian,

So, as far as I can tell, your two issues are:

1) The "dangerously" and "nicely" methods.  These method names were  
chosen in a hurry with the intent to have them changed once things  
worked.  I have no strong feelings about what they should be called.  
But getting the code to work is more important than getting method  
names right.  If you have names for these that you like, tell us what  
they are ... all of us - most especially me - want to change the names  
of these methods and are happy to entertain whatever names make sense  
to everyone.

2) Field visibility and access to things like execStatus.  Have you  
looked at the latest code?  I made a bunch of changes to a) increase  
the amount of assertions, b) make it easier to assert properties about  
execStatus, and c) I've made the important thread state fields  
private.  Does this address your concerns?

-F



On Feb 4, 2009, at 7:32 PM, Ian Rogers wrote:

> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>>
>> On 04/02/2009, at 2:50 AM, David P Grove wrote:
>>
>>> improvements to the documentation, method names, etc. I'd prefer to
>>> avoid making those changes to the trunk.
>>
>> I disagree.  I would strongly prefer to see the branch merged in as  
>> soon as
>> it is fully functional and deal with any cleanups in documentation  
>> in the
>> trunk.  PNT represents a major increase of functionality for Jikes  
>> RVM on
>> AIX (where our syscall interception strategy doesn't work) and I'm  
>> very
>> interested in having this available.  I also think there may be a
>> significant increase in our chances to get a 2009 SoC project if at  
>> least
>> one of the 2008 projects had been successfully mainlined.
>>
>> I agree with Dave.
>> We need to get native threads happening ASAP for a host of strategic
>> reasons.
>> To make that happen, Tony has paid for Fil to make the journey to  
>> ANU and
>> work intensively with Daniel.  Meanwhile Daniel has put his PhD  
>> write-up on
>> ice for two weeks for the same reason.
>> Since Fil arrived, the progress has been dramatic.    After two  
>> days they
>> had the native threads branch go from 219/2184 to 11/2184.  This is  
>> very
>> close to the head in terms of stability (see most recent kumataka  
>> regression
>> result).  Since then they've pushed on PPC and nailed a few more  
>> bugs  (see
>> recent commit messages to see the progress they've made on PPC).  
>> Daniel is
>> kicking off another kumataka run now.  So we are now finally very  
>> close to
>> having native threads production-ready.
>> --Steve
>
> Firstly, this is great. It's unfortunate that expense and Daniel's
> time has come into it. I'm sure Tony and Fil have told you about the
> work merging up done in Kent.
>
> My concern is less about that we'll have something that works and more
> that we've regressed in a number of areas that I have spent time and
> effort improving. In particular to make the threading model
> intelligible. I think with a "quality review" the state of the code in
> the PNT branch could be significantly improved. We can lose misleading
> concepts like "nicely" and "dangerously" and get back to describing
> methods for what they do. We can also decrease the visibility of
> fields (good practice and better encapsulation).
>
> Ian
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with  
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills  
> and code to
> build responsive, highly engaging applications that combine the  
> power of local
> resources and data with the reach of the web. Download the Adobe AIR  
> SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/4 Filip Pizlo <pizlo@...>:

> Ian,
>
> So, as far as I can tell, your two issues are:
>
> 1) The "dangerously" and "nicely" methods.  These method names were
> chosen in a hurry with the intent to have them changed once things
> worked.  I have no strong feelings about what they should be called.
> But getting the code to work is more important than getting method
> names right.  If you have names for these that you like, tell us what
> they are ... all of us - most especially me - want to change the names
> of these methods and are happy to entertain whatever names make sense
> to everyone.
>
> 2) Field visibility and access to things like execStatus.  Have you
> looked at the latest code?  I made a bunch of changes to a) increase
> the amount of assertions, b) make it easier to assert properties about
> execStatus, and c) I've made the important thread state fields
> private.  Does this address your concerns?
>
> -F

Sorry Fil, I'd missed parts of the commits that I like a lot,
assertAcceptableStates rocks!

I can't build the branch currently, I see:

    [mkdir] Created dir:
/home/antigua/IanR/workspace/jikesrvm-pnt/target/prototype_x86_64-linux/classes
    [javac] Compiling 85 source files to
/home/antigua/IanR/workspace/jikesrvm-pnt/target/prototype_x86_64-linux/classes
    [javac] /home/antigua/IanR/workspace/jikesrvm-pnt/libraryInterface/Common/src/java/lang/Class.java:275:
cannot find symbol
    [javac] symbol  : method isUnboxedType()
    [javac] location: class org.jikesrvm.classloader.RVMType
    [javac]     if (type.isPrimitiveType() || type.isUnboxedType()) {
    [javac]                                       ^
    [javac] /home/antigua/IanR/workspace/jikesrvm-pnt/libraryInterface/Common/src/java/lang/Class.java:295:
cannot find symbol
    [javac] symbol  : method isUnboxedType()
    [javac] location: class org.jikesrvm.classloader.RVMType
    [javac]      } else if (type.isPrimitiveType() || type.isUnboxedType() ||
    [javac]                                               ^
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.
    [javac] 2 errors

Looking through the code via sourceforge I see the following low
hanging fruit in RVMThread:

1) javadoc for a lot of methods is missing
2) native (enterNative, etc.) should be renamed
3) there seems to be an inconsistency in the naming of
IN_JAVA_TO_BLOCK and BLOCKED_IN_JNI.. could BLOCKED_IN_JNI be
IN_JNI_TO_BLOCK?
4) comments and assertions on the block adapter code - I think the
design is good, it's just a little hard to follow all of the code
through and I some assertions wouldn't go amiss for when we think
things can suspend, etc.
5) threadBySlot, monitorBySlot, aboutToTerminate, freeSlots, threads,
handshakeThreads, debugThreads - each of these arrays has MAX_THREADS
entries (currently 16384) I wonder if we could save some space with
maps and the like
6) acctLock is used to guard access to things like numThreads, it'd be
good to capture this in the javadoc of numThreads...

In the other classes:

HeavyCondLock - the nicely methods need a better name
Latch - the dangerously methods need a better name
NoYieldPointsCondLock - what's the meaning of "this method is strange" ?
SpinLock - comments talk about processors, should these be threads now?
Synchronization - it'd be nice to use this utility class rather and
factor Magic calls out of the other classes (I'd already done some of
this work in getting the PPC version starting to work but things like
SpinLock just use Magic)

Regards,
Ian

> On Feb 4, 2009, at 7:32 PM, Ian Rogers wrote:
>
>> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>>>
>>> On 04/02/2009, at 2:50 AM, David P Grove wrote:
>>>
>>>> improvements to the documentation, method names, etc. I'd prefer to
>>>> avoid making those changes to the trunk.
>>>
>>> I disagree.  I would strongly prefer to see the branch merged in as
>>> soon as
>>> it is fully functional and deal with any cleanups in documentation
>>> in the
>>> trunk.  PNT represents a major increase of functionality for Jikes
>>> RVM on
>>> AIX (where our syscall interception strategy doesn't work) and I'm
>>> very
>>> interested in having this available.  I also think there may be a
>>> significant increase in our chances to get a 2009 SoC project if at
>>> least
>>> one of the 2008 projects had been successfully mainlined.
>>>
>>> I agree with Dave.
>>> We need to get native threads happening ASAP for a host of strategic
>>> reasons.
>>> To make that happen, Tony has paid for Fil to make the journey to
>>> ANU and
>>> work intensively with Daniel.  Meanwhile Daniel has put his PhD
>>> write-up on
>>> ice for two weeks for the same reason.
>>> Since Fil arrived, the progress has been dramatic.    After two
>>> days they
>>> had the native threads branch go from 219/2184 to 11/2184.  This is
>>> very
>>> close to the head in terms of stability (see most recent kumataka
>>> regression
>>> result).  Since then they've pushed on PPC and nailed a few more
>>> bugs  (see
>>> recent commit messages to see the progress they've made on PPC).
>>> Daniel is
>>> kicking off another kumataka run now.  So we are now finally very
>>> close to
>>> having native threads production-ready.
>>> --Steve
>>
>> Firstly, this is great. It's unfortunate that expense and Daniel's
>> time has come into it. I'm sure Tony and Fil have told you about the
>> work merging up done in Kent.
>>
>> My concern is less about that we'll have something that works and more
>> that we've regressed in a number of areas that I have spent time and
>> effort improving. In particular to make the threading model
>> intelligible. I think with a "quality review" the state of the code in
>> the PNT branch could be significantly improved. We can lose misleading
>> concepts like "nicely" and "dangerously" and get back to describing
>> methods for what they do. We can also decrease the visibility of
>> fields (good practice and better encapsulation).
>>
>> Ian
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills
>> and code to
>> build responsive, highly engaging applications that combine the
>> power of local
>> resources and data with the reach of the web. Download the Adobe AIR
>> SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Filip Pizlo-2]

> I can't build the branch currently, I see:

Doesn't surprise me; Daniel and I are in the middle of merging.

> 1) javadoc for a lot of methods is missing

Will do a after the merge.  See RVM-763.

> 2) native (enterNative, etc.) should be renamed

Of course.  Will do after the merge.  See RVM-764.

> 3) there seems to be an inconsistency in the naming of
> IN_JAVA_TO_BLOCK and BLOCKED_IN_JNI.. could BLOCKED_IN_JNI be
> IN_JNI_TO_BLOCK?

Actually, IN_JAVA_TO_BLOCK vs BLOCKED_IN_JNI makes sense, depending on  
how you look at it.  While we're still running as IN_JAVA_TO_BLOCK,  
anyone waiting for the thread to block would still have to continue  
waiting - from their perspective, the thread is not "blocked" yet.  
See the block() method for example.  But when the method is  
BLOCKED_IN_JNI, the thread really is considered blocked.

The current terminology - and you're welcome to come up with something  
better - is:

1) not blocked: the thread is running and there is no request to block
2) to block: a block request is pending
3) blocked: the thread is "effectively" blocked in the sense that it's  
not running "with VM access" (using J9 terminology).  you could also  
say that the thread is "gc safe".
4) blocking: the thread is actually stopped, waiting for someone to  
wake it up.  this is when the thread is in checkBlock().  This implies  
that the thread is blocked - so (4) subsumes (3).

When the thread is running Java code, and a block request arrives, it  
goes from (1) to (2) as soon as the block request is made, and then  
from (2) to (4) as soon as it blocks.

When the thread is running JNI code, or is running what I currently  
call "native" code, and a block request arrives, it goes from (1) to  
(3) immediately after the block request is made, and then from (3) to  
(4) when it tries to go back to running Java code.  If the block  
request had by then been cleared, then it may be in (4) for a very  
short time - only to realize that it shouldn't have blocked.

> 4) comments and assertions on the block adapter code - I think the
> design is good, it's just a little hard to follow all of the code
> through and I some assertions wouldn't go amiss for when we think
> things can suspend, etc.

Good point.  Will do after the merge.  See RVM-765.

>
> 5) threadBySlot, monitorBySlot, aboutToTerminate, freeSlots, threads,
> handshakeThreads, debugThreads - each of these arrays has MAX_THREADS
> entries (currently 16384) I wonder if we could save some space with
> maps and the like

MAX_THREADS is a small number due to thin locking.  What sort of maps  
would you recommend?  These are all accessed from code that is running  
concurrently to GC, or during GC... so the data structures should be  
as simple as possible.

>
> 6) acctLock is used to guard access to things like numThreads, it'd be
> good to capture this in the javadoc of numThreads...

Good point.  There are a lot of subtle things that acctLock is used  
for and this isn't well documented.  Will fix the docs after the  
merge.  See RVM-766.

>
>
> In the other classes:
>
> HeavyCondLock - the nicely methods need a better name
> Latch - the dangerously methods need a better name

Yes.  Will do after the merge.  See RVM-767.

>
> NoYieldPointsCondLock - what's the meaning of "this method is  
> strange" ?

That whole class needs better documentation.  Will fix after the  
merge.  See RVM-767.

>
> SpinLock - comments talk about processors, should these be threads  
> now?

Yes.  See RVM-767.

>
> Synchronization - it'd be nice to use this utility class rather and
> factor Magic calls out of the other classes (I'd already done some of
> this work in getting the PPC version starting to work but things like
> SpinLock just use Magic)

This seems unrelated to PNT...  Is there already a JIRA for this?

-F

>
>
> Regards,
> Ian
>
>> On Feb 4, 2009, at 7:32 PM, Ian Rogers wrote:
>>
>>> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>>>>
>>>> On 04/02/2009, at 2:50 AM, David P Grove wrote:
>>>>
>>>>> improvements to the documentation, method names, etc. I'd prefer  
>>>>> to
>>>>> avoid making those changes to the trunk.
>>>>
>>>> I disagree.  I would strongly prefer to see the branch merged in as
>>>> soon as
>>>> it is fully functional and deal with any cleanups in documentation
>>>> in the
>>>> trunk.  PNT represents a major increase of functionality for Jikes
>>>> RVM on
>>>> AIX (where our syscall interception strategy doesn't work) and I'm
>>>> very
>>>> interested in having this available.  I also think there may be a
>>>> significant increase in our chances to get a 2009 SoC project if at
>>>> least
>>>> one of the 2008 projects had been successfully mainlined.
>>>>
>>>> I agree with Dave.
>>>> We need to get native threads happening ASAP for a host of  
>>>> strategic
>>>> reasons.
>>>> To make that happen, Tony has paid for Fil to make the journey to
>>>> ANU and
>>>> work intensively with Daniel.  Meanwhile Daniel has put his PhD
>>>> write-up on
>>>> ice for two weeks for the same reason.
>>>> Since Fil arrived, the progress has been dramatic.    After two
>>>> days they
>>>> had the native threads branch go from 219/2184 to 11/2184.  This is
>>>> very
>>>> close to the head in terms of stability (see most recent kumataka
>>>> regression
>>>> result).  Since then they've pushed on PPC and nailed a few more
>>>> bugs  (see
>>>> recent commit messages to see the progress they've made on PPC).
>>>> Daniel is
>>>> kicking off another kumataka run now.  So we are now finally very
>>>> close to
>>>> having native threads production-ready.
>>>> --Steve
>>>
>>> Firstly, this is great. It's unfortunate that expense and Daniel's
>>> time has come into it. I'm sure Tony and Fil have told you about the
>>> work merging up done in Kent.
>>>
>>> My concern is less about that we'll have something that works and  
>>> more
>>> that we've regressed in a number of areas that I have spent time and
>>> effort improving. In particular to make the threading model
>>> intelligible. I think with a "quality review" the state of the  
>>> code in
>>> the PNT branch could be significantly improved. We can lose  
>>> misleading
>>> concepts like "nicely" and "dangerously" and get back to describing
>>> methods for what they do. We can also decrease the visibility of
>>> fields (good practice and better encapsulation).
>>>
>>> Ian
>>>
>>> ------------------------------------------------------------------------------
>>> Create and Deploy Rich Internet Apps outside the browser with
>>> Adobe(R)AIR(TM)
>>> software. With Adobe AIR, Ajax developers can use existing skills
>>> and code to
>>> build responsive, highly engaging applications that combine the
>>> power of local
>>> resources and data with the reach of the web. Download the Adobe AIR
>>> SDK and
>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>> _______________________________________________
>>> Jikesrvm-core mailing list
>>> Jikesrvm-core@...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with  
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills  
>> and code to
>> build responsive, highly engaging applications that combine the  
>> power of local
>> resources and data with the reach of the web. Download the Adobe  
>> AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with  
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills  
> and code to
> build responsive, highly engaging applications that combine the  
> power of local
> resources and data with the reach of the web. Download the Adobe AIR  
> SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/4 Filip Pizlo <pizlo@...>:

>> I can't build the branch currently, I see:
>
> Doesn't surprise me; Daniel and I are in the middle of merging.
>
>> 1) javadoc for a lot of methods is missing
>
> Will do a after the merge.  See RVM-763.
>
>> 2) native (enterNative, etc.) should be renamed
>
> Of course.  Will do after the merge.  See RVM-764.
>
>> 3) there seems to be an inconsistency in the naming of
>> IN_JAVA_TO_BLOCK and BLOCKED_IN_JNI.. could BLOCKED_IN_JNI be
>> IN_JNI_TO_BLOCK?
>
> Actually, IN_JAVA_TO_BLOCK vs BLOCKED_IN_JNI makes sense, depending on
> how you look at it.  While we're still running as IN_JAVA_TO_BLOCK,
> anyone waiting for the thread to block would still have to continue
> waiting - from their perspective, the thread is not "blocked" yet.
> See the block() method for example.  But when the method is
> BLOCKED_IN_JNI, the thread really is considered blocked.
>
> The current terminology - and you're welcome to come up with something
> better - is:
>
> 1) not blocked: the thread is running and there is no request to block
> 2) to block: a block request is pending
> 3) blocked: the thread is "effectively" blocked in the sense that it's
> not running "with VM access" (using J9 terminology).  you could also
> say that the thread is "gc safe".
> 4) blocking: the thread is actually stopped, waiting for someone to
> wake it up.  this is when the thread is in checkBlock().  This implies
> that the thread is blocked - so (4) subsumes (3).
>
> When the thread is running Java code, and a block request arrives, it
> goes from (1) to (2) as soon as the block request is made, and then
> from (2) to (4) as soon as it blocks.
>
> When the thread is running JNI code, or is running what I currently
> call "native" code, and a block request arrives, it goes from (1) to
> (3) immediately after the block request is made, and then from (3) to
> (4) when it tries to go back to running Java code.  If the block
> request had by then been cleared, then it may be in (4) for a very
> short time - only to realize that it shouldn't have blocked.

Great, just doing a quick scan I wasn't sure if this was a deliberate
thing or cruft. Better javadoc would of course help.

>> 4) comments and assertions on the block adapter code - I think the
>> design is good, it's just a little hard to follow all of the code
>> through and I some assertions wouldn't go amiss for when we think
>> things can suspend, etc.
>
> Good point.  Will do after the merge.  See RVM-765.
>
>>
>> 5) threadBySlot, monitorBySlot, aboutToTerminate, freeSlots, threads,
>> handshakeThreads, debugThreads - each of these arrays has MAX_THREADS
>> entries (currently 16384) I wonder if we could save some space with
>> maps and the like
>
> MAX_THREADS is a small number due to thin locking.  What sort of maps
> would you recommend?  These are all accessed from code that is running
> concurrently to GC, or during GC... so the data structures should be
> as simple as possible.

I have a refactoring of the object model where the status word is
divvied up and threading gets what's left after hashing and GC. For
64bit code this could mean 1<<52 being the value for MAX_THREADS (we'd
of course fail to write such large arrays into the boot image). The
RVM has its own equivalents to hash maps which could be a starting
place for a different datastructure, check out org.jikesrvm.util. I
don't see this as a blocking issue.

>>
>> 6) acctLock is used to guard access to things like numThreads, it'd be
>> good to capture this in the javadoc of numThreads...
>
> Good point.  There are a lot of subtle things that acctLock is used
> for and this isn't well documented.  Will fix the docs after the
> merge.  See RVM-766.
>
>>
>>
>> In the other classes:
>>
>> HeavyCondLock - the nicely methods need a better name
>> Latch - the dangerously methods need a better name
>
> Yes.  Will do after the merge.  See RVM-767.
>
>>
>> NoYieldPointsCondLock - what's the meaning of "this method is
>> strange" ?
>
> That whole class needs better documentation.  Will fix after the
> merge.  See RVM-767.
>
>>
>> SpinLock - comments talk about processors, should these be threads
>> now?
>
> Yes.  See RVM-767.
>
>>
>> Synchronization - it'd be nice to use this utility class rather and
>> factor Magic calls out of the other classes (I'd already done some of
>> this work in getting the PPC version starting to work but things like
>> SpinLock just use Magic)
>
> This seems unrelated to PNT...  Is there already a JIRA for this?
>
> -F

Thanks for all the JIRAs. The Synchronization issue is that rather
than code against the RVM's magic API, the relevant tricks were placed
into Synchronization. In general all the RVM code used Synchronization
rather than the Magic APIs. I prefer this as it means for
architectures like ARM that don't always have CAS or ll/sc primitives,
the higher level operation of the Synchronization can be performed.

Ian

>>
>>
>> Regards,
>> Ian
>>
>>> On Feb 4, 2009, at 7:32 PM, Ian Rogers wrote:
>>>
>>>> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>>>>>
>>>>> On 04/02/2009, at 2:50 AM, David P Grove wrote:
>>>>>
>>>>>> improvements to the documentation, method names, etc. I'd prefer
>>>>>> to
>>>>>> avoid making those changes to the trunk.
>>>>>
>>>>> I disagree.  I would strongly prefer to see the branch merged in as
>>>>> soon as
>>>>> it is fully functional and deal with any cleanups in documentation
>>>>> in the
>>>>> trunk.  PNT represents a major increase of functionality for Jikes
>>>>> RVM on
>>>>> AIX (where our syscall interception strategy doesn't work) and I'm
>>>>> very
>>>>> interested in having this available.  I also think there may be a
>>>>> significant increase in our chances to get a 2009 SoC project if at
>>>>> least
>>>>> one of the 2008 projects had been successfully mainlined.
>>>>>
>>>>> I agree with Dave.
>>>>> We need to get native threads happening ASAP for a host of
>>>>> strategic
>>>>> reasons.
>>>>> To make that happen, Tony has paid for Fil to make the journey to
>>>>> ANU and
>>>>> work intensively with Daniel.  Meanwhile Daniel has put his PhD
>>>>> write-up on
>>>>> ice for two weeks for the same reason.
>>>>> Since Fil arrived, the progress has been dramatic.    After two
>>>>> days they
>>>>> had the native threads branch go from 219/2184 to 11/2184.  This is
>>>>> very
>>>>> close to the head in terms of stability (see most recent kumataka
>>>>> regression
>>>>> result).  Since then they've pushed on PPC and nailed a few more
>>>>> bugs  (see
>>>>> recent commit messages to see the progress they've made on PPC).
>>>>> Daniel is
>>>>> kicking off another kumataka run now.  So we are now finally very
>>>>> close to
>>>>> having native threads production-ready.
>>>>> --Steve
>>>>
>>>> Firstly, this is great. It's unfortunate that expense and Daniel's
>>>> time has come into it. I'm sure Tony and Fil have told you about the
>>>> work merging up done in Kent.
>>>>
>>>> My concern is less about that we'll have something that works and
>>>> more
>>>> that we've regressed in a number of areas that I have spent time and
>>>> effort improving. In particular to make the threading model
>>>> intelligible. I think with a "quality review" the state of the
>>>> code in
>>>> the PNT branch could be significantly improved. We can lose
>>>> misleading
>>>> concepts like "nicely" and "dangerously" and get back to describing
>>>> methods for what they do. We can also decrease the visibility of
>>>> fields (good practice and better encapsulation).
>>>>
>>>> Ian
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Create and Deploy Rich Internet Apps outside the browser with
>>>> Adobe(R)AIR(TM)
>>>> software. With Adobe AIR, Ajax developers can use existing skills
>>>> and code to
>>>> build responsive, highly engaging applications that combine the
>>>> power of local
>>>> resources and data with the reach of the web. Download the Adobe AIR
>>>> SDK and
>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>> _______________________________________________
>>>> Jikesrvm-core mailing list
>>>> Jikesrvm-core@...
>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Create and Deploy Rich Internet Apps outside the browser with
>>> Adobe(R)AIR(TM)
>>> software. With Adobe AIR, Ajax developers can use existing skills
>>> and code to
>>> build responsive, highly engaging applications that combine the
>>> power of local
>>> resources and data with the reach of the web. Download the Adobe
>>> AIR SDK and
>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>> _______________________________________________
>>> Jikesrvm-core mailing list
>>> Jikesrvm-core@...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills
>> and code to
>> build responsive, highly engaging applications that combine the
>> power of local
>> resources and data with the reach of the web. Download the Adobe AIR
>> SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Filip Pizlo-2]

>
> Thanks for all the JIRAs. The Synchronization issue is that rather
> than code against the RVM's magic API, the relevant tricks were placed
> into Synchronization. In general all the RVM code used Synchronization
> rather than the Magic APIs. I prefer this as it means for
> architectures like ARM that don't always have CAS or ll/sc primitives,
> the higher level operation of the Synchronization can be performed.

I don't necessarily mind using Synchronization, but I don't see why  
the Magic API cannot be encoded using what ARM has.  What were you  
thinking of doing on ARM?  Your only options are:

1) Use whatever atomic ops you've got.  I was under the impression  
that ARMs have LL/SC and/or "SWP", which is just an atomic  
unconditional exchange.  If you have LL/SC, then this matches  
perfectly to the prepareInt/attemptInt API.  For the versions that  
only have SWP, we're basically hosed - most of the operations we use  
in Synchronization can't be implemented with it.  So that leaves us  
with the next two options:

2) Disable scheduling.  This would be the best way of doing it -  
provided we have permissions - on ARMs that don't have LL/SC.  And  
there, it would make perfect sense to just have attemptInt disable  
scheduling.

3) Use locking.  If we want to do this, then the Magic and  
Synchronization APIs are equally crappy.

-F

>
>
> Ian
>
>>>
>>>
>>> Regards,
>>> Ian
>>>
>>>> On Feb 4, 2009, at 7:32 PM, Ian Rogers wrote:
>>>>
>>>>> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>>>>>>
>>>>>> On 04/02/2009, at 2:50 AM, David P Grove wrote:
>>>>>>
>>>>>>> improvements to the documentation, method names, etc. I'd prefer
>>>>>>> to
>>>>>>> avoid making those changes to the trunk.
>>>>>>
>>>>>> I disagree.  I would strongly prefer to see the branch merged  
>>>>>> in as
>>>>>> soon as
>>>>>> it is fully functional and deal with any cleanups in  
>>>>>> documentation
>>>>>> in the
>>>>>> trunk.  PNT represents a major increase of functionality for  
>>>>>> Jikes
>>>>>> RVM on
>>>>>> AIX (where our syscall interception strategy doesn't work) and  
>>>>>> I'm
>>>>>> very
>>>>>> interested in having this available.  I also think there may be a
>>>>>> significant increase in our chances to get a 2009 SoC project  
>>>>>> if at
>>>>>> least
>>>>>> one of the 2008 projects had been successfully mainlined.
>>>>>>
>>>>>> I agree with Dave.
>>>>>> We need to get native threads happening ASAP for a host of
>>>>>> strategic
>>>>>> reasons.
>>>>>> To make that happen, Tony has paid for Fil to make the journey to
>>>>>> ANU and
>>>>>> work intensively with Daniel.  Meanwhile Daniel has put his PhD
>>>>>> write-up on
>>>>>> ice for two weeks for the same reason.
>>>>>> Since Fil arrived, the progress has been dramatic.    After two
>>>>>> days they
>>>>>> had the native threads branch go from 219/2184 to 11/2184.  
>>>>>> This is
>>>>>> very
>>>>>> close to the head in terms of stability (see most recent kumataka
>>>>>> regression
>>>>>> result).  Since then they've pushed on PPC and nailed a few more
>>>>>> bugs  (see
>>>>>> recent commit messages to see the progress they've made on PPC).
>>>>>> Daniel is
>>>>>> kicking off another kumataka run now.  So we are now finally very
>>>>>> close to
>>>>>> having native threads production-ready.
>>>>>> --Steve
>>>>>
>>>>> Firstly, this is great. It's unfortunate that expense and Daniel's
>>>>> time has come into it. I'm sure Tony and Fil have told you about  
>>>>> the
>>>>> work merging up done in Kent.
>>>>>
>>>>> My concern is less about that we'll have something that works and
>>>>> more
>>>>> that we've regressed in a number of areas that I have spent time  
>>>>> and
>>>>> effort improving. In particular to make the threading model
>>>>> intelligible. I think with a "quality review" the state of the
>>>>> code in
>>>>> the PNT branch could be significantly improved. We can lose
>>>>> misleading
>>>>> concepts like "nicely" and "dangerously" and get back to  
>>>>> describing
>>>>> methods for what they do. We can also decrease the visibility of
>>>>> fields (good practice and better encapsulation).
>>>>>
>>>>> Ian
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Create and Deploy Rich Internet Apps outside the browser with
>>>>> Adobe(R)AIR(TM)
>>>>> software. With Adobe AIR, Ajax developers can use existing skills
>>>>> and code to
>>>>> build responsive, highly engaging applications that combine the
>>>>> power of local
>>>>> resources and data with the reach of the web. Download the Adobe  
>>>>> AIR
>>>>> SDK and
>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>> _______________________________________________
>>>>> Jikesrvm-core mailing list
>>>>> Jikesrvm-core@...
>>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Create and Deploy Rich Internet Apps outside the browser with
>>>> Adobe(R)AIR(TM)
>>>> software. With Adobe AIR, Ajax developers can use existing skills
>>>> and code to
>>>> build responsive, highly engaging applications that combine the
>>>> power of local
>>>> resources and data with the reach of the web. Download the Adobe
>>>> AIR SDK and
>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>> _______________________________________________
>>>> Jikesrvm-core mailing list
>>>> Jikesrvm-core@...
>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Create and Deploy Rich Internet Apps outside the browser with
>>> Adobe(R)AIR(TM)
>>> software. With Adobe AIR, Ajax developers can use existing skills
>>> and code to
>>> build responsive, highly engaging applications that combine the
>>> power of local
>>> resources and data with the reach of the web. Download the Adobe AIR
>>> SDK and
>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>> _______________________________________________
>>> Jikesrvm-core mailing list
>>> Jikesrvm-core@...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with  
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills  
>> and code to
>> build responsive, highly engaging applications that combine the  
>> power of local
>> resources and data with the reach of the web. Download the Adobe  
>> AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with  
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills  
> and code to
> build responsive, highly engaging applications that combine the  
> power of local
> resources and data with the reach of the web. Download the Adobe AIR  
> SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/2/5 Filip Pizlo <pizlo@...>:

>>
>> Thanks for all the JIRAs. The Synchronization issue is that rather
>> than code against the RVM's magic API, the relevant tricks were placed
>> into Synchronization. In general all the RVM code used Synchronization
>> rather than the Magic APIs. I prefer this as it means for
>> architectures like ARM that don't always have CAS or ll/sc primitives,
>> the higher level operation of the Synchronization can be performed.
>
> I don't necessarily mind using Synchronization, but I don't see why
> the Magic API cannot be encoded using what ARM has.  What were you
> thinking of doing on ARM?  Your only options are:
>
> 1) Use whatever atomic ops you've got.  I was under the impression
> that ARMs have LL/SC and/or "SWP", which is just an atomic
> unconditional exchange.  If you have LL/SC, then this matches
> perfectly to the prepareInt/attemptInt API.  For the versions that
> only have SWP, we're basically hosed - most of the operations we use
> in Synchronization can't be implemented with it.  So that leaves us
> with the next two options:
>
> 2) Disable scheduling.  This would be the best way of doing it -
> provided we have permissions - on ARMs that don't have LL/SC.  And
> there, it would make perfect sense to just have attemptInt disable
> scheduling.
>
> 3) Use locking.  If we want to do this, then the Magic and
> Synchronization APIs are equally crappy.
>
> -F

Our work on ARM has pretty much stopped, although it'd be nice to make
the code public for someone to bash it into shape. Our ARM machine
only has SWP, so we were using the special "we're looking" value to
implement the CAS. It means making sure there is a valid "we're
looking" encoding for fields that are CASed.

Anyway, the point wasn't so much about ARM but more about trying to
not hand write CAS code everywhere as it seems harder to maintain and
a step away from what we were doing. I fixed/changed a number of cases
of this and I think there's only one really big magic user in the PNT
scheduler.

Cheers,
Ian

>>
>>
>> Ian
>>
>>>>
>>>>
>>>> Regards,
>>>> Ian
>>>>
>>>>> On Feb 4, 2009, at 7:32 PM, Ian Rogers wrote:
>>>>>
>>>>>> 2009/2/3 Steve Blackburn <Steve.Blackburn@...>:
>>>>>>>
>>>>>>> On 04/02/2009, at 2:50 AM, David P Grove wrote:
>>>>>>>
>>>>>>>> improvements to the documentation, method names, etc. I'd prefer
>>>>>>>> to
>>>>>>>> avoid making those changes to the trunk.
>>>>>>>
>>>>>>> I disagree.  I would strongly prefer to see the branch merged
>>>>>>> in as
>>>>>>> soon as
>>>>>>> it is fully functional and deal with any cleanups in
>>>>>>> documentation
>>>>>>> in the
>>>>>>> trunk.  PNT represents a major increase of functionality for
>>>>>>> Jikes
>>>>>>> RVM on
>>>>>>> AIX (where our syscall interception strategy doesn't work) and
>>>>>>> I'm
>>>>>>> very
>>>>>>> interested in having this available.  I also think there may be a
>>>>>>> significant increase in our chances to get a 2009 SoC project
>>>>>>> if at
>>>>>>> least
>>>>>>> one of the 2008 projects had been successfully mainlined.
>>>>>>>
>>>>>>> I agree with Dave.
>>>>>>> We need to get native threads happening ASAP for a host of
>>>>>>> strategic
>>>>>>> reasons.
>>>>>>> To make that happen, Tony has paid for Fil to make the journey to
>>>>>>> ANU and
>>>>>>> work intensively with Daniel.  Meanwhile Daniel has put his PhD
>>>>>>> write-up on
>>>>>>> ice for two weeks for the same reason.
>>>>>>> Since Fil arrived, the progress has been dramatic.    After two
>>>>>>> days they
>>>>>>> had the native threads branch go from 219/2184 to 11/2184.
>>>>>>> This is
>>>>>>> very
>>>>>>> close to the head in terms of stability (see most recent kumataka
>>>>>>> regression
>>>>>>> result).  Since then they've pushed on PPC and nailed a few more
>>>>>>> bugs  (see
>>>>>>> recent commit messages to see the progress they've made on PPC).
>>>>>>> Daniel is
>>>>>>> kicking off another kumataka run now.  So we are now finally very
>>>>>>> close to
>>>>>>> having native threads production-ready.
>>>>>>> --Steve
>>>>>>
>>>>>> Firstly, this is great. It's unfortunate that expense and Daniel's
>>>>>> time has come into it. I'm sure Tony and Fil have told you about
>>>>>> the
>>>>>> work merging up done in Kent.
>>>>>>
>>>>>> My concern is less about that we'll have something that works and
>>>>>> more
>>>>>> that we've regressed in a number of areas that I have spent time
>>>>>> and
>>>>>> effort improving. In particular to make the threading model
>>>>>> intelligible. I think with a "quality review" the state of the
>>>>>> code in
>>>>>> the PNT branch could be significantly improved. We can lose
>>>>>> misleading
>>>>>> concepts like "nicely" and "dangerously" and get back to
>>>>>> describing
>>>>>> methods for what they do. We can also decrease the visibility of
>>>>>> fields (good practice and better encapsulation).
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Create and Deploy Rich Internet Apps outside the browser with
>>>>>> Adobe(R)AIR(TM)
>>>>>> software. With Adobe AIR, Ajax developers can use existing skills
>>>>>> and code to
>>>>>> build responsive, highly engaging applications that combine the
>>>>>> power of local
>>>>>> resources and data with the reach of the web. Download the Adobe
>>>>>> AIR
>>>>>> SDK and
>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>> _______________________________________________
>>>>>> Jikesrvm-core mailing list
>>>>>> Jikesrvm-core@...
>>>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Create and Deploy Rich Internet Apps outside the browser with
>>>>> Adobe(R)AIR(TM)
>>>>> software. With Adobe AIR, Ajax developers can use existing skills
>>>>> and code to
>>>>> build responsive, highly engaging applications that combine the
>>>>> power of local
>>>>> resources and data with the reach of the web. Download the Adobe
>>>>> AIR SDK and
>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>> _______________________________________________
>>>>> Jikesrvm-core mailing list
>>>>> Jikesrvm-core@...
>>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Create and Deploy Rich Internet Apps outside the browser with
>>>> Adobe(R)AIR(TM)
>>>> software. With Adobe AIR, Ajax developers can use existing skills
>>>> and code to
>>>> build responsive, highly engaging applications that combine the
>>>> power of local
>>>> resources and data with the reach of the web. Download the Adobe AIR
>>>> SDK and
>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>> _______________________________________________
>>>> Jikesrvm-core mailing list
>>>> Jikesrvm-core@...
>>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Create and Deploy Rich Internet Apps outside the browser with
>>> Adobe(R)AIR(TM)
>>> software. With Adobe AIR, Ajax developers can use existing skills
>>> and code to
>>> build responsive, highly engaging applications that combine the
>>> power of local
>>> resources and data with the reach of the web. Download the Adobe
>>> AIR SDK and
>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>> _______________________________________________
>>> Jikesrvm-core mailing list
>>> Jikesrvm-core@...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills
>> and code to
>> build responsive, highly engaging applications that combine the
>> power of local
>> resources and data with the reach of the web. Download the Adobe AIR
>> SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core