From: David P G. <gr...@us...> - 2004-08-17 23:47:43
|
This email is mainly reporting some in-person conversations that happened last week when Steve Blackburn was visiting the US. I'd like to reach a final consensus on this in the next few days so we can go ahead and start making the changes. There is a proposal to move all of the "magic" currently mostly found in various classes in com.ibm.JikesRVM to their own set of packages. This will (1) support some portability goals for MMTk and (2) enable a more precise definition of the 'magic interface' and possibly separate those aspects that are more vm-independent from those that are more Jikes RVM specific. At this level I think this is fairly uncontroversial and unlikely to be that disruptive for users of the system. The current proposal (as I recall it) is to have at least 3 new magic packages: <prefix>.unboxed (VM_Address, VM_Word, etc). <prefix>.pragmas (VM_PragmaUninterruptible, VM_PragmaInline, etc. and most likely VM_Uninterruptible as well) <prefix>.functions (Steve, did we have a better name? for the misc static functions now in VM_Magic). The <prefix> is still an open issue. magic? vmmagic? org.magic? org.vmmagic? com.ibm.JikesRVM.magic? A related open issue is whether or not we should remove the VM_ prefix from classes as we put them into these magic packages. On the one hand, this is "nice" and makes the resulting class names less Jikes RVM specific (possibly good for MMTk), on the other hand it is a somewhat massive rename (impacts a large number of files) and thus could be fairly disruptive for people who maintain patches/local cvs with differences from the cvs head. I have a personal opinion of course, but am holding back to avoid biasing the discussion ;-) On this second point, I'd really like to hear from people not on the core team who maintain largish deltas from the system. It seems to me that they are the most likely to be impacted (or not) by this kind of wide-spread renaming. --dave |
From: Ewout P. <ew...@pr...> - 2004-08-18 08:42:40
|
David P Grove wrote: Hi Dave and others, If this will help to make MMTK a bit less dependent on JikesRVM (so I can use it in JNode also) that would be very great! For that I suggest to make an RVM indepent prefix like org.vmmagic or something. Ewout > > This email is mainly reporting some in-person conversations that > happened last week when Steve Blackburn was visiting the US. I'd like > to reach a final consensus on this in the next few days so we can go > ahead and start making the changes. > > There is a proposal to move all of the "magic" currently mostly found > in various classes in com.ibm.JikesRVM to their own set of packages. > This will (1) support some portability goals for MMTk and (2) enable > a more precise definition of the 'magic interface' and possibly > separate those aspects that are more vm-independent from those that > are more Jikes RVM specific. At this level I think this is fairly > uncontroversial and unlikely to be that disruptive for users of the > system. > > The current proposal (as I recall it) is to have at least 3 new magic > packages: > <prefix>.unboxed (VM_Address, VM_Word, etc). > <prefix>.pragmas (VM_PragmaUninterruptible, VM_PragmaInline, > etc. and most likely VM_Uninterruptible as well) > <prefix>.functions (Steve, did we have a better name? for the > misc static functions now in VM_Magic). > > The <prefix> is still an open issue. magic? vmmagic? org.magic? > org.vmmagic? com.ibm.JikesRVM.magic? > > A related open issue is whether or not we should remove the VM_ prefix > from classes as we put them into these magic packages. On the one > hand, this is "nice" and makes the resulting class names less Jikes > RVM specific (possibly good for MMTk), on the other hand it is a > somewhat massive rename (impacts a large number of files) and thus > could be fairly disruptive for people who maintain patches/local cvs > with differences from the cvs head. > > I have a personal opinion of course, but am holding back to avoid > biasing the discussion ;-) On this second point, I'd really like to > hear from people not on the core team who maintain largish deltas from > the system. It seems to me that they are the most likely to be > impacted (or not) by this kind of wide-spread renaming. > > --dave |
From: Ian R. <ir...@cs...> - 2004-08-18 11:03:29
|
Hi Ewout, I've been helping to manage a project porting the Jikes RVM onto a nanokernel and the JNode version of classpath. The project is with an advanced masters student and we have had some good initial results although the complete system isn't yet working (more work on the class libraries needed). I will make sure the work is available when complete and I have some interest in writing a paper about it (my research work is assessed by weighing the papers I write). Let me know if you'd like more information. Regards, Ian Rogers Ewout Prangsma wrote: > David P Grove wrote: > > Hi Dave and others, > > If this will help to make MMTK a bit less dependent on JikesRVM (so I > can use it in JNode also) that would be very great! > > For that I suggest to make an RVM indepent prefix like org.vmmagic or > something. > > Ewout > >> >> This email is mainly reporting some in-person conversations that >> happened last week when Steve Blackburn was visiting the US. I'd >> like to reach a final consensus on this in the next few days so we >> can go ahead and start making the changes. >> >> There is a proposal to move all of the "magic" currently mostly found >> in various classes in com.ibm.JikesRVM to their own set of packages. >> This will (1) support some portability goals for MMTk and (2) enable >> a more precise definition of the 'magic interface' and possibly >> separate those aspects that are more vm-independent from those that >> are more Jikes RVM specific. At this level I think this is fairly >> uncontroversial and unlikely to be that disruptive for users of the >> system. >> >> The current proposal (as I recall it) is to have at least 3 new magic >> packages: >> <prefix>.unboxed (VM_Address, VM_Word, etc). >> <prefix>.pragmas (VM_PragmaUninterruptible, VM_PragmaInline, >> etc. and most likely VM_Uninterruptible as well) >> <prefix>.functions (Steve, did we have a better name? for the >> misc static functions now in VM_Magic). >> >> The <prefix> is still an open issue. magic? vmmagic? org.magic? >> org.vmmagic? com.ibm.JikesRVM.magic? >> >> A related open issue is whether or not we should remove the VM_ >> prefix from classes as we put them into these magic packages. On the >> one hand, this is "nice" and makes the resulting class names less >> Jikes RVM specific (possibly good for MMTk), on the other hand it is >> a somewhat massive rename (impacts a large number of files) and thus >> could be fairly disruptive for people who maintain patches/local cvs >> with differences from the cvs head. >> >> I have a personal opinion of course, but am holding back to avoid >> biasing the discussion ;-) On this second point, I'd really like to >> hear from people not on the core team who maintain largish deltas >> from the system. It seems to me that they are the most likely to be >> impacted (or not) by this kind of wide-spread renaming. >> >> --dave > > |
From: Ewout P. <ew...@pr...> - 2004-08-18 16:50:24
|
Quoting Ian Rogers <ir...@cs...>: Ian, Please tell me more! Ewout > Hi Ewout, > > I've been helping to manage a project porting the Jikes RVM onto a > nanokernel and the JNode version of classpath. The project is with an > advanced masters student and we have had some good initial results > although the complete system isn't yet working (more work on the class > libraries needed). I will make sure the work is available when complete > and I have some interest in writing a paper about it (my research work > is assessed by weighing the papers I write). Let me know if you'd like > more information. > > Regards, > > Ian Rogers > > Ewout Prangsma wrote: > > > David P Grove wrote: > > > > Hi Dave and others, > > > > If this will help to make MMTK a bit less dependent on JikesRVM (so I > > can use it in JNode also) that would be very great! > > > > For that I suggest to make an RVM indepent prefix like org.vmmagic or > > something. > > > > Ewout > > > >> > >> This email is mainly reporting some in-person conversations that > >> happened last week when Steve Blackburn was visiting the US. I'd > >> like to reach a final consensus on this in the next few days so we > >> can go ahead and start making the changes. > >> > >> There is a proposal to move all of the "magic" currently mostly found > >> in various classes in com.ibm.JikesRVM to their own set of packages. > >> This will (1) support some portability goals for MMTk and (2) enable > >> a more precise definition of the 'magic interface' and possibly > >> separate those aspects that are more vm-independent from those that > >> are more Jikes RVM specific. At this level I think this is fairly > >> uncontroversial and unlikely to be that disruptive for users of the > >> system. > >> > >> The current proposal (as I recall it) is to have at least 3 new magic > >> packages: > >> <prefix>.unboxed (VM_Address, VM_Word, etc). > >> <prefix>.pragmas (VM_PragmaUninterruptible, VM_PragmaInline, > >> etc. and most likely VM_Uninterruptible as well) > >> <prefix>.functions (Steve, did we have a better name? for the > >> misc static functions now in VM_Magic). > >> > >> The <prefix> is still an open issue. magic? vmmagic? org.magic? > >> org.vmmagic? com.ibm.JikesRVM.magic? > >> > >> A related open issue is whether or not we should remove the VM_ > >> prefix from classes as we put them into these magic packages. On the > >> one hand, this is "nice" and makes the resulting class names less > >> Jikes RVM specific (possibly good for MMTk), on the other hand it is > >> a somewhat massive rename (impacts a large number of files) and thus > >> could be fairly disruptive for people who maintain patches/local cvs > >> with differences from the cvs head. > >> > >> I have a personal opinion of course, but am holding back to avoid > >> biasing the discussion ;-) On this second point, I'd really like to > >> hear from people not on the core team who maintain largish deltas > >> from the system. It seems to me that they are the most likely to be > >> impacted (or not) by this kind of wide-spread renaming. > >> > >> --dave > > > > > > _______________________________________________ > Jikesrvm-core mailing list > Jik...@os... > http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core > |
From: Ian R. <ir...@cs...> - 2004-08-18 17:24:45
|
Hi Ewout, the plan with a couple of the things we're up to here at Manchester using the Jikes RVM as part of the JAMAICA project has been to do some research and then release the code and a paper when we have something ready. We've been very interested in the Jikes RVM for a while and we have also been interested more recently with JNode. So we proposed an MSc project to tie the two things together, although from what I can see from your postings the way we've attempted it is different. George (the MSc student - I have to apologize for not being able to properly pronounce his Greek name) has modified the Jikes RVM build process so that it has an extra phase to build a nanokernel similar (and in part based on) the JNode nanokernel. This nanokernel performs the same job as the bootImageRunner but on bare x86 hardware. So we have a working nanokernel, and we can process interrupts, handle memory faults and the like. The next big job comes with device drivers and classpath. The JNode classpath currently is different from the stock classpath that the Jikes RVM comes with. George has been working on getting the JNode classpath and libraries to build with the Jikes RVM but this work is incomplete. George is currently concentrating on writing his MSc dissertation, whilst I'm concentrating on getting some results and writing a paper on something you will probably also be interested in we're calling PearColator (a PPC DBT written in Java using the Jikes RVM opt compiler). I'm hoping to get what I'm doing finished soon and then to concentrate on helping with George's work so we can get to a command prompt. It never rains but pours, I'm also helping with Ming's ARM backend for the Jikes RVM, a modified adaptive compilation system for the Jikes RVM that uses genetic algorithms and random-mutation hill climbing and (my own work) an optimization phase to do loop parallelization and hopefully to take advantage of the port we're doing of the Jikes RVM to our chip multi-processor (with light-weight threading support and cores executing multiple contexts) called JAMAICA. The hope with the JNode work is that we could tie it back with the JNode project and also that we could use it as a basis for Operating System labs here. Sorry for not communicating more earlier. As you can imagine we're quite busy and nothing is quite complete yet. George and I are both happy to speak to further. Apologies for a long off-topic post. Kind regards, Ian Rogers Ewout Prangsma wrote: >Quoting Ian Rogers <ir...@cs...>: > >Ian, > >Please tell me more! > >Ewout > > > >>Hi Ewout, >> >>I've been helping to manage a project porting the Jikes RVM onto a >>nanokernel and the JNode version of classpath. The project is with an >>advanced masters student and we have had some good initial results >>although the complete system isn't yet working (more work on the class >>libraries needed). I will make sure the work is available when complete >>and I have some interest in writing a paper about it (my research work >>is assessed by weighing the papers I write). Let me know if you'd like >>more information. >> >>Regards, >> >>Ian Rogers >> >>Ewout Prangsma wrote: >> >> >> >>>David P Grove wrote: >>> >>>Hi Dave and others, >>> >>>If this will help to make MMTK a bit less dependent on JikesRVM (so I >>>can use it in JNode also) that would be very great! >>> >>>For that I suggest to make an RVM indepent prefix like org.vmmagic or >>>something. >>> >>>Ewout >>> >>> >>> >>>>This email is mainly reporting some in-person conversations that >>>>happened last week when Steve Blackburn was visiting the US. I'd >>>>like to reach a final consensus on this in the next few days so we >>>>can go ahead and start making the changes. >>>> >>>>There is a proposal to move all of the "magic" currently mostly found >>>>in various classes in com.ibm.JikesRVM to their own set of packages. >>>> This will (1) support some portability goals for MMTk and (2) enable >>>>a more precise definition of the 'magic interface' and possibly >>>>separate those aspects that are more vm-independent from those that >>>>are more Jikes RVM specific. At this level I think this is fairly >>>>uncontroversial and unlikely to be that disruptive for users of the >>>>system. >>>> >>>>The current proposal (as I recall it) is to have at least 3 new magic >>>>packages: >>>> <prefix>.unboxed (VM_Address, VM_Word, etc). >>>> <prefix>.pragmas (VM_PragmaUninterruptible, VM_PragmaInline, >>>>etc. and most likely VM_Uninterruptible as well) >>>> <prefix>.functions (Steve, did we have a better name? for the >>>>misc static functions now in VM_Magic). >>>> >>>>The <prefix> is still an open issue. magic? vmmagic? org.magic? >>>> org.vmmagic? com.ibm.JikesRVM.magic? >>>> >>>>A related open issue is whether or not we should remove the VM_ >>>>prefix from classes as we put them into these magic packages. On the >>>>one hand, this is "nice" and makes the resulting class names less >>>>Jikes RVM specific (possibly good for MMTk), on the other hand it is >>>>a somewhat massive rename (impacts a large number of files) and thus >>>>could be fairly disruptive for people who maintain patches/local cvs >>>>with differences from the cvs head. >>>> >>>>I have a personal opinion of course, but am holding back to avoid >>>>biasing the discussion ;-) On this second point, I'd really like to >>>>hear from people not on the core team who maintain largish deltas >>>>from the system. It seems to me that they are the most likely to be >>>>impacted (or not) by this kind of wide-spread renaming. >>>> >>>>--dave >>>> >>>> >>> >>> >>_______________________________________________ >>Jikesrvm-core mailing list >>Jik...@os... >>http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core >> >> >> > > > >_______________________________________________ >Jikesrvm-core mailing list >Jik...@os... >http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core > > |
From: Steve B. <Ste...@an...> - 2004-08-30 15:26:28
|
Hi all, Having let everyone think about it for a while, I'd like to follow up on Dave's email and make a proposal regarding the cleanup of magic. If there is approval, I'd like to act this week. I propose a comprehensive cleanup (details below). I'll quickly argue why I think we should go for the comprehensive rather than minimalist approach: + The final outcome is nicer . Rationalization of the existing magic will be syntactically cleaner . We can introduce a new "Reference" type, solving some problems . We get greater portability . Teasing the magic out as a vm-neutral entity is appealing - It generates more upheaval and change . I believe MMTk code is most impacted . MMTk is currently undergoing major change---let's seize the moment - Someone has to do the work . I am happy to do it (with Daniel's help ;-) The proposal: o Shift all vm-neutral magic into a new package: org.vmmagic org.vmmagic.unboxed (unboxed types such as Address & Word) org.vmmagic.pragma (pragmas such as PragmaInline) o Rationalize memory access routines as instance methods on Address: address.load<Type>() address.store<Type>(value) address.prepare<Type>() address.attempt<Type>(old, new) o Introduce a new unboxed type: Reference Reference is used to abstractly refer to objects in a vm-neutral way. In principle, a Reference could be a handle. We currently have such a distinction in MMTk, but it is not reflected in the types (we use VM_Address for both addresses and references). o Retain any JikesRVM-specific magic in its current place I think that's about it. Cheers, --Steve |
From: David P G. <gr...@us...> - 2004-08-30 15:41:41
|
I'd suggest that we do the addition of the Reference type as a separable workitem. The initial round of cleanup is more or less a large collection of re-names and other "trivial" transforms. Adding Reference is going to be a little less trivial. --dave |
From: Eliot M. <mo...@cs...> - 2004-08-30 18:20:55
|
A warning: Java.lang.ref.Reference exists, so using the exact name "Reference" may be confusing or problematic. (I am not objecting to the idea, only the name :-). -- E |
From: David P G. <gr...@us...> - 2004-08-31 14:48:29
|
yes, this is an issue. The best I could come up with on the ride in this morning is "Pointer" or possibly OOP, although that is a little more obscure. I think we should avoid overloading Reference; especially as parts of the GC system have to deal with java.lang.ref.Reference processing... --dave jik...@ww... wrote on 08/30/2004 11:20:48 AM: > A warning: Java.lang.ref.Reference exists, so using the exact name > "Reference" may be confusing or problematic. (I am not objecting to the > idea, only the name :-). > > -- E |
From: Steve B. <Ste...@an...> - 2004-08-31 14:52:27
|
I agree entirely with Dave & Eliot. Daniel and I struggled to come up with good names. Like Dave, I thought of "Pointer", not ideal though... Cheers, --Steve |
From: Perry C. <per...@us...> - 2004-08-31 20:01:31
|
Yes, Reference is problematic. And I am not sure what OOP is supposed to be except object-oriented programming? ;-) Pointer is correct but not precise enough since this is almost the same as Address. I propose ObjectPointer which indicates it is a pointer that refers to an object in the canonical manner (handles, 8 bytes from one end or the other, whatever the norm is). Of course, it is a tad verbose. Perry |
From: Eliot M. <mo...@cs...> - 2004-09-01 03:55:40
|
"oop" comes from Smalltalk -- and maybe somewhere else before that. I think it was intended to be short for "object-oriented pointer" .... E |
From: Steve B. <Ste...@an...> - 2004-09-02 15:21:32
|
Hi all, Daniel and I (mostly Daniel) have produced a draft implementation of the new magic. It is close to being complete and will run an intel BaseAdaptiveSemiSpace build. We need to finish of PowerPC and the transition from static calls on VM_Magic to instance calls on Address (we've only just started that transition). We hope to complete it all tommorrow. This is a great stage for people to provide feedback. Cosmetic changes are easy to make at this point ;-) Most such changes can be done trivially with a search and replace on the patch file. So we encourage you all to take a look at what we've done and send feedback to this list. To check it out, either: a) get this morning's cvs head and apply the following patch: http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic.patch.gz % cd $RVM_ROOT/rvm % zcat ../vmmagic.patch.gz | patch -p0 or, b) untar the following tarball http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic.tgz For a good example of the changes, check out: rvm/src/vm/memoryManagers/JMTk/utility/SegregatedFreeList.java To see the magic classes, look in: rvm/src/vm/runtime/vmmagic Here's a short summary: o created org.vmmagic.pragma and org.vmmagic.unboxed packages for pragmas and unboxed types (address et al) respectively. o *template* implementations will probably be placed in cvs somewhere like org/vmmagic/*. For now we only have *concrete* implementations in src/vm/runtime/vmmagic/* o dropped the VM_ prefix o "Pragma" is now a suffix (consistent with "Exception") o values are loaded and stored via instances methods on the Address type: addr.loadWord(), addr.loadInt() (we have only just started transitioning the code to using this idiom). o we have added an "offset" overload: addr.loadWord(offset) - have not yet implemented the ObjectReference type, but this is something that we think is a high priority---this view was reinforced as we cleaned the code up and discovered how many inadvertant VM_Address -> Object upcasts there were, among other problems! Unless there are objections, I would like to commit this in the next day or so. I think it is a good step forward for Jikes RVM and well worth the pain we will experince over the short period of transition. Cheers, --Steve |
From: David P G. <gr...@us...> - 2004-09-02 16:00:13
|
Some quick comments: I think it would be better to locate these files at vm/vmmagic instead of burying them in the runtime directory. This is important enough to get its own "top-level" directory in Jikes RVM. What do you think of adding an Address.fromObject(obj) static method to Address class to replace the current VM_Magic.objectAsAddress(obj) idiom? My initial guess is that this would be a nicer way to do it. Long term, I think it probably makes sense to switch to template generation for the Address/Word/etc classes. There is too much stuff that is copied and pasted between these files that needs to be kept in synch. I've been meaning to do this for a while, and moving lots of functionality to instance methods of these classes makes the problem much worse. I preferred having the Pragma at the beginning of the exception name, but don't care that much. --dave |
From: Daniel F. <zyr...@zy...> - 2004-09-02 16:32:40
|
Dave, > I think it would be better to locate these files at vm/vmmagic instead of burying them in the runtime directory. This is important enough to get its own "top-level" directory in Jikes RVM. Good idea. > What do you think of adding an Address.fromObject(obj) static method to Address class to replace the current VM_Magic.objectAsAddress(obj) idiom? My initial guess is that this would be a nicer way to do it. I think that it might make sense to do this as a Jikes specific extension. I don't think it makes sense for such a method to be part of the general org.vmmagic Address type though; when using those general interfaces you should be dealing with an ObjectReference type. > Long term, I think it probably makes sense to switch to template generation for the Address/Word/etc classes. There is too much stuff that is copied and pasted between these files that needs to be kept in synch. I've been meaning to do this for a while, and moving lots of functionality to instance methods of these classes makes the problem much worse. Agreed. On the plus side moving these methods to Address will allow VM_Magic to be a lot cleaner. Thanks for the comments, Daniel. |
From: David P G. <gr...@us...> - 2004-09-02 16:44:38
|
I think if you step back and think of org.vmmagic as something that is usable outside of MMTk, then this actually makes a lot of sense. How do you create an Address or a Word from an Object? There has to be some coercion operation and it makes a lot of sense for that to be a method of Address as opposed to an external method. I suppose in the interest of type checking we could force people to do the following double jump: Address.from(ObjectReference.from(obj)) I still think it makes sense to have some operation on Address that coerces a non-primitive value to an Address, otherwise where do these things come from? --dave > > > What do you think of adding an Address.fromObject(obj) static method to Address > > class to replace the current VM_Magic.objectAsAddress(obj) idiom? My initial guess > > is that this would be a nicer way to do it. > > I think that it might make sense to do this as a Jikes specific extension. I don't > think it makes sense for such a method to be part of the general org.vmmagic > Address type though; when using those general interfaces you should be dealing with > an ObjectReference type. |
From: Daniel F. <zyr...@zy...> - 2004-09-02 17:02:59
|
Dave, My only concern with being able to have any client create Address/ObjectReference objects from arbitrary objects is that it appears to makes an assumption that the operations work on all instances of Object (pure Java in Java). While the VM can introduce a runtime check to ensure that the conversion from Object to Address or ObjectReference is valid, I am not sure I like the idea. In Jikes as all Objects have a corresponding ObjectReference this issue does not arise. The design of the general vmmagic classes was to delegate this responsibility and have objects fetched by some other coupling with the VM. This other coupling can then control what is given away as an ObjectReference. In MMTk this is the MM/VM Interface. However, I don't have a particularly strong view about this... Cheers, Daniel. |
From: Steve B. <Ste...@an...> - 2004-09-03 18:43:42
|
Hi again, We are *very* near to completing the job. PowerPC and Intel are working under BaseBase and BaseAdaptive. Patches and a tarball are below for those interested. I believe that all that remains are some opt compiler problems that I have not had a chance to look at yet. Unfortunately Daniel is leaving for an internship soon (in a few hours). If anyone is able to take a quick look at the opt compiler problem we're facing I'd be most appreciative. It may be quite trivial. To grab the system, either: a) get cvs with timestamp "2004/09/02 20:03:43 UTC" and apply the following patch: http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic.patch.gz % cd $RVM_ROOT/rvm % zcat ../vmmagic.patch.gz | patch -p0 or, b) untar the following tarball http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic.tgz I see two problems. a) FastAdaptive builds die in the opt compiler with a class cast exception. This is trivial to see: just do a FastAdaptive build. b) There is a problem with the use of the new form of the store magic that shows up only on line 182 of runtime/VM_Memory.java, and is only in evidence in a BaseAdaptive build (the system suffers some form of memory corruption when running javac). This is the only line in the entire system that I have not convereted over to use the new magic. If anyone could take a moment to look at either of these I'd be most appreciative. Anyway, the good news is that the massive job is very nearly done. Good night, --Steve |
From: Ewout P. <ew...@pr...> - 2004-09-03 18:52:12
|
Steve Blackburn wrote: Hi Steve, I took at loot at the snapshot and i have a question. Do the pragmaexceptions really need to be dependent on jikesrvm packages? If so this reduces the use of a seperate (org.vmmagic) package quite a bit. Ewout > Hi again, > > We are *very* near to completing the job. PowerPC and Intel are working > under BaseBase and BaseAdaptive. Patches and a tarball are below for > those interested. > > I believe that all that remains are some opt compiler problems that I > have not had a chance to look at yet. Unfortunately Daniel is leaving > for an internship soon (in a few hours). If anyone is able to take a > quick look at the opt compiler problem we're facing I'd be most > appreciative. It may be quite trivial. > > To grab the system, either: > > a) get cvs with timestamp "2004/09/02 20:03:43 UTC" and apply the > following patch: > http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic.patch.gz > > % cd $RVM_ROOT/rvm > % zcat ../vmmagic.patch.gz | patch -p0 > > or, > > b) untar the following tarball > http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic.tgz > > I see two problems. > > a) FastAdaptive builds die in the opt compiler with a class cast > exception. This is trivial to see: just do a FastAdaptive build. > > b) There is a problem with the use of the new form of the store > magic that shows up only on line 182 of runtime/VM_Memory.java, > and is only in evidence in a BaseAdaptive build (the system > suffers some form of memory corruption when running javac). This > is the only line in the entire system that I have not convereted > over to use the new magic. > > If anyone could take a moment to look at either of these I'd be most > appreciative. > > Anyway, the good news is that the massive job is very nearly done. > > Good night, > > --Steve > > _______________________________________________ > Jikesrvm-core mailing list > Jik...@os... > http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core |
From: Steve B. <Ste...@an...> - 2004-09-03 19:00:14
|
> Do the pragmaexceptions really need to be dependent on jikesrvm > packages? If so this reduces the use of a seperate (org.vmmagic) package > quite a bit. No they should not be. The model we have is that the vmmagic classes come in two forms, abstract (stubs) and concrete (fleshed out). The snapshot currently only has the concrete, which has Jikes RVM specific stuff in it like import com.ibm.JikesRVM.classloader.* We will produce the abstract ones, and the model is that you compile your java source against the abstract one and then use the concrete one specific to your context. For example, an mmtk jar would be built against the abstract ones and then when used would see the concrete ones specific to the vm it is being used with. This is similar to org.mmtk.vm. All of the classes in that directory have the same property---they would be replaced by vm-specific versions. Cheers, --Steve |
From: David P G. <gr...@us...> - 2004-09-03 19:00:49
|
Hi Steve, I probably won't be able to look at until Tuesday. All of our machines go away in about 4 hours and I have some other stuff that has to get done today before they go away. I'd suggest building FullAdaptive though, then assertions are turned on and it might be easier to debug., Also if the class cast exception is happening while building the bootimage, build BaseAdaptiveOTH and then do rvm OptTestHarness -useBootOptions -method <the problem method> That will give you a faster turnaround time. --dave |
From: Steve B. <Ste...@an...> - 2004-09-03 19:02:59
|
Thanks Dave. I'll try that. Have a nice weekend. --Steve |
From: Steve B. <Ste...@an...> - 2004-09-04 13:35:40
|
Hi all, I'm pleased to say that all known problems have now been ironed out, and the changes have been brought back up to speed with the latest cvs head (including Kris' latest fixes). All that remains is for the system to be tested under AIX and 64 bit platforms, and for Dave to give me the go-ahead to commit. If anyone with access to either of these platforms could run regressions for us, I'd be most appreciative. Just use the tarball below. Now I will summarize what we've done: . moved unboxed type magic and pragma magic into a new vm-neutral package . changed memory access methods to be instances methods on addresses rather than static methods of VM_Magic . removed all use of Jikes RVM classes from within mmtk (except of course mmtk/vm, which is vm-specific) I realize transitions like this can be a pain, but the more time I spend on this, the more convinced I am that this is the right move. I think if you have any quibbles about names etc, now is an *excellent* time to speak up. :-) Cheers, --Steve a) get cvs with timestamp "2004/09/03 13:18:35 UTC" and apply the following patch: http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic.patch-2004-09-03-131835.gz % cd $RVM_ROOT/rvm % zcat ../vmmagic.patch-2004-09-03-131835.gz | patch -p0 or, b) untar the following tarball http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic-2004-09-03-131835.tgz |
From: David P G. <gr...@us...> - 2004-09-06 06:12:32
|
Hi Steve, When our machines come back up on Tuesday, I'll run regression tests on AIX 32 and 64 if no one else does it before then. I took a quick scan through, mainly looking at the stuff in org.vmmagic and it looks plausible to me. One thing that _might_ make sense to add is a variant of all the load/store operations that took an int as an offset. Depends on how many times we end up having to say addr.loadInt(Offset.fromInt(off)) to justify adding the extra overloaded load/store operations to Address. But, I'd be happy to defer adding that until we see how many times it comes up. ReferenceObject and the instance methods that implement object => ReferenceObject => Address conversion path will be a follow up patch I assume? --dave |
From: Steve B. <Ste...@an...> - 2004-09-06 06:18:31
|
> > When our machines come back up on Tuesday, I'll run regression > tests on AIX 32 and 64 if no one else does it before then. Great! > I took a quick scan through, mainly looking at the stuff in > org.vmmagic and it looks plausible to me. One thing that _might_ make > sense to add is a variant of all the load/store operations that took an > int as an offset. Depends on how many times we end up having to say > addr.loadInt(Offset.fromInt(off)) to justify adding the extra overloaded > load/store operations to Address. But, I'd be happy to defer adding > that until we see how many times it comes up. Yes, I agree entirely with your thinking. I wavered on this point and nearly did what you said, but wanted to consult with Daniel (who was on a plane). I think that perhaps it makes sense because in this context we are not trying to take differences between addresses and therefore the 32 bit limitation of the int just isn't an issue. > ReferenceObject and the instance methods that implement object > => ReferenceObject => Address conversion path will be a follow up patch > I assume? Right. I think this is a high priority, but we could not get it done before Daniel left. BTW, the URL for the patch was broken (in a fairly obvious way). I fixed it by putting a copy of the patch in that place. The correct URL for the patch is actually: http://cs.anu.edu.au/~Steve.Blackburn/private/vmmagic-2004-09-03-131835.patch.gz Cheers, --Steve |