x10-core — List for X10 core design team

[X10-core] general implementation of map/reduce

[Josh M. <jos...@an...>]

Hi all,

with the separation of Rail from the simple x10.array and the 
fully-featured x10.regionarray classes, the map and reduce methods have 
been lost from Rail.  The map and reduce patterns (and to a lesser 
extent, scan) are so fundamental that I think this might be an 
appropriate time to define a standard approach for applying these 
patterns across X10 data structures.

The existing approach seems to be to just implement methods for 
map/reduce as needed on container classes like Array and DistArray. This 
may lead to undesirable repetition if it is extended to other types like 
Rail, ArrayList and other Collections.  Would it be appropriate to 
create a new interface Indexable that defines the indices() method and 
get and set operators?  This could be used to implement a general map 
operation as follows:

     public class x10.lang.Map {
         public @Inline static def map[T](op:(T)=>T, a:Indexable[T]) {
             finish for (p in a.indices()) async {
                 a(p) = op(a(p));
             }
         }
     }

A related question: should map/reduce be parallel or sequential by 
default?  The current implementations on the simple array classes are 
all sequential, but there are TODO comments on each suggesting they 
should be parallel.  The new work stealing implementation should 
substantially reduce the overhead of a parallel loop, which may swing 
the balance in favour of parallel map/reduce.

There are obviously multiple different ways of dividing map/reduce for 
parallel execution; it seems to me that the best general-purpose 
implementation would be recursive bisection, possibly with some minimum 
grain size; but other implementations may work better for particular 
problems.

Do you think it is possible to come up with a standard approach in time 
for version 2.4?

Cheers,

Josh

-- 
------------------------------------------
Josh Milthorpe

Postdoctoral Fellow, Research School of Computer Science
Australian National University, Building 108
Canberra, ACT 0200
Australia
Phone:  + 61 (0)2 61254478
Mobile: + 61 (0)407 940743
E-mail: jos...@an...
Web:    http://cs.anu.edu.au/~Josh.Milthorpe/

[X10-core] rippling conversions from int to long in X10 2.4

[David P G. <gr...@us...>]

For X10 2.4, we've made the jump to long-based indexing for Rail, Point,
Region, Array, DistArray, etc. This enables X10 2.4 to naturally support
very large array-based data structures (both single place and distributed).

A natural corollary of that is that x10.util.ArrayList should probably also
be upgraded to long-based indexing (since one is supposed to think of
ArrayList as a "collectionized" GrowableRail, and Rail/GrowableRail are
indexed by longs).

In itself, that change makes sense, but it then pushes into the rest of the
x10.util collection APIs.  In particular, the indexing methods of ArrayList
are implementations of the List interface.  Furthermore, the size method of
ArrayList implements the size method of Container.   Should we follow
through the change to the logical conclusion and make all of the x10.util
collections 64-bit sized?

One the one hand it seems like the most consistent thing to do.  On the
other hand, it cause more API incompatibilities with X10 2.3.x and isn't
quite as obvious that having the size of Maps and other collections be 64
bit is quite as useful as it is for array-like data structures.

Any thoughts?   I think I'd lean to making everything 64-bit in the name of
consistency, but I don't think we absolutely have to.

thanks,

--dave

[X10-core] new svn location for x10 project: https://svn.code.sf.net/p/x10/code

[David P G. <gr...@us...>]

As part of the upgrade of the sourceforge project, there is a new root
location for the svn repository.

If you have an existing checkout that you want to switch, the easiest way
to do it is on the command line with
	svn switch --relocate OLD_ROOT NEW_ROOT

If your username is not the same as your userid, then also include
--username to avoid having to specify the username the first time you
commit after the switch.

For example,

svn switch --username dgrove-oss --relocate
https://x10.svn.sf.net/svnroot/x10 https://svn.code.sf.net/p/x10/code


I'll be working on switching over the regression machines, scripts, web
pages, etc. this weekend.  However, the migration is complete so it is fine
to go ahead, switch to the new repository location, and start committing
code.

--dave

[X10-core] Array related changes in progress in svn head

[David P G. <gr...@us...>]

We're starting the next phase of the Array related class library changes
this week.
	(0) we changed the backing storage for Array and DistArray from
IndexedMemoryChunk to Rail (done earlier today).
	(1) we're going to stop auto-importing the x10.array package
	(2) the packaged x10.array will be renamed to x10.regionarray
	(3) stabilize all test cases
	(4) start work on new x10.simplearray classes.

So, expect a number of Array related changes this week.  Probably best to
not track the svn head unless you are actively working on either these
changes or other Rail related work.

--dave

Re: [X10-core] sockets backend serializes places in parallel 'at async'

[Josh M. <jos...@an...>]

Hi Olivier,

thanks for your suggestions.

For our own problematic code, we will probably either split the loop to 
spread and then compute on data as you suggest, or divide the long 
computation into smaller subtasks, thereby allowing communication to 
progress (as well as exploiting multiple threads where available).

The idea of automatically injecting yield points into activity bodies is 
an interesting one.  At the moment a call to Runtime.x10rtProbe() is 
relatively expensive, so I expect it would not benefit most codes to 
have it called more frequently. However, perhaps the cost can be 
reduced.  For example, it may not be necessary to poll the network if a 
probe has been called very recently.  Also, is it necessary to always 
progress sending and receiving at the same time?  (Every probe checks 
for pending receives, and then sends - is this send/recv symmetry 
expected to match a symmetry in the application, so that data won't be 
sent faster than they can be received at each place?)

Cheers,

Josh

On 11/12/12 08:31, Olivier Tardieu wrote:
>
> Josh,
>
> This is indeed a subtle point.
>
> The X10 runtime is a cooperative one. So today if every thread in a 
> place is running a long sequential computation, there is no 
> opportunity for the runtime to process incoming or outgoing network 
> messages.
> Moreover long message sends cannot typically be sent in full in one 
> step (details depend on transport).
> So we have two choices here: either block until a long send is 
> complete or stage a long send in multiple chunks.
> I believe we support both options (at least for PAMI and sockets).
> For sockets, the behavior is controlled with env var X10_NOWRITEBUFFER.
> For PAMI, it is different of course... X10RT_PAMI_BLOCKING_SEND.
>
> The default is not to block (I suspect MPI blocks always but I have 
> not checked).
> The rationale for this default is that it typically gives you more 
> communication computation overlap "for free."
> The computation can resume even if the send is still in progress.
> The drawback is what you have observed. The communication is 
> automatically done in multiple steps but not the computation.
> With long computations *and* long sends, we do not get a good 
> interleaving of chunks of computation and communication for free.
> We end up serializing computation at the sender and receiver(s) places.
>
> The alternative avoids this problem by neither splitting the 
> computation nor the communication so the ordering is closer to the 
> programmer's intuition.
>
> But there is a better fix (still assuming a purely cooperative runtime).
> By periodically calling Runtime.x10rtProbe() in the body of the long 
> computation, you ensure that transport gets the opportunity to send 
> more chunks of the long messages.
>
> We have thought about using the compiler to inject these probes 
> automatically (yield points) but have not decided to go implement this 
> feature yet.
> We could also abandon our cooperative paradigm and permit the runtime 
> to preempt user threads or have threads of its own to handle such 
> asynchronous services.
> Again, we have not committed to spend the time implementing such 
> features yet.
>
> Typically one can also restructure the problematic loop into two 
> separate pieces: the first loop spreading the data, the second 
> computing on it, with a blocking finish around the first loop,
> hence locally disabling the problematic overlap of communication and 
> computation.
>
> Olivier
>
>
> David Cunningham/Watson/IBM@IBMUS wrote on 12/10/2012 12:07:49 PM:
>
> > From: David Cunningham/Watson/IBM@IBMUS
> > To: X10 core design <x10...@li...>,
> > Cc: "taw...@an..."
> > <taw...@an...>, X10 core design <x10-
> > co...@li...>
> > Date: 12/10/2012 12:12 PM
> > Subject: Re: [X10-core] sockets backend serializes places in
> > parallel 'at async'
> >
> > Try setting X10_NOWRITEBUFFER=1
> >
> > Josh Milthorpe <jos...@an...> wrote on 12/10/2012 
> 06:11:18 AM:
> >
> > > From: Josh Milthorpe <jos...@an...>
> > > To: X10 core design <x10...@li...>,
> > > Cc: "taw...@an..." 
> <taw...@an...>
> > > Date: 12/10/2012 06:11 AM
> > > Subject: [X10-core] sockets backend serializes places in parallel 
> 'at async'
> > >
> > > Hi,
> > >
> > > we came across an interesting 'gotcha' where the sockets 
> implementation
> > > of X10RT serializes the places in a parallel 'at async' construction.
> > > We run the same (fairly large) closure at all places:
> > >
> > > for(place in Place.places()) at(place) async {
> > >      // body
> > > }
> > >
> > > We found that for a certain code, when run with X10_NTHREADS=1, 
> Place 0
> > > would run 'body' to completion, and then the other places would run.
> > >
> > > It seems that if 'body' has a large enough environment, the sockets
> > > backend can't send it all to another place in a single write.  It
> > > therefore saves the remaining data to be sent later (x10rt_sockets.cc
> > > nonBlockingWrite 265--306) and continues on with other useful work,
> > > which in this case is to complete 'body'.  Once 'body' is 
> completed at
> > > Place 0 leaving the worker thread idle, it sends the pending data 
> to the
> > > other places, which then start their portions of the work.
> > >
> > > The attached example code (which implements a rather silly 
> parallel sum
> > > over an array of 1M elements) demonstrates the problem:
> > >
> > >          val largeArray = new Array[Double](n, (a:Int)=> a as Double);
> > >          val sum = finish(new Reducible.SumReducer[Double]()) {
> > >              for(place in Place.places()) at(place) async {
> > >                  Console.OUT.println("starting at " + here);
> > > Console.OUT.flush();
> > >                  for (var i:Int=here.id; i<n; i+=Place.MAX_PLACES) {
> > >                      offer largeArray(i);
> > >                  }
> > >                  Console.OUT.println("done at " + here);
> > > Console.OUT.flush();
> > >              }
> > >          };
> > >
> > >
> > > When run over sockets with a small closure environment (e.g. array 
> size
> > > 50000), all places run in parallel as expected, and we observe a
> > > parallel speedup.  When run with a larger environment (default array
> > > size of 1M) we observe parallel slowdown for 2 places, and it is
> > > apparent that place 0 runs to completion before place 1:
> > >
> > > starting at Place(0)
> > > done at Place(0)
> > > starting at Place(1)
> > > done at Place(1)
> > >
> > > When compiled with -x10rt mpi, we observe parallel speedup for 2 
> places
> > > even for large array sizes.
> > >
> > > This is a kind of priority inversion, where the high priority task
> > > (sharing the work among places) has to wait for the completion of a
> > > lower priority task (completing the portion of the work assigned 
> to this
> > > place).  Is there anything that can be done in this case to allow the
> > > nonBlockingWrite to continue in parallel with other work? Or 
> should this
> > > just be documented as a 'gotcha' for the sockets version of X10RT?
> > >
> > > Many thanks,
> > >
> > > Josh
> > >
> > >
> > > [attachment "TestLargeAt.x10" deleted by David Cunningham/Watson/
> > > IBM]
> > >
> > 
> ------------------------------------------------------------------------------
> > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > > Remotely access PCs and mobile devices and provide instant support
> > > Improve your efficiency, and focus on delivering more value-add 
> services
> > > Discover what IT Professionals Know. Rescue delivers
> > > http://p.sf.net/sfu/logmein_12329d2d
> > > _______________________________________________
> > > X10-core mailing list
> > > X10...@li...
> > > https://lists.sourceforge.net/lists/listinfo/x10-core
> > 
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/
> > logmein_12329d2d_______________________________________________
> > X10-core mailing list
> > X10...@li...
> > https://lists.sourceforge.net/lists/listinfo/x10-core
>

Re: [X10-core] sockets backend serializes places in parallel 'at async'

[Olivier T. <ta...@us...>]

Josh,

This is indeed a subtle point.

The X10 runtime is a cooperative one. So today if every thread in a place
is running a long sequential computation, there is no opportunity for the
runtime to process incoming or outgoing network messages.
Moreover long message sends cannot typically be sent in full in one step
(details depend on transport).
So we have two choices here: either block until a long send is complete or
stage a long send in multiple chunks.
I believe we support both options (at least for PAMI and sockets).
For sockets, the behavior is controlled with env var X10_NOWRITEBUFFER.
For PAMI, it is different of course... X10RT_PAMI_BLOCKING_SEND.

