>>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark> No, please ask. This is an area that is not documented enough and VM Mark> implementers must really give us feedback on how they actually use this Mark> stuff. I haven't looked at the reference VM code too much. The javadoc there looks pretty reasonable to me. Maybe the next step would be a package.html file to explain how it all fits together... Mark> See for another examples of how I think the core classes and their Mark> vm/reference counterparts should evolve the suggestion for splitting Mark> Thread into a VM independent Thread and a VM dependent VMThread class: Mark> http://mail.gnu.org/archive/html/classpath/2002-10/msg00009.html Mark> (I have not found the time/opportunity to actually implement this yet.) In general I think this separation makes a lot of sense. It makes it easier for us to provide a VM authors with the information they need to port Classpath, and it makes it easier for us to say what has to change in VM support code from release to release -- we can just diff the VM reference code. The only problem I have with this approach is when a particular method is performance-sensitive; then the extra call is wasteful (as opposed to a native method directly in the standard class). For libgcj we can just maintain a small divergence in these cases. Ideally I prefer to avoid these divergences. I'm not sure how much this consideration applies to other VMs. Tom _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
