You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(83) |
Aug
(46) |
Sep
(87) |
Oct
(77) |
Nov
(83) |
Dec
(53) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(121) |
Feb
(15) |
Mar
(133) |
Apr
(125) |
May
(104) |
Jun
(20) |
Jul
(21) |
Aug
(8) |
Sep
(46) |
Oct
(51) |
Nov
(37) |
Dec
(21) |
2011 |
Jan
(28) |
Feb
(12) |
Mar
(36) |
Apr
(18) |
May
(10) |
Jun
(18) |
Jul
(32) |
Aug
(16) |
Sep
(12) |
Oct
|
Nov
|
Dec
(4) |
2012 |
Jan
(1) |
Feb
(5) |
Mar
(1) |
Apr
(4) |
May
(3) |
Jun
(3) |
Jul
(19) |
Aug
(5) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
(4) |
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Josh M. <jos...@an...> - 2013-06-07 11:20:07
|
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/ |
From: David P G. <gr...@us...> - 2013-05-07 12:55:55
|
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 |
From: David P G. <gr...@us...> - 2013-05-04 15:19:41
|
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 |
From: David P G. <gr...@us...> - 2013-03-19 01:48:20
|
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 |
From: Josh M. <jos...@an...> - 2012-12-12 12:17:22
|
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 > |
From: Olivier T. <ta...@us...> - 2012-12-10 21:32:14
|
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 |
From: David C. <dc...@us...> - 2012-12-10 17:08:34
|
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 |
From: Josh M. <jos...@an...> - 2012-12-10 11:11:30
|
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 |
From: David P G. <gr...@us...> - 2012-10-11 21:11:39
|
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 |
From: David C. <dc...@us...> - 2012-10-10 17:29:26
|
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 |
From: David P G. <gr...@us...> - 2012-10-10 12:13:02
|
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 |
From: Bard B. <bar...@gm...> - 2012-10-10 01:01:06
|
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 > > |
From: Vijay S. <vi...@sa...> - 2012-10-10 00:03:15
|
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 |
From: David C. <dc...@us...> - 2012-10-09 23:46:14
|
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. |
From: Josh M. <jos...@an...> - 2012-09-01 10:50:22
|
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 |
From: David P G. <gr...@us...> - 2012-08-31 14:50:01
|
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 |
From: David C. <dc...@us...> - 2012-08-30 19:46:06
|
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 |
From: Mikio T. <mik...@gm...> - 2012-08-30 13:27:43
|
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 |
From: Vijay S. <vi...@sa...> - 2012-08-30 12:32:52
|
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 |
From: David C. <dc...@us...> - 2012-08-30 03:25:12
|
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. |
From: Mikio T. <mik...@gm...> - 2012-07-20 03:52:54
|
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 > |
From: David C. <dc...@us...> - 2012-07-19 20:52:06
|
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 > |
From: Mikio T. <mik...@gm...> - 2012-07-19 08:06:29
|
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 >> |
From: Mikio T. <mik...@gm...> - 2012-07-19 07:37:20
|
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 > |
From: David C. <dc...@us...> - 2012-07-18 23:58:01
|
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. |