The default is not to block (I suspect MPI blocks always but I have not
checked).
The rationale for this default is that it typically gives you more
communication computation overlap "for free."
The computation can resume even if the send is still in progress.
The drawback is what you have observed. The communication is automatically
done in multiple steps but not the computation.
With long computations *and* long sends, we do not get a good interleaving
of chunks of computation and communication for free.
We end up serializing computation at the sender and receiver(s) places.

The alternative avoids this problem by neither splitting the computation
nor the communication so the ordering is closer to the programmer's
intuition.

But there is a better fix (still assuming a purely cooperative runtime).
By periodically calling Runtime.x10rtProbe() in the body of the long
computation, you ensure that transport gets the opportunity to send more
chunks of the long messages.

We have thought about using the compiler to inject these probes
automatically (yield points) but have not decided to go implement this
feature yet.
We could also abandon our cooperative paradigm and permit the runtime to
preempt user threads or have threads of its own to handle such asynchronous
services.
Again, we have not committed to spend the time implementing such features
yet.

Typically one can also restructure the problematic loop into two separate
pieces: the first loop spreading the data, the second computing on it, with
a blocking finish around the first loop,
hence locally disabling the problematic overlap of communication and
computation.

Olivier


David Cunningham/Watson/IBM@IBMUS wrote on 12/10/2012 12:07:49 PM:

> From: David Cunningham/Watson/IBM@IBMUS
> To: X10 core design <x10...@li...>,
> Cc: "taw...@an..."
> <taw...@an...>, X10 core design <x10-
> co...@li...>
> Date: 12/10/2012 12:12 PM
> Subject: Re: [X10-core] sockets backend serializes places in
> parallel 'at async'
>
> Try setting X10_NOWRITEBUFFER=1
>
> Josh Milthorpe <jos...@an...> wrote on 12/10/2012 06:11:18
AM:
>
> > From: Josh Milthorpe <jos...@an...>
> > To: X10 core design <x10...@li...>,
> > Cc: "taw...@an..."
<taw...@an...>
> > Date: 12/10/2012 06:11 AM
> > Subject: [X10-core] sockets backend serializes places in parallel 'at
async'
> >
> > Hi,
> >
> > we came across an interesting 'gotcha' where the sockets implementation

> > of X10RT serializes the places in a parallel 'at async' construction.
> > We run the same (fairly large) closure at all places:
> >
> > for(place in Place.places()) at(place) async {
> >      // body
> > }
> >
> > We found that for a certain code, when run with X10_NTHREADS=1, Place 0

> > would run 'body' to completion, and then the other places would run.
> >
> > It seems that if 'body' has a large enough environment, the sockets
> > backend can't send it all to another place in a single write.  It
> > therefore saves the remaining data to be sent later (x10rt_sockets.cc
> > nonBlockingWrite 265--306) and continues on with other useful work,
> > which in this case is to complete 'body'.  Once 'body' is completed at
> > Place 0 leaving the worker thread idle, it sends the pending data to
the
> > other places, which then start their portions of the work.
> >
> > The attached example code (which implements a rather silly parallel sum

> > over an array of 1M elements) demonstrates the problem:
> >
> >          val largeArray = new Array[Double](n, (a:Int)=> a as Double);
> >          val sum = finish(new Reducible.SumReducer[Double]()) {
> >              for(place in Place.places()) at(place) async {
> >                  Console.OUT.println("starting at " + here);
> > Console.OUT.flush();
> >                  for (var i:Int=here.id; i<n; i+=Place.MAX_PLACES) {
> >                      offer largeArray(i);
> >                  }
> >                  Console.OUT.println("done at " + here);
> > Console.OUT.flush();
> >              }
> >          };
> >
> >
> > When run over sockets with a small closure environment (e.g. array size

> > 50000), all places run in parallel as expected, and we observe a
> > parallel speedup.  When run with a larger environment (default array
> > size of 1M) we observe parallel slowdown for 2 places, and it is
> > apparent that place 0 runs to completion before place 1:
> >
> > starting at Place(0)
> > done at Place(0)
> > starting at Place(1)
> > done at Place(1)
> >
> > When compiled with -x10rt mpi, we observe parallel speedup for 2 places

> > even for large array sizes.
> >
> > This is a kind of priority inversion, where the high priority task
> > (sharing the work among places) has to wait for the completion of a
> > lower priority task (completing the portion of the work assigned to
this
> > place).  Is there anything that can be done in this case to allow the
> > nonBlockingWrite to continue in parallel with other work? Or should
this
> > just be documented as a 'gotcha' for the sockets version of X10RT?
> >
> > Many thanks,
> >
> > Josh
> >
> >
> > [attachment "TestLargeAt.x10" deleted by David Cunningham/Watson/
> > IBM]
> >
>
------------------------------------------------------------------------------

> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add
services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > X10-core mailing list
> > X10...@li...
> > https://lists.sourceforge.net/lists/listinfo/x10-core
>
------------------------------------------------------------------------------

> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/
> logmein_12329d2d_______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

Re: [X10-core] sockets backend serializes places in parallel 'at async'

[David C. <dc...@us...>]

Try setting X10_NOWRITEBUFFER=1

Josh Milthorpe <jos...@an...> wrote on 12/10/2012 06:11:18 
AM:

> From: Josh Milthorpe <jos...@an...>
> To: X10 core design <x10...@li...>, 
> Cc: "taw...@an..." 
<taw...@an...>
> Date: 12/10/2012 06:11 AM
> Subject: [X10-core] sockets backend serializes places in parallel 'at 
async'
> 
> Hi,
> 
> we came across an interesting 'gotcha' where the sockets implementation 
> of X10RT serializes the places in a parallel 'at async' construction. 
> We run the same (fairly large) closure at all places:
> 
> for(place in Place.places()) at(place) async {
>      // body
> }
> 
> We found that for a certain code, when run with X10_NTHREADS=1, Place 0 
> would run 'body' to completion, and then the other places would run.
> 
> It seems that if 'body' has a large enough environment, the sockets 
> backend can't send it all to another place in a single write.  It 
> therefore saves the remaining data to be sent later (x10rt_sockets.cc 
> nonBlockingWrite 265--306) and continues on with other useful work, 
> which in this case is to complete 'body'.  Once 'body' is completed at 
> Place 0 leaving the worker thread idle, it sends the pending data to the 

> other places, which then start their portions of the work.
> 
> The attached example code (which implements a rather silly parallel sum 
> over an array of 1M elements) demonstrates the problem:
> 
>          val largeArray = new Array[Double](n, (a:Int)=> a as Double);
>          val sum = finish(new Reducible.SumReducer[Double]()) {
>              for(place in Place.places()) at(place) async {
>                  Console.OUT.println("starting at " + here); 
> Console.OUT.flush();
>                  for (var i:Int=here.id; i<n; i+=Place.MAX_PLACES) {
>                      offer largeArray(i);
>                  }
>                  Console.OUT.println("done at " + here); 
> Console.OUT.flush();
>              }
>          };
> 
> 
> When run over sockets with a small closure environment (e.g. array size 
> 50000), all places run in parallel as expected, and we observe a 
> parallel speedup.  When run with a larger environment (default array 
> size of 1M) we observe parallel slowdown for 2 places, and it is 
> apparent that place 0 runs to completion before place 1:
> 
> starting at Place(0)
> done at Place(0)
> starting at Place(1)
> done at Place(1)
> 
> When compiled with -x10rt mpi, we observe parallel speedup for 2 places 
> even for large array sizes.
> 
> This is a kind of priority inversion, where the high priority task 
> (sharing the work among places) has to wait for the completion of a 
> lower priority task (completing the portion of the work assigned to this 

> place).  Is there anything that can be done in this case to allow the 
> nonBlockingWrite to continue in parallel with other work? Or should this 

> just be documented as a 'gotcha' for the sockets version of X10RT?
> 
> Many thanks,
> 
> Josh
> 
> 
> [attachment "TestLargeAt.x10" deleted by David Cunningham/Watson/
> IBM] 
> 
------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

[X10-core] sockets backend serializes places in parallel 'at async'

[Josh M. <jos...@an...>]

Hi,

we came across an interesting 'gotcha' where the sockets implementation 
of X10RT serializes the places in a parallel 'at async' construction.  
We run the same (fairly large) closure at all places:

for(place in Place.places()) at(place) async {
     // body
}

We found that for a certain code, when run with X10_NTHREADS=1, Place 0 
would run 'body' to completion, and then the other places would run.

It seems that if 'body' has a large enough environment, the sockets 
backend can't send it all to another place in a single write.  It 
therefore saves the remaining data to be sent later (x10rt_sockets.cc 
nonBlockingWrite 265--306) and continues on with other useful work, 
which in this case is to complete 'body'.  Once 'body' is completed at 
Place 0 leaving the worker thread idle, it sends the pending data to the 
other places, which then start their portions of the work.

The attached example code (which implements a rather silly parallel sum 
over an array of 1M elements) demonstrates the problem:

         val largeArray = new Array[Double](n, (a:Int)=> a as Double);
         val sum = finish(new Reducible.SumReducer[Double]()) {
             for(place in Place.places()) at(place) async {
                 Console.OUT.println("starting at " + here); 
Console.OUT.flush();
                 for (var i:Int=here.id; i<n; i+=Place.MAX_PLACES) {
                     offer largeArray(i);
                 }
                 Console.OUT.println("done at " + here); 
Console.OUT.flush();
             }
         };


When run over sockets with a small closure environment (e.g. array size 
50000), all places run in parallel as expected, and we observe a 
parallel speedup.  When run with a larger environment (default array 
size of 1M) we observe parallel slowdown for 2 places, and it is 
apparent that place 0 runs to completion before place 1:

starting at Place(0)
done at Place(0)
starting at Place(1)
done at Place(1)

When compiled with -x10rt mpi, we observe parallel speedup for 2 places 
even for large array sizes.

This is a kind of priority inversion, where the high priority task 
(sharing the work among places) has to wait for the completion of a 
lower priority task (completing the portion of the work assigned to this 
place).  Is there anything that can be done in this case to allow the 
nonBlockingWrite to continue in parallel with other work? Or should this 
just be documented as a 'gotcha' for the sockets version of X10RT?

Many thanks,

Josh

Re: [X10-core] Profiling individual at statements at the application level

[David P G. <gr...@us...>]

David Cunningham/Watson/IBM@IBMUS wrote on 10/10/2012 07:25:51 PM:

>
> OK those extra things are done
>
> If you decide you do want to include this in 2.3, the relevant revisions
are
>
> 24700 (original commit)
> 24707 (ateach)
> 24709 (documentation, at expressions)
>
>

I'm going to have to respin at least some of the builds to pick up a bug
fix for bluegene/p codegen, so I decided to merge these in to the 2.3.0
branch and respin everything.

One consequence of the decision to respin all the builds is that the
earliest possible time for a 2.3 release is Monday, with Tuesday or Wed
being more likely.

--dave

Re: [X10-core] Profiling individual at statements at the application level

[David C. <dc...@us...>]

AtEach is now fixed

In addition I have yet to document the Annotation class and I want to make 
at expressions work as well (parser problem right now)


David P Grove/Watson/IBM@IBMUS wrote on 10/10/2012 08:12:09 AM:

> From: David P Grove/Watson/IBM@IBMUS
> To: X10 core design <x10...@li...>
> Date: 10/10/2012 08:13 AM
> Subject: Re: [X10-core] Profiling individual at statements at the 
> application level
> 
> Vijay Saraswat <vi...@sa...> wrote on 10/09/2012 08:03:08 PM:
> > 
> > Thanks! Looks good.. will be valuable to students. Is this gettinginto 
2.3?
> > 
> 
> It needs fixing.  Appears to have broken ateach.  So, most likely no
> (since we've already branched 2.3). 
> 
> --
> 
dave------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

Re: [X10-core] Profiling individual at statements at the application level

[David P G. <gr...@us...>]

Vijay Saraswat <vi...@sa...> wrote on 10/09/2012 08:03:08 PM:
>
> Thanks! Looks good.. will be valuable to students. Is this getting into
2.3?
>

It needs fixing.  Appears to have broken ateach.  So, most likely no (since
we've already branched 2.3).

--dave

Re: [X10-core] Profiling individual at statements at the application level

[Bard B. <bar...@gm...>]

Oooh, that's really nice, David!

Maybe sometime I'll get back to X10 and able to use it.

On Tue, Oct 9, 2012 at 8:03 PM, Vijay Saraswat <vi...@sa...> wrote:

>  Thanks! Looks good.. will be valuable to students. Is this getting into
> 2.3?
>
>
> On 10/9/12 7:46 PM, David Cunningham wrote:
>
> I've just committed to trunk a change that allows code like the following,
> for both managed and native backends:
>
> import x10.io.Console;
>
> import x10.compiler.*;
>
> public class AtProfile {
>
>     public static def printProf (str:String, x:Runtime.Profile) {
>         Console.OUT.println(str+":  Serialization nanos:
> "+x.serializationNanos+"  Communication nanos: "+x.communicationNanos+"
>  Bytes: "+x.bytes);
>     }
>
>     public static def main (args : Array[String]) {
>         val x = new Runtime.Profile();
>         val arr = new Array[Float](25000);
>         val there = here.next();
>
>
>         x.reset();
>         @Profile(x) at (here) {
>             arr(10) = 10.0f;
>         }
>         printProf("Local at", x);
>
>         x.reset();
>         @Profile(x) at (here) async {
>             arr(10) = 10.0f;
>         }
>         printProf("Local at async", x);
>
>         //x.reset();
>         //val tmp = @Profile(x) at (here) arr(10);
>         //printProf("Local at expr", x);
>
>
>         x.reset();
>         @Profile(x) at (there) {
>             arr(10) = 10.0f;
>         }
>         printProf("Remote at", x);
>
>         x.reset();
>         @Profile(x) at (there) async {
>             arr(10) = 10.0f;
>         }
>         printProf("Remote at async", x);
>
>         //x.reset();
>         //val tmp = @Profile(x) at (there) arr(10);
>         //printProf("Remote at expr", x);
>
>
>         x.reset();
>         Runtime.deepCopy(arr, x);
>         printProf("Explicit deep copy", x);
>     }
> }
>
>
> Currently, one cannot put an annotation on an at expression, which is why
> that is commented out.
>
> Exception serialization is not counted, if you throw an exception.  At
> expression return values are also not counted.
>
> The intention is to only include stuff that the program can control in the
> 'bytes' quantity, i.e. exclude internal overheads (like finish state, x10rt
> overheads, IP/layer 2 packet headers, etc) as much as possible.  The
> reasoning is that any answer we can provide is not going to be accurate is
> it will not be sampled at a low enough level.  So it is best to go for the
> other extreme and only provide information the programmer can relate to.
>  This is quite tricky though in the case of e.g. clocks so right now there
> will still be some extra bytes in some cases.
>
>
>
>
>
> Here is the output for both backends:
>
> MANAGED:
> Local at:  Serialization nanos: 17373456  Communication nanos: 0  Bytes:
> 100093
> Local at async:  Serialization nanos: 35523967  Communication nanos: 0
>  Bytes: 100093
> Remote at:  Serialization nanos: 2324627  Communication nanos: 393421
>  Bytes: 100121
> Remote at async:  Serialization nanos: 1060134  Communication nanos:
> 125017  Bytes: 100091
> Explicit deep copy:  Serialization nanos: 1234391  Communication nanos: 0
>  Bytes: 100091
>
> NATIVE:
> Local at:  Serialization nanos: 564253  Communication nanos: 0  Bytes:
> 100054
> Local at async:  Serialization nanos: 258626  Communication nanos: 0
>  Bytes: 100054
> Remote at:  Serialization nanos: 74382  Communication nanos: 85976  Bytes:
> 100068
> Remote at async:  Serialization nanos: 22279  Communication nanos: 70192
>  Bytes: 100052
> Explicit deep copy:  Serialization nanos: 94776  Communication nanos: 0
>  Bytes: 100052
>
> Take the times with a pinch of salt as there is no warmup phase for the
> managed backend, and the native numbers are for an unoptimised build of X10.
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> X10-core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/x10-core
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core
>
>

Re: [X10-core] Profiling individual at statements at the application level

[Vijay S. <vi...@sa...>]

Thanks! Looks good.. will be valuable to students. Is this getting into 2.3?

On 10/9/12 7:46 PM, David Cunningham wrote:
> I've just committed to trunk a change that allows code like the 
> following, for both managed and native backends:
>
> import x10.io.Console;
>
> import x10.compiler.*;
>
> public class AtProfile {
>
>     public static def printProf (str:String, x:Runtime.Profile) {
> Console.OUT.println(str+":  Serialization nanos: 
> "+x.serializationNanos+"  Communication nanos: 
> "+x.communicationNanos+"  Bytes: "+x.bytes);
>     }
>
>     public static def main (args : Array[String]) {
>         val x = new Runtime.Profile();
>         val arr = new Array[Float](25000);
>         val there = here.next();
>
>
>         x.reset();
>         @Profile(x) at (here) {
> arr(10) = 10.0f;
>         }
>         printProf("Local at", x);
>
>         x.reset();
>         @Profile(x) at (here) async {
> arr(10) = 10.0f;
>         }
>         printProf("Local at async", x);
>
>         //x.reset();
>         //val tmp = @Profile(x) at (here) arr(10);
>         //printProf("Local at expr", x);
>
>
>         x.reset();
>         @Profile(x) at (there) {
> arr(10) = 10.0f;
>         }
>         printProf("Remote at", x);
>
>         x.reset();
>         @Profile(x) at (there) async {
> arr(10) = 10.0f;
>         }
>         printProf("Remote at async", x);
>
>         //x.reset();
>         //val tmp = @Profile(x) at (there) arr(10);
>         //printProf("Remote at expr", x);
>
>
>         x.reset();
>         Runtime.deepCopy(arr, x);
>         printProf("Explicit deep copy", x);
>     }
> }
>
>
> Currently, one cannot put an annotation on an at expression, which is 
> why that is commented out.
>
> Exception serialization is not counted, if you throw an exception.  At 
> expression return values are also not counted.
>
> The intention is to only include stuff that the program can control in 
> the 'bytes' quantity, i.e. exclude internal overheads (like finish 
> state, x10rt overheads, IP/layer 2 packet headers, etc) as much as 
> possible.  The reasoning is that any answer we can provide is not 
> going to be accurate is it will not be sampled at a low enough level. 
>  So it is best to go for the other extreme and only provide 
> information the programmer can relate to.  This is quite tricky though 
> in the case of e.g. clocks so right now there will still be some extra 
> bytes in some cases.
>
>
>
>
>
> Here is the output for both backends:
>
> MANAGED:
> Local at:  Serialization nanos: 17373456  Communication nanos: 0 
>  Bytes: 100093
> Local at async:  Serialization nanos: 35523967  Communication nanos: 0 
>  Bytes: 100093
> Remote at:  Serialization nanos: 2324627  Communication nanos: 393421 
>  Bytes: 100121
> Remote at async:  Serialization nanos: 1060134  Communication nanos: 
> 125017  Bytes: 100091
> Explicit deep copy:  Serialization nanos: 1234391  Communication 
> nanos: 0  Bytes: 100091
>
> NATIVE:
> Local at:  Serialization nanos: 564253  Communication nanos: 0  Bytes: 
> 100054
> Local at async:  Serialization nanos: 258626  Communication nanos: 0 
>  Bytes: 100054
> Remote at:  Serialization nanos: 74382  Communication nanos: 85976 
>  Bytes: 100068
> Remote at async:  Serialization nanos: 22279  Communication nanos: 
> 70192  Bytes: 100052
> Explicit deep copy:  Serialization nanos: 94776  Communication nanos: 
> 0  Bytes: 100052
>
> Take the times with a pinch of salt as there is no warmup phase for 
> the managed backend, and the native numbers are for an unoptimised 
> build of X10.
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

[X10-core] Profiling individual at statements at the application level

[David C. <dc...@us...>]

I've just committed to trunk a change that allows code like the following, 
for both managed and native backends:

import x10.io.Console;

import x10.compiler.*;

public class AtProfile {

    public static def printProf (str:String, x:Runtime.Profile) {
        Console.OUT.println(str+":  Serialization nanos: 
"+x.serializationNanos+"  Communication nanos: "+x.communicationNanos+" 
Bytes: "+x.bytes);
    }

    public static def main (args : Array[String]) {
        val x = new Runtime.Profile();
        val arr = new Array[Float](25000);
        val there = here.next();


        x.reset();
        @Profile(x) at (here) {
            arr(10) = 10.0f;
        }
        printProf("Local at", x);

        x.reset();
        @Profile(x) at (here) async {
            arr(10) = 10.0f;
        }
        printProf("Local at async", x);

        //x.reset();
        //val tmp = @Profile(x) at (here) arr(10);
        //printProf("Local at expr", x);


        x.reset();
        @Profile(x) at (there) {
            arr(10) = 10.0f;
        }
        printProf("Remote at", x);

        x.reset();
        @Profile(x) at (there) async {
            arr(10) = 10.0f;
        }
        printProf("Remote at async", x);

        //x.reset();
        //val tmp = @Profile(x) at (there) arr(10);
        //printProf("Remote at expr", x);


        x.reset();
        Runtime.deepCopy(arr, x);
        printProf("Explicit deep copy", x);
    } 
} 


Currently, one cannot put an annotation on an at expression, which is why 
that is commented out.

Exception serialization is not counted, if you throw an exception.  At 
expression return values are also not counted.

The intention is to only include stuff that the program can control in the 
'bytes' quantity, i.e. exclude internal overheads (like finish state, 
x10rt overheads, IP/layer 2 packet headers, etc) as much as possible.  The 
reasoning is that any answer we can provide is not going to be accurate is 
it will not be sampled at a low enough level.  So it is best to go for the 
other extreme and only provide information the programmer can relate to. 
This is quite tricky though in the case of e.g. clocks so right now there 
will still be some extra bytes in some cases.





Here is the output for both backends:

MANAGED:
Local at:  Serialization nanos: 17373456  Communication nanos: 0  Bytes: 
100093
Local at async:  Serialization nanos: 35523967  Communication nanos: 0 
Bytes: 100093
Remote at:  Serialization nanos: 2324627  Communication nanos: 393421 
Bytes: 100121
Remote at async:  Serialization nanos: 1060134  Communication nanos: 
125017  Bytes: 100091
Explicit deep copy:  Serialization nanos: 1234391  Communication nanos: 0 
Bytes: 100091

NATIVE:
Local at:  Serialization nanos: 564253  Communication nanos: 0  Bytes: 
100054
Local at async:  Serialization nanos: 258626  Communication nanos: 0 
Bytes: 100054
Remote at:  Serialization nanos: 74382  Communication nanos: 85976  Bytes: 
100068
Remote at async:  Serialization nanos: 22279  Communication nanos: 70192 
Bytes: 100052
Explicit deep copy:  Serialization nanos: 94776  Communication nanos: 0 
Bytes: 100052

Take the times with a pinch of salt as there is no warmup phase for the 
managed backend, and the native numbers are for an unoptimised build of 
X10.

Re: [X10-core] major change to C++ codegeneration: elimination of x10aux::ref

[Josh M. <jos...@an...>]

Hi Dave,

this definitely improves the readability of the generated code. For our 
codes, there will be some changes required to definitions of native 
methods but this looks like only a few minutes' work.

I compared compile times for ANU-Chem packages on two computers: my ANU 
desktop which is a Core2 Q9550@2.83GHz with GCC 4.4.3, and my home 
computer which is a Pentium D (much slower) with GCC 4.6.3.   Example 
times are below: compile times have reduced slightly on the home 
computer but strangely seem to have actually increased on my ANU desktop.

I have no idea why this is.  You mentioned that the number of header 
files included has previously been the major issue, so maybe ref<T> 
wasn't the main problem after all...

Cheers,

Josh

Uni: GCC 4.4.3 before
anu-chem Total time: 1 minute 8 seconds
fmm Total time: 1 minute 45 seconds
fmm-lib Total time: 1 minute 48 seconds
anum Total time: 34 seconds

Uni: GCC 4.4.3 after
anu-chem Total time: 1 minute 19 seconds
fmm Total time: 1 minute 42 seconds
fmm-lib Total time: 2 minutes 14 seconds
anum Total time: 32 seconds


home: GCC 4.6.3 before
anu-chem Total time: 3 minutes 14 seconds
fmm      Total time: 5 minutes 45 seconds
fmm-lib  Total time: 6 minutes 13 seconds
anum     Total time: 1 minute 24 seconds

home: GCC 4.6.3 after
anu-chem Total time: 3 minutes 0 seconds
fmm      Total time: 5 minutes 24 seconds
fmm-lib  Total time: 5 minutes 52 seconds
anum     Total time: 1 minute 7 seconds

On 01/09/12 00:49, David P Grove wrote:
>
> I've just committed the major change in C++ code generation that I've 
> been contemplating doing for months and have talked to several of you 
> about....x10aux::ref is no more.
>
> If you don't know what x10aux::ref is, you can safely ignore the rest 
> of this email.  Modulo any @Native declarations that I failed to 
> update this change should be completely invisible to the X10 programmer.
>
> If you write @Native annotations (or native C++ code that needs to 
> interact with the X10 object model), then read on...
>
> The heart of the change is that a C++ type that used to be written 
> ref<T> is now written as T*
>
> For example:
>  ref<Array<ref<String> > becomes Array<String*>*
>  ref(Array<int> > becomes Array<int>*
>
> Benefits:
>  (1) Less template instantiation, faster C++ compilation and
>        more readable/standard C++ types (and symbol names)
>  (2) We can now actually use C++'s catch blocks properly instead of
>      generating our own dynamic type tests inside of a single catch.
>
> Drawbacks (?):
>  (1) No silent conversion from one pointer type to an arbitrary other 
> pointer type.
>      The C++ code generator (and the programmer writing native code)
>      needs to be more aware of how the X10 and C++ object model
>      are related to each other and inject reinterpret_casts where needed.
>       This makes some things more verbose, but based on the thousands 
> of lines
>       of code I was modifying yesterday, I think this is actually an 
> improvement
>       because the places where something interesting is happening 
> become explicit.
>
> --dave
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

[X10-core] major change to C++ codegeneration: elimination of x10aux::ref

[David P G. <gr...@us...>]

I've just committed the major change in C++ code generation that I've been
contemplating doing for months and have talked to several of you
about....x10aux::ref is no more.

If you don't know what x10aux::ref is, you can safely ignore the rest of
this email.  Modulo any @Native declarations that I failed to update this
change should be completely invisible to the X10 programmer.

If you write @Native annotations (or native C++ code that needs to interact
with the X10 object model), then read on...

The heart of the change is that a C++ type that used to be written ref<T>
is now written as T*

For example:
  ref<Array<ref<String> > becomes Array<String*>*
  ref(Array<int> > becomes Array<int>*

Benefits:
  (1) Less template instantiation, faster C++ compilation and
        more readable/standard C++ types (and symbol names)
  (2) We can now actually use C++'s catch blocks properly instead of
      generating our own dynamic type tests inside of a single catch.

Drawbacks (?):
  (1) No silent conversion from one pointer type to an arbitrary other
pointer type.
      The C++ code generator (and the programmer writing native code)
      needs to be more aware of how the X10 and C++ object model
      are related to each other and inject reinterpret_casts where needed.
      This makes some things more verbose, but based on the thousands of
lines
      of code I was modifying yesterday, I think this is actually an
improvement
      because the places where something interesting is happening become
explicit.

--dave

Re: [X10-core] Porting notes for X10 2.3

[David C. <dc...@us...>]

I should have included an example like the following for the new syntaxes:

f has a method guard T isref, takes a T, returns a T, and also throws 
CheckedThrowable

public class XTEN_2_3 {

    public static def f[T](x:T) { T isref } : T throws CheckedThrowable = 
x;

    public static def main (args : Rail[String]) {
        try {
            f(new String());
            //f(42); // error -- Int isref inconsistent
        } catch (e:CheckedThrowable) { // type system requires we catch 
here
            e.printStackTrace();
        }
    }
}




Mikio Takeuchi <mik...@gm...> wrote on 08/30/2012 09:27:23 AM:

> From: Mikio Takeuchi <mik...@gm...>
> To: "vi...@sa..." <vi...@sa...>
> Cc: "x10...@li..." <x10...@li...>
> Date: 08/30/2012 09:27 AM
> Subject: Re: [X10-core] Porting notes for X10 2.3
> 
> Hi, Vijay. 
> 
> We implemented throws clause just as Java. @Throws[T] annotation was 
gone. 
> 
> - Mikio
> 
> On Aug 30, 2012, at 21:33, Vijay Saraswat <vi...@sa...> wrote:

> Thanks a lot, Dave and Mikio!
> 
> A quick question.. what is the syntax for declaring a method throws 
> an exception? (not sure how to interprete "annotation", could be a 
> throws clause or could be a genuine annotation. what did you implement.)
> 
> On 8/29/12 11:24 PM, David Cunningham wrote:
> We just merged the interop-exceptions branch into trunk, and this 
> carries with it a number of changes (that are not backwards 
> compatible) to allow cleaner Java interoperability for the managed 
> backend.  You will probably have to make some minor adjustments to 
> your X10 code if you intend to compile it using trunk X10, or the 
> forthcoming X10 2.3 release. 
> 
> 
> The new syntax T isref for some type T will hold if T is represented
> by a pointer at runtime.  This is similar to the type constraint T 
> haszero.  T isref is true for T that are function types, classes, 
> and all values that have been cast to interfaces (including boxed 
> structs).  T isref is used in the standard library, e.g. for the 
> GlobalRef[T] and PlaceLocalHandle[T] APIs. 
> 
> 
> x10.lang.Object is gone, there is now no single class that is the 
> supertype of all classes. 
> 
> If, for some reason, you were extending Object, don't do that anymore. 
> 
> If you were doing new Object() to get a fresh value, use new Empty() 
instead.
> 
> If you were using Object as a supertype, use Any (the one true 
supertype). 
> 
> If you were using the type constraint T <: Object to disallow 
> structs, use T isref instead. 
> 
> 
> The exception hierarchy has changed, and checked exceptions have 
> been reintroduced.  The 'throws' annotation is required on methods, 
> as in Java.  It is not supported on closures, so checked exceptions 
> cannot be thrown from a closure.  The exception hierarchy has been 
> chosen to exist in a 1:1 relationship with Java's.  However, unlike 
> Java, we prefer using unchecked exceptions wherever possible, and 
> this is reflected in the naming of the X10 classes.  The following 
> classes are all in the x10.lang package. 
> 
>     CheckedThrowable  (mapped to java.lang.Throwable) 
>     \-- CheckedException  (mapped to java.lang.Exception) 
>         \-- Exception  (mapped to java.lang.RuntimeException) 
>     \-- Error  (mapped to java.lang.Error) 
> 
> Anything under CheckedThrowable can be thrown using the throw 
> statement... But anything that is not under Exception or Error can 
> only be thrown if it is caught by an enclosing try/catch, or it is 
> thrown from a method with an appropriate throws annotation, as in Java. 
> 
> RuntimeException is gone from X10.  Use Exception instead. 
> 
> All the exceptions in the standard library are under Exception, 
> except AssertionError and OutOfMemoryException, which are under 
> Error (as in Java).  This means all exceptions in the standard 
> library remain unchecked. 
> 
> Note that catching Exception is not sufficient to catch 
> AssertionError or OutOfMemoryException.  To handle all unchecked 
> exceptions, one must catch Exception and Error in separate catch 
> blocks, catch CheckedThrowable in a single catch block, or use a 
> finally block.  This is the same as Java. 
> 
> Best practice is to derive from Exception for your own X10 exception
> classes, in which case no throws annotations are needed anywhere in 
> your X10 code.  If you write X10 code that interoperates with Java, 
> you may have to deal with checked exceptions such as 
> java.io.IOException in your X10 code.  This is when you may consider
> using throws annotations. 
> 
> We also provide an exception x10.lang.WrappedThrowable under 
> Exception, that can be used to wrap a given CheckedThrowable using 
> the exception chaining mechanism (getCause()) if it is not already a
> subtype of Exception.  This can be useful for handling arbitrary 
> exceptions coming from Java code, at the boundary with X10, forcing 
> them into more X10-friendly exceptions that are under 
x10.lang.Exception. 
> 
>     // rethrow a checked exception (or an Error) as an Exception by 
> wrapping it in WrappedThrowable if necessary 
>     try { 
>         assert false; 
>     } catch (t:CheckedThrowable) { throw Exception.ensureException(t); } 

> 
> Checked exceptions and Errors are cleanly propagated through 'at' 
> blocks just like any other exception. 
> 
> Checked exceptions and Errors are wrapped in WrappedThrowable at the
> root of an async, when they are pushed into a MultipleExceptions 
> object.  Therefore only Exception objects can come out of a 
> MultipleExceptions object. 
> 
> 
> With all this in mind, here is some porting advice for exceptions in 2.3 

> 
> If you previously extended Throwable, extend Exception instead. 
> 
> If you previously extended RuntimeException, extend Exception instead. 
> 
> If you previously extended Error, do some soul searching to decide 
> whether you want your exception to be caught by 'catch 
> (e:Exception)' or not.  You probably should be extending Exception 
instead. 
> 
> If for some reason you really want to use checked exceptions in X10,
> you can extend CheckedException.  But we don't recommend this as the
> throws annotation is not supported in function types.  You're 
> probably making your life harder, not easier. 
> 
> If you previously caught Throwable, you need to change to one of these: 
> 
> try { ... } catch (e:CheckedThrowable) { ... } 
> try { ... } catch (e:Exception) { ... } catch (e:Error) { ... } 
> 
> If you want to catch everything and do e.printStackTrace(), then 
> catching CheckedThrowable is a good choice.  However if you are 
> catching to rethrow, this will force you to include a throws 
> CheckedThrowable annotation on your method, and any methods that 
> transitively call it.  You probably don't want that. 
> 
> If you want to rethrow everything but you only care about unchecked 
> exceptions, e.g. you need to close a file or release a lock or some 
> other 'end of work' bureaucracy around code that may throw 
> exceptions, then you can use a finally block, or catch both Error 
> and Exception (duplicating your handling code) and rethrow these 
> exceptions without needing a throws annotation on your method. 
> 
> You can also catch (e:CheckedThrowable) and use 
> Exception.ensureException(e) to wrap it when you rethrow it, but 
> this will obviously be caught as a WrappedThrowable instead of the 
> original exception, which is probably not what you want. 
> 
> Of course if you were actually catching a particular exception, e.g.
> to implement some exciting control flow such as jumping out from the
> middle of a recursive call stack, then catch that specific type. 
> 
> 
> Hope this helps. 

> 
------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. 
Discussions 
> will include endpoint security, mobile security and the latest in 
malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 

> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

> 
> 
------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. 
Discussions 
> will include endpoint security, mobile security and the latest in 
malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core
> 
------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. 
Discussions 
> will include endpoint security, mobile security and the latest in 
malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

Re: [X10-core] Porting notes for X10 2.3

[Mikio T. <mik...@gm...>]

Hi, Vijay.

We implemented throws clause just as Java. @Throws[T] annotation was gone.

- Mikio

On Aug 30, 2012, at 21:33, Vijay Saraswat <vi...@sa...> wrote:

 Thanks a lot, Dave and Mikio!

A quick question.. what is the syntax for declaring a method throws an
exception? (not sure how to interprete "annotation", could be a throws
clause or could be a genuine annotation. what did you implement.)

On 8/29/12 11:24 PM, David Cunningham wrote:

We just merged the interop-exceptions branch into trunk, and this carries
with it a number of changes (that are not backwards compatible) to allow
cleaner Java interoperability for the managed backend.  You will probably
have to make some minor adjustments to your X10 code if you intend to
compile it using trunk X10, or the forthcoming X10 2.3 release.


The new syntax T isref for some type T will hold if T is represented by a
pointer at runtime.  This is similar to the type constraint T haszero.  T
isref is true for T that are function types, classes, and all values that
have been cast to interfaces (including boxed structs).  T isref is used in
the standard library, e.g. for the GlobalRef[T] and PlaceLocalHandle[T]
APIs.


x10.lang.Object is gone, there is now no single class that is the supertype
of all classes.

If, for some reason, you were extending Object, don't do that anymore.

If you were doing new Object() to get a fresh value, use new Empty()
instead.

If you were using Object as a supertype, use Any (the one true supertype).

If you were using the type constraint T <: Object to disallow structs, use
T isref instead.


The exception hierarchy has changed, and checked exceptions have been
reintroduced.  The 'throws' annotation is required on methods, as in Java.
 It is not supported on closures, so checked exceptions cannot be thrown
from a closure.  The exception hierarchy has been chosen to exist in a 1:1
relationship with Java's.  However, unlike Java, we prefer using unchecked
exceptions wherever possible, and this is reflected in the naming of the
X10 classes.  The following classes are all in the x10.lang package.

    CheckedThrowable  (mapped to java.lang.Throwable)
    \-- CheckedException  (mapped to java.lang.Exception)
        \-- Exception  (mapped to java.lang.RuntimeException)
    \-- Error  (mapped to java.lang.Error)

Anything under CheckedThrowable can be thrown using the throw statement...
But anything that is not under Exception or Error can only be thrown if it
is caught by an enclosing try/catch, or it is thrown from a method with an
appropriate throws annotation, as in Java.

RuntimeException is gone from X10.  Use Exception instead.

All the exceptions in the standard library are under Exception, except
AssertionError and OutOfMemoryException, which are under Error (as in
Java).  This means all exceptions in the standard library remain unchecked.

Note that catching Exception is not sufficient to catch AssertionError or
OutOfMemoryException.  To handle all unchecked exceptions, one must catch
Exception and Error in separate catch blocks, catch CheckedThrowable in a
single catch block, or use a finally block.  This is the same as Java.

Best practice is to derive from Exception for your own X10 exception
classes, in which case no throws annotations are needed anywhere in your
X10 code.  If you write X10 code that interoperates with Java, you may have
to deal with checked exceptions such as java.io.IOException in your X10
code.  This is when you may consider using throws annotations.

We also provide an exception x10.lang.WrappedThrowable under Exception,
that can be used to wrap a given CheckedThrowable using the exception
chaining mechanism (getCause()) if it is not already a subtype of
Exception.  This can be useful for handling arbitrary exceptions coming
from Java code, at the boundary with X10, forcing them into more
X10-friendly exceptions that are under x10.lang.Exception.

    // rethrow a checked exception (or an Error) as an Exception by
wrapping it in WrappedThrowable if necessary
    try {
        assert false;
    } catch (t:CheckedThrowable) { throw Exception.ensureException(t); }

Checked exceptions and Errors are cleanly propagated through 'at' blocks
just like any other exception.

Checked exceptions and Errors are wrapped in WrappedThrowable at the root
of an async, when they are pushed into a MultipleExceptions object.
 Therefore only Exception objects can come out of a MultipleExceptions
object.


With all this in mind, here is some porting advice for exceptions in 2.3

If you previously extended Throwable, extend Exception instead.

If you previously extended RuntimeException, extend Exception instead.

If you previously extended Error, do some soul searching to decide whether
you want your exception to be caught by 'catch (e:Exception)' or not.  You
probably should be extending Exception instead.

If for some reason you really want to use checked exceptions in X10, you
can extend CheckedException.  But we don't recommend this as the throws
annotation is not supported in function types.  You're probably making your
life harder, not easier.

If you previously caught Throwable, you need to change to one of these:

try { ... } catch (e:CheckedThrowable) { ... }
try { ... } catch (e:Exception) { ... } catch (e:Error) { ... }

If you want to catch everything and do e.printStackTrace(), then catching
CheckedThrowable is a good choice.  However if you are catching to rethrow,
this will force you to include a throws CheckedThrowable annotation on your
method, and any methods that transitively call it.  You probably don't want
that.

If you want to rethrow everything but you only care about unchecked
exceptions, e.g. you need to close a file or release a lock or some other
'end of work' bureaucracy around code that may throw exceptions, then you
can use a finally block, or catch both Error and Exception (duplicating
your handling code) and rethrow these exceptions without needing a throws
annotation on your method.

You can also catch (e:CheckedThrowable) and use
Exception.ensureException(e) to wrap it when you rethrow it, but this will
obviously be caught as a WrappedThrowable instead of the original
exception, which is probably not what you want.

Of course if you were actually catching a particular exception, e.g. to
implement some exciting control flow such as jumping out from the middle of
a recursive call stack, then catch that specific type.


Hope this helps.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/



_______________________________________________
X10-core mailing
lis...@li...https://lists.sourceforge.net/lists/listinfo/x10-core


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
X10-core mailing list
X10...@li...
https://lists.sourceforge.net/lists/listinfo/x10-core

Re: [X10-core] Porting notes for X10 2.3

[Vijay S. <vi...@sa...>]

Thanks a lot, Dave and Mikio!

A quick question.. what is the syntax for declaring a method throws an 
exception? (not sure how to interprete "annotation", could be a throws 
clause or could be a genuine annotation. what did you implement.)

On 8/29/12 11:24 PM, David Cunningham wrote:
> We just merged the interop-exceptions branch into trunk, and this 
> carries with it a number of changes (that are not backwards 
> compatible) to allow cleaner Java interoperability for the managed 
> backend.  You will probably have to make some minor adjustments to 
> your X10 code if you intend to compile it using trunk X10, or the 
> forthcoming X10 2.3 release.
>
>
> The new syntax T isref for some type T will hold if T is represented 
> by a pointer at runtime.  This is similar to the type constraint T 
> haszero.  T isref is true for T that are function types, classes, and 
> all values that have been cast to interfaces (including boxed 
> structs).  T isref is used in the standard library, e.g. for the 
> GlobalRef[T] and PlaceLocalHandle[T] APIs.
>
>
> x10.lang.Object is gone, there is now no single class that is the 
> supertype of all classes.
>
> If, for some reason, you were extending Object, don't do that anymore.
>
> If you were doing new Object() to get a fresh value, use new Empty() 
> instead.
>
> If you were using Object as a supertype, use Any (the one true 
> supertype).
>
> If you were using the type constraint T <: Object to disallow structs, 
> use T isref instead.
>
>
> The exception hierarchy has changed, and checked exceptions have been 
> reintroduced.  The 'throws' annotation is required on methods, as in 
> Java.  It is not supported on closures, so checked exceptions cannot 
> be thrown from a closure.  The exception hierarchy has been chosen to 
> exist in a 1:1 relationship with Java's.  However, unlike Java, we 
> prefer using unchecked exceptions wherever possible, and this is 
> reflected in the naming of the X10 classes.  The following classes are 
> all in the x10.lang package.
>
>     CheckedThrowable  (mapped to java.lang.Throwable)
>     \-- CheckedException  (mapped to java.lang.Exception)
>         \-- Exception  (mapped to java.lang.RuntimeException)
>     \-- Error  (mapped to java.lang.Error)
>
> Anything under CheckedThrowable can be thrown using the throw 
> statement... But anything that is not under Exception or Error can 
> only be thrown if it is caught by an enclosing try/catch, or it is 
> thrown from a method with an appropriate throws annotation, as in Java.
>
> RuntimeException is gone from X10.  Use Exception instead.
>
> All the exceptions in the standard library are under Exception, except 
> AssertionError and OutOfMemoryException, which are under Error (as in 
> Java).  This means all exceptions in the standard library remain 
> unchecked.
>
> Note that catching Exception is not sufficient to catch AssertionError 
> or OutOfMemoryException.  To handle all unchecked exceptions, one must 
> catch Exception and Error in separate catch blocks, catch 
> CheckedThrowable in a single catch block, or use a finally block. 
>  This is the same as Java.
>
> Best practice is to derive from Exception for your own X10 exception 
> classes, in which case no throws annotations are needed anywhere in 
> your X10 code.  If you write X10 code that interoperates with Java, 
> you may have to deal with checked exceptions such as 
> java.io.IOException in your X10 code.  This is when you may consider 
> using throws annotations.
>
> We also provide an exception x10.lang.WrappedThrowable under 
> Exception, that can be used to wrap a given CheckedThrowable using the 
> exception chaining mechanism (getCause()) if it is not already a 
> subtype of Exception.  This can be useful for handling arbitrary 
> exceptions coming from Java code, at the boundary with X10, forcing 
> them into more X10-friendly exceptions that are under x10.lang.Exception.
>
>     // rethrow a checked exception (or an Error) as an Exception by 
> wrapping it in WrappedThrowable if necessary
>     try {
>         assert false;
>     } catch (t:CheckedThrowable) { throw Exception.ensureException(t); }
>
> Checked exceptions and Errors are cleanly propagated through 'at' 
> blocks just like any other exception.
>
> Checked exceptions and Errors are wrapped in WrappedThrowable at the 
> root of an async, when they are pushed into a MultipleExceptions 
> object.  Therefore only Exception objects can come out of a 
> MultipleExceptions object.
>
>
> With all this in mind, here is some porting advice for exceptions in 2.3
>
> If you previously extended Throwable, extend Exception instead.
>
> If you previously extended RuntimeException, extend Exception instead.
>
> If you previously extended Error, do some soul searching to decide 
> whether you want your exception to be caught by 'catch (e:Exception)' 
> or not.  You probably should be extending Exception instead.
>
> If for some reason you really want to use checked exceptions in X10, 
> you can extend CheckedException.  But we don't recommend this as the 
> throws annotation is not supported in function types.  You're probably 
> making your life harder, not easier.
>
> If you previously caught Throwable, you need to change to one of these:
>
> try { ... } catch (e:CheckedThrowable) { ... }
> try { ... } catch (e:Exception) { ... } catch (e:Error) { ... }
>
> If you want to catch everything and do e.printStackTrace(), then 
> catching CheckedThrowable is a good choice.  However if you are 
> catching to rethrow, this will force you to include a throws 
> CheckedThrowable annotation on your method, and any methods that 
> transitively call it.  You probably don't want that.
>
> If you want to rethrow everything but you only care about unchecked 
> exceptions, e.g. you need to close a file or release a lock or some 
> other 'end of work' bureaucracy around code that may throw exceptions, 
> then you can use a finally block, or catch both Error and Exception 
> (duplicating your handling code) and rethrow these exceptions without 
> needing a throws annotation on your method.
>
> You can also catch (e:CheckedThrowable) and use 
> Exception.ensureException(e) to wrap it when you rethrow it, but this 
> will obviously be caught as a WrappedThrowable instead of the original 
> exception, which is probably not what you want.
>
> Of course if you were actually catching a particular exception, e.g. 
> to implement some exciting control flow such as jumping out from the 
> middle of a recursive call stack, then catch that specific type.
>
>
> Hope this helps.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core

[X10-core] Porting notes for X10 2.3

[David C. <dc...@us...>]

We just merged the interop-exceptions branch into trunk, and this carries 
with it a number of changes (that are not backwards compatible) to allow 
cleaner Java interoperability for the managed backend.  You will probably 
have to make some minor adjustments to your X10 code if you intend to 
compile it using trunk X10, or the forthcoming X10 2.3 release.


The new syntax T isref for some type T will hold if T is represented by a 
pointer at runtime.  This is similar to the type constraint T haszero.  T 
isref is true for T that are function types, classes, and all values that 
have been cast to interfaces (including boxed structs).  T isref is used 
in the standard library, e.g. for the GlobalRef[T] and PlaceLocalHandle[T] 
APIs.


x10.lang.Object is gone, there is now no single class that is the 
supertype of all classes.

If, for some reason, you were extending Object, don't do that anymore.

If you were doing new Object() to get a fresh value, use new Empty() 
instead.

If you were using Object as a supertype, use Any (the one true supertype).

If you were using the type constraint T <: Object to disallow structs, use 
T isref instead.


The exception hierarchy has changed, and checked exceptions have been 
reintroduced.  The 'throws' annotation is required on methods, as in Java. 
 It is not supported on closures, so checked exceptions cannot be thrown 
from a closure.  The exception hierarchy has been chosen to exist in a 1:1 
relationship with Java's.  However, unlike Java, we prefer using unchecked 
exceptions wherever possible, and this is reflected in the naming of the 
X10 classes.  The following classes are all in the x10.lang package.

    CheckedThrowable  (mapped to java.lang.Throwable)
    \-- CheckedException  (mapped to java.lang.Exception)
        \-- Exception  (mapped to java.lang.RuntimeException)
    \-- Error  (mapped to java.lang.Error)

Anything under CheckedThrowable can be thrown using the throw statement... 
But anything that is not under Exception or Error can only be thrown if it 
is caught by an enclosing try/catch, or it is thrown from a method with an 
appropriate throws annotation, as in Java.

RuntimeException is gone from X10.  Use Exception instead.

All the exceptions in the standard library are under Exception, except 
AssertionError and OutOfMemoryException, which are under Error (as in 
Java).  This means all exceptions in the standard library remain 
unchecked.

Note that catching Exception is not sufficient to catch AssertionError or 
OutOfMemoryException.  To handle all unchecked exceptions, one must catch 
Exception and Error in separate catch blocks, catch CheckedThrowable in a 
single catch block, or use a finally block.  This is the same as Java.

Best practice is to derive from Exception for your own X10 exception 
classes, in which case no throws annotations are needed anywhere in your 
X10 code.  If you write X10 code that interoperates with Java, you may 
have to deal with checked exceptions such as java.io.IOException in your 
X10 code.  This is when you may consider using throws annotations.

We also provide an exception x10.lang.WrappedThrowable under Exception, 
that can be used to wrap a given CheckedThrowable using the exception 
chaining mechanism (getCause()) if it is not already a subtype of 
Exception.  This can be useful for handling arbitrary exceptions coming 
from Java code, at the boundary with X10, forcing them into more 
X10-friendly exceptions that are under x10.lang.Exception.

    // rethrow a checked exception (or an Error) as an Exception by 
wrapping it in WrappedThrowable if necessary
    try {
        assert false;
    } catch (t:CheckedThrowable) { throw Exception.ensureException(t); }

Checked exceptions and Errors are cleanly propagated through 'at' blocks 
just like any other exception.

Checked exceptions and Errors are wrapped in WrappedThrowable at the root 
of an async, when they are pushed into a MultipleExceptions object. 
Therefore only Exception objects can come out of a MultipleExceptions 
object.


With all this in mind, here is some porting advice for exceptions in 2.3

If you previously extended Throwable, extend Exception instead.

If you previously extended RuntimeException, extend Exception instead.

If you previously extended Error, do some soul searching to decide whether 
you want your exception to be caught by 'catch (e:Exception)' or not.  You 
probably should be extending Exception instead.

If for some reason you really want to use checked exceptions in X10, you 
can extend CheckedException.  But we don't recommend this as the throws 
annotation is not supported in function types.  You're probably making 
your life harder, not easier.

If you previously caught Throwable, you need to change to one of these:

try { ... } catch (e:CheckedThrowable) { ... }
try { ... } catch (e:Exception) { ... } catch (e:Error) { ... }

If you want to catch everything and do e.printStackTrace(), then catching 
CheckedThrowable is a good choice.  However if you are catching to 
rethrow, this will force you to include a throws CheckedThrowable 
annotation on your method, and any methods that transitively call it.  You 
probably don't want that.

If you want to rethrow everything but you only care about unchecked 
exceptions, e.g. you need to close a file or release a lock or some other 
'end of work' bureaucracy around code that may throw exceptions, then you 
can use a finally block, or catch both Error and Exception (duplicating 
your handling code) and rethrow these exceptions without needing a throws 
annotation on your method.

You can also catch (e:CheckedThrowable) and use 
Exception.ensureException(e) to wrap it when you rethrow it, but this will 
obviously be caught as a WrappedThrowable instead of the original 
exception, which is probably not what you want.

Of course if you were actually catching a particular exception, e.g. to 
implement some exciting control flow such as jumping out from the middle 
of a recursive call stack, then catch that specific type.


Hope this helps.

Re: [X10-core] X10 2.3 exception hierarchy

[Mikio T. <mik...@gm...>]

Good to hear that Object will be removed.
Thanks,
-- Mikio

2012/7/20 David Cunningham <dc...@us...>:
> OK, we had the discussion (Avi, Vijay, Dave Grove, me)
>
> Current plan is to
>
> 1) remove Object
> 2) add an isref keyword, that can be used in constraints like haszero to
> indicate that a type is not a struct
>
> isref will be used anywhere where <:Object is currently used, e.g.
>
> GlobalRef
> PlaceLocalHandle
>
> and some others (Deque?)
>
> Classes that do not specify a parent will have default implementations of
> typeName() equals() toString() hashCode(), perhaps through extending RefI
> although RefI is no longer visible to the x10 programmer.  Another option is
> to simply generate such methods in every generated java class.
>
> Going off on a slight tangent, it would be nice if X10 classes that extend
> java classes have default implementations of typeName and friends provided
> that are similar to the ones in RefI.
>
>
> And a small status update:  I have almost finished adding throws back into
> the exceptions branch.  Just ironing out some bugs.
>
>
> Mikio Takeuchi <mik...@gm...> wrote on 07/19/2012 03:37:11 AM:
>
>> From: Mikio Takeuchi <mik...@gm...>
>> To: X10 core design <x10...@li...>,
>> Date: 07/19/2012 03:37 AM
>> Subject: Re: [X10-core] X10 2.3 exception hierarchy
>>
>> Hi, Dave,
>>
>> As I told you yesterday in the Sametime chat, there is an issue to
>> make CheckedThrowable NativeRep'ed to java.lang.Throwable.
>> Since j.l.Throwable is a direct child of j.l.Object, it must be a
>> direct child of Any. However, it is a child of x.l.Object in the
>> proposed hierarchy.
>>
>> I think there are three possible options to implement CheckedThrowable.
>>
>> 1. If we can remove Object, it is the best.
>>
>> 2. If it (i.e. removal of Object) is not acceptable, if
>> CheckedThrowable is a direct child of Any, it is OK.
>>
>> 3. If it (i.e. making CheckedThrowable direct child of Any) is not
>> acceptable, we need to box CheckedThrowable to something that
>> implements x10.core.RefI (to which x.l.Object is NativeRep'ed). As I
>> told you, this already happens with x.l.String so the logic is already
>> there.
>>
>> I wonder the Option 3 is has the least impact to the existing code.
>> However if we remove Object, it is the best chance.  Please discuss
>> with Vijay and the team and let me know their decision.
>>
>> -- Mikio
>>
>>
>> 2012/7/19 David Cunningham <dc...@us...>:
>> > Just had a discussion with Dave Grove about what to do about Exception,
>> > Throwable, etc.  It somewhat makes my last email obsolete, so I'llresay
>> > the
>
>> > relevant parts from scratch.  Also spoke with Vijay who is OK with these
>> > changes.
>> >
>> >
>> > The simple back story is we want the exception hierarchy in X10 to be
>> > symmetrical with Java.  We want best practices for programming with
>> > exceptions in X10 to be as similar as possible to Java, up to the switch
>> > to
>> > preferring unchecked exceptions.  We want the names of the classes to be
>> > sensible as well.
>> >
>> >
>> > Backwards incompatible changes:
>> >
>> > The first change is that the root (Throwable) is checked rather than
>> > unchecked.  We will thus name it CheckedThrowable.  Throwable no-longer
>> > exists in the language.
>> >
>> > The second change is the introduction of a new class CheckedException,
>> > which
>> > is the root of all exceptions (including checked ones) that are not
>> > under
>> > Error.
>> >
>> > The third change is the squashing of RuntimeException and Exception to a
>> > single class called Exception.  This makes sense because Exception is
>> > unchecked in X10 so the distinction between these two classes in Java
>> > does
>> > not exist in X10.
>> >
>> >
>> > Red means checked, green means unchecked
>> >
>> > Old X10 hierarchy:
>> > x10.lang.Throwable
>> >         x10.lang.Exception
>> >                 x10.lang.RuntimeException
>> >                         NPE, CCE, ABIE, SBIE, etc
>> >                 x10.io.Exception, etc
>> >         x10.lang.Error
>> >                 OOME, x10.lang.AssertionError
>> >
>> >
>> > Java hierarchy
>> > java.lang.Throwable
>> >         java.lang.Exception
>> >                 java.lang.RuntimeException
>> >                         NPE, CCE, ABIE, SBIE, etc
>> >                 java.io.Exception, etc
>> >         java.lang.Error
>> >                 OOME, java.lang.AssertionError
>> >
>> >
>> > New X10 hierarchy (classes only visible in managed backend are shown in
>> > parens)
>> > x10.lang.CheckedThrowable
>> >         x10.lang.CheckedException
>> >                 x10.lang.Exception
>> >                         NPE, CCE, ABIE, SBIE, etc
>> >                         x10.io.IOException, etc
>> >                         (Any java class that extends
>> > java.lang.RuntimeException, e.g. java.lang.ArrayStoreException)
>> >                 (Any  java class that extends java.lang.Exception, e.g.
>> > java.io.IOException)
>> >         x10.lang.Error
>> >                 OOME, x10.lang.AssertionError
>> >                 (Any java class that extends java.lang.Error, e.g.
>> > java.lang.StackOverflowException)
>> >
>> > The New X10 hierarchy is the same as the Java hierarchy, but with some
>> > classes renamed.  This makes interop and java codegen very simple.  None
>> > of
>> > the mapped Java classes (e.g. java.lang.Throwable) are accessible via
>> > interop, one must use the X10 names.  Exception stack traces printed by
>> > X10
>> > code or by the X10 runtime will use the X10 names.
>> >
>> >
>> >
>> >
>> > Migration advice and best practices for new X10 exception hierarchy
>> >
>> > If you prreviously extended Throwable, you should modify your codeto
>> > extend
>
>> > Exception or Error instead.  The distinction between Exception and Error
>> > in
>> > X10 is the same as that between Exception and Error in java.
>> > * Extend Error for internal application errors that should be
>> > immediately
>> > propagated to the user, either to provide useful bug reporting
>> > information
>> > (i.e. the stack trace), or because handling of the error without exiting
>> > the
>> > application is not possible.
>> > * Extend Exception when the exception could reasonably be handled by the
>> > application, e.g. by showing the user a more comprehensible error
>> > message,
>> > or by transparently ignoring a configuration file that could not be
>> > read.
>> >
>> > If you were catching Throwable, you should either
>> > * catch Exception, if you want to handle the exception without
>> > propagating
>> > it to the user, i.e. let exceptions under Error fall through your catch
>> > statement
>> > * catch Exception and Error (in separate catch blocks), if the catch is
>> > for
>> > preserving the integrity of your state during exceptional control flow,
>> > e.g.
>> > releasing a lock, closing a file, etc.  These exceptions are typically
>> > rethrown.
>> > * catch CheckedException if you want to catch all checked exceptions
>> > (e.g.
>> > if you call a method that has a throws CheckedException annotation).
>> > You
>> > cannot rethrow such exceptions without a throws annotation on your
>> > method,
>> > but you can package them and rethrow.
>> > * catch CheckedThrowable, if you want to catch everything.  You cannot
>> > rethrow a caught exception without the throws CheckedThrowable
>> > annotation on
>> > your method.
>> >
>> > If you were extending RuntimeException, you should extend Exception
>> > instead.
>> >
>> > If you were catching RuntimeException, catch Exception instead.
>> >
>> > Most people should define a new exception by extending Exception.  The
>> > X10
>> > standard library and other libraries from the X10 team will only throw
>> > exceptions under Exception.
>> >
>> > If you want an exception that should bypass most user exception
>> > handling,
>> > extend Error.
>> >
>> > If for some reason you want a checked exception in X10, extend
>> > CheckedException.  Do not extend Throwable, unless for some reason you
>> > want
>> > your exception to be uncaught by user code that catches Error and
>> > CheckedException.  Note that closures cannot throw checked exceptions or
>> > call methods with throws annotations, which limits the usefulness of
>> > checked
>> > exceptions.
>> >
>> > All exceptions work as expected in an at clause.
>> >
>> > Any exception that reaches the root of an async and is not under
>> > x10.lang.Exception will be wrapped as it is inserted into the
>> > MultipleExceptions object.
>> >
>> >
>>
>> ------------------------------------------------------------------------------
>> > Live Security Virtual Conference
>> > Exclusive live event will cover all the ways today's security and
>> > threat landscape has changed and how IT managers can respond.
>> > Discussions
>> > will include endpoint security, mobile security and the latest in
>> > malware
>> > threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>> > _______________________________________________
>> > X10-core mailing list
>> > X10...@li...
>> > https://lists.sourceforge.net/lists/listinfo/x10-core
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> X10-core mailing list
>> X10...@li...
>> https://lists.sourceforge.net/lists/listinfo/x10-core
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core
>

Re: [X10-core] X10 2.3 exception hierarchy

[David C. <dc...@us...>]

OK, we had the discussion (Avi, Vijay, Dave Grove, me)

Current plan is to

1) remove Object
2) add an isref keyword, that can be used in constraints like haszero to 
indicate that a type is not a struct

isref will be used anywhere where <:Object is currently used, e.g.

GlobalRef
PlaceLocalHandle

and some others (Deque?)

Classes that do not specify a parent will have default implementations of 
typeName() equals() toString() hashCode(), perhaps through extending RefI 
although RefI is no longer visible to the x10 programmer.  Another option 
is to simply generate such methods in every generated java class.

Going off on a slight tangent, it would be nice if X10 classes that extend 
java classes have default implementations of typeName and friends provided 
that are similar to the ones in RefI.


And a small status update:  I have almost finished adding throws back into 
the exceptions branch.  Just ironing out some bugs.


Mikio Takeuchi <mik...@gm...> wrote on 07/19/2012 03:37:11 AM:

> From: Mikio Takeuchi <mik...@gm...>
> To: X10 core design <x10...@li...>, 
> Date: 07/19/2012 03:37 AM
> Subject: Re: [X10-core] X10 2.3 exception hierarchy
> 
> Hi, Dave,
> 
> As I told you yesterday in the Sametime chat, there is an issue to
> make CheckedThrowable NativeRep'ed to java.lang.Throwable.
> Since j.l.Throwable is a direct child of j.l.Object, it must be a
> direct child of Any. However, it is a child of x.l.Object in the
> proposed hierarchy.
> 
> I think there are three possible options to implement CheckedThrowable.
> 
> 1. If we can remove Object, it is the best.
> 
> 2. If it (i.e. removal of Object) is not acceptable, if
> CheckedThrowable is a direct child of Any, it is OK.
> 
> 3. If it (i.e. making CheckedThrowable direct child of Any) is not
> acceptable, we need to box CheckedThrowable to something that
> implements x10.core.RefI (to which x.l.Object is NativeRep'ed). As I
> told you, this already happens with x.l.String so the logic is already
> there.
> 
> I wonder the Option 3 is has the least impact to the existing code.
> However if we remove Object, it is the best chance.  Please discuss
> with Vijay and the team and let me know their decision.
> 
> -- Mikio
> 
> 
> 2012/7/19 David Cunningham <dc...@us...>:
> > Just had a discussion with Dave Grove about what to do about 
Exception,
> > Throwable, etc.  It somewhat makes my last email obsolete, so 
I'llresay the
> > relevant parts from scratch.  Also spoke with Vijay who is OK with 
these
> > changes.
> >
> >
> > The simple back story is we want the exception hierarchy in X10 to be
> > symmetrical with Java.  We want best practices for programming with
> > exceptions in X10 to be as similar as possible to Java, up to the 
switch to
> > preferring unchecked exceptions.  We want the names of the classes to 
be
> > sensible as well.
> >
> >
> > Backwards incompatible changes:
> >
> > The first change is that the root (Throwable) is checked rather than
> > unchecked.  We will thus name it CheckedThrowable.  Throwable 
no-longer
> > exists in the language.
> >
> > The second change is the introduction of a new class CheckedException, 
which
> > is the root of all exceptions (including checked ones) that are not 
under
> > Error.
> >
> > The third change is the squashing of RuntimeException and Exception to 
a
> > single class called Exception.  This makes sense because Exception is
> > unchecked in X10 so the distinction between these two classes in Java 
does
> > not exist in X10.
> >
> >
> > Red means checked, green means unchecked
> >
> > Old X10 hierarchy:
> > x10.lang.Throwable
> >         x10.lang.Exception
> >                 x10.lang.RuntimeException
> >                         NPE, CCE, ABIE, SBIE, etc
> >                 x10.io.Exception, etc
> >         x10.lang.Error
> >                 OOME, x10.lang.AssertionError
> >
> >
> > Java hierarchy
> > java.lang.Throwable
> >         java.lang.Exception
> >                 java.lang.RuntimeException
> >                         NPE, CCE, ABIE, SBIE, etc
> >                 java.io.Exception, etc
> >         java.lang.Error
> >                 OOME, java.lang.AssertionError
> >
> >
> > New X10 hierarchy (classes only visible in managed backend are shown 
in
> > parens)
> > x10.lang.CheckedThrowable
> >         x10.lang.CheckedException
> >                 x10.lang.Exception
> >                         NPE, CCE, ABIE, SBIE, etc
> >                         x10.io.IOException, etc
> >                         (Any java class that extends
> > java.lang.RuntimeException, e.g. java.lang.ArrayStoreException)
> >                 (Any  java class that extends java.lang.Exception, 
e.g.
> > java.io.IOException)
> >         x10.lang.Error
> >                 OOME, x10.lang.AssertionError
> >                 (Any java class that extends java.lang.Error, e.g.
> > java.lang.StackOverflowException)
> >
> > The New X10 hierarchy is the same as the Java hierarchy, but with some
> > classes renamed.  This makes interop and java codegen very simple. 
None of
> > the mapped Java classes (e.g. java.lang.Throwable) are accessible via
> > interop, one must use the X10 names.  Exception stack traces printed 
by X10
> > code or by the X10 runtime will use the X10 names.
> >
> >
> >
> >
> > Migration advice and best practices for new X10 exception hierarchy
> >
> > If you prreviously extended Throwable, you should modify your codeto 
extend
> > Exception or Error instead.  The distinction between Exception and 
Error in
> > X10 is the same as that between Exception and Error in java.
> > * Extend Error for internal application errors that should be 
immediately
> > propagated to the user, either to provide useful bug reporting 
information
> > (i.e. the stack trace), or because handling of the error without 
exiting the
> > application is not possible.
> > * Extend Exception when the exception could reasonably be handled by 
the
> > application, e.g. by showing the user a more comprehensible error 
message,
> > or by transparently ignoring a configuration file that could not be 
read.
> >
> > If you were catching Throwable, you should either
> > * catch Exception, if you want to handle the exception without 
propagating
> > it to the user, i.e. let exceptions under Error fall through your 
catch
> > statement
> > * catch Exception and Error (in separate catch blocks), if the catch 
is for
> > preserving the integrity of your state during exceptional control 
flow, e.g.
> > releasing a lock, closing a file, etc.  These exceptions are typically
> > rethrown.
> > * catch CheckedException if you want to catch all checked exceptions 
(e.g.
> > if you call a method that has a throws CheckedException annotation). 
You
> > cannot rethrow such exceptions without a throws annotation on your 
method,
> > but you can package them and rethrow.
> > * catch CheckedThrowable, if you want to catch everything.  You cannot
> > rethrow a caught exception without the throws CheckedThrowable 
annotation on
> > your method.
> >
> > If you were extending RuntimeException, you should extend Exception 
instead.
> >
> > If you were catching RuntimeException, catch Exception instead.
> >
> > Most people should define a new exception by extending Exception.  The 
X10
> > standard library and other libraries from the X10 team will only throw
> > exceptions under Exception.
> >
> > If you want an exception that should bypass most user exception 
handling,
> > extend Error.
> >
> > If for some reason you want a checked exception in X10, extend
> > CheckedException.  Do not extend Throwable, unless for some reason you 
want
> > your exception to be uncaught by user code that catches Error and
> > CheckedException.  Note that closures cannot throw checked exceptions 
or
> > call methods with throws annotations, which limits the usefulness of 
checked
> > exceptions.
> >
> > All exceptions work as expected in an at clause.
> >
> > Any exception that reaches the root of an async and is not under
> > x10.lang.Exception will be wrapped as it is inserted into the
> > MultipleExceptions object.
> >
> > 
> 
------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. 
Discussions
> > will include endpoint security, mobile security and the latest in 
malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > X10-core mailing list
> > X10...@li...
> > https://lists.sourceforge.net/lists/listinfo/x10-core
> >
> 
> 
------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. 
Discussions 
> will include endpoint security, mobile security and the latest in 
malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core
> 

Re: [X10-core] X10 2.3 exception hierarchy

[Mikio T. <mik...@gm...>]

Hi Dave,

Please use the attached slides for the discussion.

-- Mikio

2012/7/19 Mikio Takeuchi <mik...@gm...>:
> Hi, Dave,
>
> As I told you yesterday in the Sametime chat, there is an issue to
> make CheckedThrowable NativeRep'ed to java.lang.Throwable.
> Since j.l.Throwable is a direct child of j.l.Object, it must be a
> direct child of Any. However, it is a child of x.l.Object in the
> proposed hierarchy.
>
> I think there are three possible options to implement CheckedThrowable.
>
> 1. If we can remove Object, it is the best.
>
> 2. If it (i.e. removal of Object) is not acceptable, if
> CheckedThrowable is a direct child of Any, it is OK.
>
> 3. If it (i.e. making CheckedThrowable direct child of Any) is not
> acceptable, we need to box CheckedThrowable to something that
> implements x10.core.RefI (to which x.l.Object is NativeRep'ed). As I
> told you, this already happens with x.l.String so the logic is already
> there.
>
> I wonder the Option 3 is has the least impact to the existing code.
> However if we remove Object, it is the best chance.  Please discuss
> with Vijay and the team and let me know their decision.
>
> -- Mikio
>
>
> 2012/7/19 David Cunningham <dc...@us...>:
>> Just had a discussion with Dave Grove about what to do about Exception,
>> Throwable, etc.  It somewhat makes my last email obsolete, so I'll resay the
>> relevant parts from scratch.  Also spoke with Vijay who is OK with these
>> changes.
>>
>>
>> The simple back story is we want the exception hierarchy in X10 to be
>> symmetrical with Java.  We want best practices for programming with
>> exceptions in X10 to be as similar as possible to Java, up to the switch to
>> preferring unchecked exceptions.  We want the names of the classes to be
>> sensible as well.
>>
>>
>> Backwards incompatible changes:
>>
>> The first change is that the root (Throwable) is checked rather than
>> unchecked.  We will thus name it CheckedThrowable.  Throwable no-longer
>> exists in the language.
>>
>> The second change is the introduction of a new class CheckedException, which
>> is the root of all exceptions (including checked ones) that are not under
>> Error.
>>
>> The third change is the squashing of RuntimeException and Exception to a
>> single class called Exception.  This makes sense because Exception is
>> unchecked in X10 so the distinction between these two classes in Java does
>> not exist in X10.
>>
>>
>> Red means checked, green means unchecked
>>
>> Old X10 hierarchy:
>> x10.lang.Throwable
>>         x10.lang.Exception
>>                 x10.lang.RuntimeException
>>                         NPE, CCE, ABIE, SBIE, etc
>>                 x10.io.Exception, etc
>>         x10.lang.Error
>>                 OOME, x10.lang.AssertionError
>>
>>
>> Java hierarchy
>> java.lang.Throwable
>>         java.lang.Exception
>>                 java.lang.RuntimeException
>>                         NPE, CCE, ABIE, SBIE, etc
>>                 java.io.Exception, etc
>>         java.lang.Error
>>                 OOME, java.lang.AssertionError
>>
>>
>> New X10 hierarchy (classes only visible in managed backend are shown in
>> parens)
>> x10.lang.CheckedThrowable
>>         x10.lang.CheckedException
>>                 x10.lang.Exception
>>                         NPE, CCE, ABIE, SBIE, etc
>>                         x10.io.IOException, etc
>>                         (Any java class that extends
>> java.lang.RuntimeException, e.g. java.lang.ArrayStoreException)
>>                 (Any  java class that extends java.lang.Exception, e.g.
>> java.io.IOException)
>>         x10.lang.Error
>>                 OOME, x10.lang.AssertionError
>>                 (Any java class that extends java.lang.Error, e.g.
>> java.lang.StackOverflowException)
>>
>> The New X10 hierarchy is the same as the Java hierarchy, but with some
>> classes renamed.  This makes interop and java codegen very simple.  None of
>> the mapped Java classes (e.g. java.lang.Throwable) are accessible via
>> interop, one must use the X10 names.  Exception stack traces printed by X10
>> code or by the X10 runtime will use the X10 names.
>>
>>
>>
>>
>> Migration advice and best practices for new X10 exception hierarchy
>>
>> If you prreviously extended Throwable, you should modify your code to extend
>> Exception or Error instead.  The distinction between Exception and Error in
>> X10 is the same as that between Exception and Error in java.
>> * Extend Error for internal application errors that should be immediately
>> propagated to the user, either to provide useful bug reporting information
>> (i.e. the stack trace), or because handling of the error without exiting the
>> application is not possible.
>> * Extend Exception when the exception could reasonably be handled by the
>> application, e.g. by showing the user a more comprehensible error message,
>> or by transparently ignoring a configuration file that could not be read.
>>
>> If you were catching Throwable, you should either
>> * catch Exception, if you want to handle the exception without propagating
>> it to the user, i.e. let exceptions under Error fall through your catch
>> statement
>> * catch Exception and Error (in separate catch blocks), if the catch is for
>> preserving the integrity of your state during exceptional control flow, e.g.
>> releasing a lock, closing a file, etc.  These exceptions are typically
>> rethrown.
>> * catch CheckedException if you want to catch all checked exceptions (e.g.
>> if you call a method that has a throws CheckedException annotation).  You
>> cannot rethrow such exceptions without a throws annotation on your method,
>> but you can package them and rethrow.
>> * catch CheckedThrowable, if you want to catch everything.  You cannot
>> rethrow a caught exception without the throws CheckedThrowable annotation on
>> your method.
>>
>> If you were extending RuntimeException, you should extend Exception instead.
>>
>> If you were catching RuntimeException, catch Exception instead.
>>
>> Most people should define a new exception by extending Exception.  The X10
>> standard library and other libraries from the X10 team will only throw
>> exceptions under Exception.
>>
>> If you want an exception that should bypass most user exception handling,
>> extend Error.
>>
>> If for some reason you want a checked exception in X10, extend
>> CheckedException.  Do not extend Throwable, unless for some reason you want
>> your exception to be uncaught by user code that catches Error and
>> CheckedException.  Note that closures cannot throw checked exceptions or
>> call methods with throws annotations, which limits the usefulness of checked
>> exceptions.
>>
>> All exceptions work as expected in an at clause.
>>
>> Any exception that reaches the root of an async and is not under
>> x10.lang.Exception will be wrapped as it is inserted into the
>> MultipleExceptions object.
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> X10-core mailing list
>> X10...@li...
>> https://lists.sourceforge.net/lists/listinfo/x10-core
>>

Re: [X10-core] X10 2.3 exception hierarchy

[Mikio T. <mik...@gm...>]

Hi, Dave,

As I told you yesterday in the Sametime chat, there is an issue to
make CheckedThrowable NativeRep'ed to java.lang.Throwable.
Since j.l.Throwable is a direct child of j.l.Object, it must be a
direct child of Any. However, it is a child of x.l.Object in the
proposed hierarchy.

I think there are three possible options to implement CheckedThrowable.

1. If we can remove Object, it is the best.

2. If it (i.e. removal of Object) is not acceptable, if
CheckedThrowable is a direct child of Any, it is OK.

3. If it (i.e. making CheckedThrowable direct child of Any) is not
acceptable, we need to box CheckedThrowable to something that
implements x10.core.RefI (to which x.l.Object is NativeRep'ed). As I
told you, this already happens with x.l.String so the logic is already
there.

I wonder the Option 3 is has the least impact to the existing code.
However if we remove Object, it is the best chance.  Please discuss
with Vijay and the team and let me know their decision.

-- Mikio


2012/7/19 David Cunningham <dc...@us...>:
> Just had a discussion with Dave Grove about what to do about Exception,
> Throwable, etc.  It somewhat makes my last email obsolete, so I'll resay the
> relevant parts from scratch.  Also spoke with Vijay who is OK with these
> changes.
>
>
> The simple back story is we want the exception hierarchy in X10 to be
> symmetrical with Java.  We want best practices for programming with
> exceptions in X10 to be as similar as possible to Java, up to the switch to
> preferring unchecked exceptions.  We want the names of the classes to be
> sensible as well.
>
>
> Backwards incompatible changes:
>
> The first change is that the root (Throwable) is checked rather than
> unchecked.  We will thus name it CheckedThrowable.  Throwable no-longer
> exists in the language.
>
> The second change is the introduction of a new class CheckedException, which
> is the root of all exceptions (including checked ones) that are not under
> Error.
>
> The third change is the squashing of RuntimeException and Exception to a
> single class called Exception.  This makes sense because Exception is
> unchecked in X10 so the distinction between these two classes in Java does
> not exist in X10.
>
>
> Red means checked, green means unchecked
>
> Old X10 hierarchy:
> x10.lang.Throwable
>         x10.lang.Exception
>                 x10.lang.RuntimeException
>                         NPE, CCE, ABIE, SBIE, etc
>                 x10.io.Exception, etc
>         x10.lang.Error
>                 OOME, x10.lang.AssertionError
>
>
> Java hierarchy
> java.lang.Throwable
>         java.lang.Exception
>                 java.lang.RuntimeException
>                         NPE, CCE, ABIE, SBIE, etc
>                 java.io.Exception, etc
>         java.lang.Error
>                 OOME, java.lang.AssertionError
>
>
> New X10 hierarchy (classes only visible in managed backend are shown in
> parens)
> x10.lang.CheckedThrowable
>         x10.lang.CheckedException
>                 x10.lang.Exception
>                         NPE, CCE, ABIE, SBIE, etc
>                         x10.io.IOException, etc
>                         (Any java class that extends
> java.lang.RuntimeException, e.g. java.lang.ArrayStoreException)
>                 (Any  java class that extends java.lang.Exception, e.g.
> java.io.IOException)
>         x10.lang.Error
>                 OOME, x10.lang.AssertionError
>                 (Any java class that extends java.lang.Error, e.g.
> java.lang.StackOverflowException)
>
> The New X10 hierarchy is the same as the Java hierarchy, but with some
> classes renamed.  This makes interop and java codegen very simple.  None of
> the mapped Java classes (e.g. java.lang.Throwable) are accessible via
> interop, one must use the X10 names.  Exception stack traces printed by X10
> code or by the X10 runtime will use the X10 names.
>
>
>
>
> Migration advice and best practices for new X10 exception hierarchy
>
> If you prreviously extended Throwable, you should modify your code to extend
> Exception or Error instead.  The distinction between Exception and Error in
> X10 is the same as that between Exception and Error in java.
> * Extend Error for internal application errors that should be immediately
> propagated to the user, either to provide useful bug reporting information
> (i.e. the stack trace), or because handling of the error without exiting the
> application is not possible.
> * Extend Exception when the exception could reasonably be handled by the
> application, e.g. by showing the user a more comprehensible error message,
> or by transparently ignoring a configuration file that could not be read.
>
> If you were catching Throwable, you should either
> * catch Exception, if you want to handle the exception without propagating
> it to the user, i.e. let exceptions under Error fall through your catch
> statement
> * catch Exception and Error (in separate catch blocks), if the catch is for
> preserving the integrity of your state during exceptional control flow, e.g.
> releasing a lock, closing a file, etc.  These exceptions are typically
> rethrown.
> * catch CheckedException if you want to catch all checked exceptions (e.g.
> if you call a method that has a throws CheckedException annotation).  You
> cannot rethrow such exceptions without a throws annotation on your method,
> but you can package them and rethrow.
> * catch CheckedThrowable, if you want to catch everything.  You cannot
> rethrow a caught exception without the throws CheckedThrowable annotation on
> your method.
>
> If you were extending RuntimeException, you should extend Exception instead.
>
> If you were catching RuntimeException, catch Exception instead.
>
> Most people should define a new exception by extending Exception.  The X10
> standard library and other libraries from the X10 team will only throw
> exceptions under Exception.
>
> If you want an exception that should bypass most user exception handling,
> extend Error.
>
> If for some reason you want a checked exception in X10, extend
> CheckedException.  Do not extend Throwable, unless for some reason you want
> your exception to be uncaught by user code that catches Error and
> CheckedException.  Note that closures cannot throw checked exceptions or
> call methods with throws annotations, which limits the usefulness of checked
> exceptions.
>
> All exceptions work as expected in an at clause.
>
> Any exception that reaches the root of an async and is not under
> x10.lang.Exception will be wrapped as it is inserted into the
> MultipleExceptions object.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core
>

[X10-core] X10 2.3 exception hierarchy

[David C. <dc...@us...>]

Just had a discussion with Dave Grove about what to do about Exception, 
Throwable, etc.  It somewhat makes my last email obsolete, so I'll resay 
the relevant parts from scratch.  Also spoke with Vijay who is OK with 
these changes.


The simple back story is we want the exception hierarchy in X10 to be 
symmetrical with Java.  We want best practices for programming with 
exceptions in X10 to be as similar as possible to Java, up to the switch 
to preferring unchecked exceptions.  We want the names of the classes to 
be sensible as well.


Backwards incompatible changes:

The first change is that the root (Throwable) is checked rather than 
unchecked.  We will thus name it CheckedThrowable.  Throwable no-longer 
exists in the language.

The second change is the introduction of a new class CheckedException, 
which is the root of all exceptions (including checked ones) that are not 
under Error.

The third change is the squashing of RuntimeException and Exception to a 
single class called Exception.  This makes sense because Exception is 
unchecked in X10 so the distinction between these two classes in Java does 
not exist in X10.


Red means checked, green means unchecked

Old X10 hierarchy:
x10.lang.Throwable
        x10.lang.Exception
                x10.lang.RuntimeException
                        NPE, CCE, ABIE, SBIE, etc
                x10.io.Exception, etc
        x10.lang.Error
                OOME, x10.lang.AssertionError


Java hierarchy
java.lang.Throwable
        java.lang.Exception
                java.lang.RuntimeException
                        NPE, CCE, ABIE, SBIE, etc
                java.io.Exception, etc
        java.lang.Error
                OOME, java.lang.AssertionError


New X10 hierarchy (classes only visible in managed backend are shown in 
parens)
x10.lang.CheckedThrowable
        x10.lang.CheckedException
                x10.lang.Exception
                        NPE, CCE, ABIE, SBIE, etc
                        x10.io.IOException, etc
                        (Any java class that extends 
java.lang.RuntimeException, e.g. java.lang.ArrayStoreException)
                (Any  java class that extends java.lang.Exception, e.g. 
java.io.IOException)
        x10.lang.Error
                OOME, x10.lang.AssertionError
                (Any java class that extends java.lang.Error, e.g. 
java.lang.StackOverflowException)

The New X10 hierarchy is the same as the Java hierarchy, but with some 
classes renamed.  This makes interop and java codegen very simple.  None 
of the mapped Java classes (e.g. java.lang.Throwable) are accessible via 
interop, one must use the X10 names.  Exception stack traces printed by 
X10 code or by the X10 runtime will use the X10 names.




Migration advice and best practices for new X10 exception hierarchy

If you prreviously extended Throwable, you should modify your code to 
extend Exception or Error instead.  The distinction between Exception and 
Error in X10 is the same as that between Exception and Error in java.
* Extend Error for internal application errors that should be immediately 
propagated to the user, either to provide useful bug reporting information 
(i.e. the stack trace), or because handling of the error without exiting 
the application is not possible.
* Extend Exception when the exception could reasonably be handled by the 
application, e.g. by showing the user a more comprehensible error message, 
or by transparently ignoring a configuration file that could not be read.

If you were catching Throwable, you should either
* catch Exception, if you want to handle the exception without propagating 
it to the user, i.e. let exceptions under Error fall through your catch 
statement
* catch Exception and Error (in separate catch blocks), if the catch is 
for preserving the integrity of your state during exceptional control 
flow, e.g. releasing a lock, closing a file, etc.  These exceptions are 
typically rethrown.
* catch CheckedException if you want to catch all checked exceptions (e.g. 
if you call a method that has a throws CheckedException annotation).  You 
cannot rethrow such exceptions without a throws annotation on your method, 
but you can package them and rethrow.
* catch CheckedThrowable, if you want to catch everything.  You cannot 
rethrow a caught exception without the throws CheckedThrowable annotation 
on your method.

If you were extending RuntimeException, you should extend Exception 
instead.

If you were catching RuntimeException, catch Exception instead.

Most people should define a new exception by extending Exception.  The X10 
standard library and other libraries from the X10 team will only throw 
exceptions under Exception.

If you want an exception that should bypass most user exception handling, 
extend Error.

If for some reason you want a checked exception in X10, extend 
CheckedException.  Do not extend Throwable, unless for some reason you 
want your exception to be uncaught by user code that catches Error and 
CheckedException.  Note that closures cannot throw checked exceptions or 
call methods with throws annotations, which limits the usefulness of 
checked exceptions.

All exceptions work as expected in an at clause.

Any exception that reaches the root of an async and is not under 
x10.lang.Exception will be wrapped as it is inserted into the 
MultipleExceptions object.