Re: [jchevm] _jc_parse_classfile called twice in common case
Archie Cobbs wrote: Mark Hindess wrote: I notice that there is a common code path that goes: _jc_derive_type_from_classfile which calls: _jc_parse_classfile _jc_derive_type_interp which calls: _jc_parse_classfile (with, I think, the same arguments as before) Is this correct? Perhaps we could avoid making the second call? That's correct.. but we don't duplicate much work. The first call to _jc_parse_classfile() has howmuch=1, which means just parse the names of the class, superclass, and superinterfaces, and then return. Actually, we do parse the constant pool twice, which is silly. But this is easy to fix... done in r417540. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote:
Actually I propose the default value of interrupt action is null,
which means the VM will do what it suppose to do for the general
cases(wait(), join(), etc) as before, so the interrupt() might looks like:
public void interrupt(){
if(action != null){
action.run();
}
//call native method to do what it supposed to do
interruptImpl();
}
If you do that, and the VM uses signals, then interruptImpl() is going to
unexpectedly
wake up your NIO threads with a signal, right?
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Produce updated snapshots in time for ApacheConEU?
Geir Magnusson Jr wrote: Can we snapshot a few things together (jchevm, classlibadapter, drlvm, classlib)? Probably in separate archives still at this point? Yes. I think that we'd want 3 : 1) classlib 2) drlvm + classlib 3) jchevm + adapater + classlib (hey, archie, when are you going to make adapter redundant for jchevm???) I thought we wanted to keep the adpater distinct, so that one could (in theory) re-use it with other Classpath-compatible JVMs... ? Similarly, it's advantageous for JCHEVM to remain compatible with both classlib and Classpath for testing and comparison purposes. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote: I'm still curious what mechanism will be used to wakeup blocked threads though. And when Thread.interrupt() executes the interruptAction and closes the channel, generally the blocking I/O operation will return with an error code, and if Harmony user implements a subclass of AbstractInterruptibleChannel, he is required by spec to implement implCloseChannel(which is invoked by close()) in similar way, in both cases, the thread is waken up as by product. The blocking select is waken up in similar way by invoke wakeup() in interruptAction. Thanks.. for the other cases.. e.g. a thread blocked in Object.wait(), Thread.join(), or Thread.sleep(), I guess they will require an interrupt action which invokes a native method (equivalent to the current situation), right? I.e., these cases would be handled entirely by the VM. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote: OK, this is nice and simple.. installing an interrupt action is a clean and Java-centric way to make the handling of interrupts explicit. It may be technically unnecessary (if POSIX signals were available) but has the advantage of being less tied to the O/S and VM internals. Great, so may I assume you agree with the VMI modification to add Thread.setInterruptAction()? Yes, looks good. I'm still curious what mechanism will be used to wakeup blocked threads though. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote:
I. B send interrupt signal to A, and A responses by doing right thing
II. For select(), using signal to wake it up, and
AbstractSelector.begin()/end() actually don't need to do much things
III. For blocking I/O, begin()/end() should set/reset some
per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from I/O,
the I/O classlib native codes checks the flags, if it is set, then the
I/O is interruptible and everything is OK so just going on, but if
not, which means the I/O is actually not interruptible, so that the
I/O classlib native codes should invoke the I/O system call again to
blocking again.
But the issues are:
a. for I, and I'm not sure how to wake up windows thread blocking on
I/O, except close the file descriptor
b. for II, I have no idea how to wake up a Windows thread blocking on
select, except secret wake up fd, or loop in Java codes with
select(timeout)
c. for III, this solution impacts much to most I/O codes, first, it is
hard for begin()/end() to encapsulate the machinery, every blocking I/O
system call invocation must take care of the interruptible flag. And
more significant, it is difficult to extend the
AbstractInterruptibleChannel like spec requires, because at first the
developer should care about the flags and make his I/O codes loop, and
then he must know about the flags, because begin()/end() is final, so
that it is impossible except we introduce more contract to Harmony users
besides Java spec.
For (a) and (b), the POSIX pthread_kill() function would work... but
of course that requires POSIX compatibility (this doesn't seem like
a big requirement to me but then again I don't program on Windows).
But I don't understand (c): every blocking I/O call is implemented
in classlib native code, so the Java developer is not involved (the
looping, checking of flags, etc. would be done in the native I/O code).
To me it boils down to whether we can assume POSIX siganls are
available. If not, then I agree we need the interrupt actions.
1. add a setInterruptAction(Runnable action), its implementation is
straightforward
2. Thread.interrupt() is supposed to be like this:
public void interrupt(){
if(interruptAction != null){
interruptAction.run();
}
interruptImpl();//do what it supposed to do before interruptible NIO
world.
}
OK, this is nice and simple.. installing an interrupt action is a clean
and Java-centric way to make the handling of interrupts explicit. It may
be technically unnecessary (if POSIX signals were available) but has
the advantage of being less tied to the O/S and VM internals.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jchevm+classlibadapter] Running classlib tests
Ivan Volosyuk wrote: IMHO, Archie's suggestion is simplier and less intrusive, as the function Thread.attachInternal() can be native function implemented in classlibadapter itself. But Graeme is correct in that there could be initialization delay. I.e., if we're following the normal rules of Java, all the initialization associated with java.lang.Object, java.lang.String, etc. will have to occur before the very first thread can invoke any methods in java.lang.Thread (even if native). The idea is salvagable if we have a special classlib-specific launcher (i.e., C program using the JNI invocation interface to launch the JVM) which did the very first thread_attach() for the main thread. Then all the other threads could use Thread.attachThread() or whatever without all the initialization delay. Yet another idea (probably not feasible) would be for classlib to: (a) check whether thread_attach() has been called yet for the current thread in any native method that requires this to be so, and if not, go ahead and do it itself (b) store its state in a ThreadLocal (so cleanup would be automatic) This would eliminate the requirement for the VM to be classlib-aware. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Andrew Zhang wrote: if thread A is block on ServerSocket.accept(), then A is interrupted by another thread. What should be the result? Spec says If none of the previous conditions hold then this thread's interrupt status will be set. Only interrupt status should be set and thread A should keep blocking! RI also behaves in this way. Therefore, I'm not sure whether signal communicatoin works for this scenario. If you wakeup from accept() with a signal, and you want to ignore that signal, you just loop back and invoke accept() again (same would be true for any other interruptible system call like read, etc.). Instead, if you need to throw some exception, you throw it. Etc. If a signal is sent to one thread, then the target is really killed. Only for certain signals like TERM, INT, etc. If we were to use signals for interrupt, we'd use one of the user-defined signals like USR1 and then install a signal handler which ignored the signal (i.e, just returned). But interrupt concept in java.lang.Thread is not the same as that in native OS. For java, the interrupted thread ends its lifecycle in some situations while it keeps the same as if no interrupt happens except that the interrupt status is set in other situations. Comments? Please correct me if I'm missing something. Thanks! Not sure what you mean by ends its lifecycle.. if you mean returns from whatever method was being invoked, yes sometimes it returns and sometimes it does not.. but either way can be implemented as described above. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] moving to 1.5 for real - discuss
Mark Hindess wrote: On 16 June 2006 at 12:11, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: I'd like to suggest that we get at least one of the project VMs to support this before we switch. Yep, Alexey said that there were some (minor) changes required to DRLVM, and Archie said that JCHEVM should already handle the new classfile format. I tried jchevm with target=1.5 and I submitted a JIRA, HARMONY-585, to fix a minor issue. I suspect that new issues will come up pretty regularly when we start using 1.5 for real. (This is not a reason to hold anything up.) I've applied HARMONY-585 in r414874. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote:
Jimmy, Jing Lv wrote:
Archie Cobbs wrote:
Paulex Yang wrote:
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
I don't think the VM or java.lang.Thread needs to be involved.
First of all, the code performing the blocking operation knows
what kind of operation it is, so when it wakes up abnormally it
can take the appropriate action. This code doesn't necessarily
reside in java.lang.Thread.
In Classpath the java.nio stuff is all implemented in native
libraries without the VM or java.lang.Thread being specially
aware of anything. However, classlib's design may be different
enough to need it (I haven't studied it as much as you guys).
E.g., the java.nio native code does invoke Thread.interrupt() and
Thread.interrupted(), but these are normal, API-specified methods.
Might be worth taking a look for some design ideas.
Thanks Archie, it sounds interesting :).
As I study few about Classpath, I still have a question here. As we
know, there are three states of blocking on a thread. One is wait(),
sleep() and so forth, thread class handle them itself, it is easy to
interrupt; and one is blocking on I/O, invoke Thread.interrupt() may
be not enough as it is blocked on a system call, e.g., call read on
socket may not return until it receive something or it is closed. In
this way, the Thread.interrupt should know how to close the socket to
perform the real interruption. The question is: how can the thread
know if it is blocked on wait() or I/O operation currently? I think
this is the reason why Paulex require Thread to be involved. So I'm
very interested in what does Classpath do here to stop I/O operation
without get involved?
Actually Thread.interrupt() is required to handle four different scenario:
1. wait(), join(), etc, throw InterruptException
2. blocking I/O, close the channel, and throw ClosedByInterruptException
3. blocking select, wake up the selector
4. none of above, just set the thread's interrupt status
So if we don't involve Thread and want to implment scenario 2 and 3, we
may find the situation is:
a. If Thread cannot judge scenario 2/3, so it may think they are both
scenario 4, so Thread.interrupt() just set the interrupt status and do
nothing else, the I/O operation is still blocking there, we cannot get
it actually interrupted.
b. If Thread can find the thread is blocking somewhere, and it considers
all blocking as scenario 1, so the InterruptException is thrown, but
considering scenario 3, Selector.select() should be waked up without
exception, while our selector only has the end() executed in finally
block like below, how does end() catch the thrown InterruptException and
handle it silently?
try {
begin();
// Perform blocking I/O operation here
...
} finally {
end();
}
c. If Thread can magically find the thread is blocking on I/O or select,
it may need to set the interrupt status, and make the blocked Java
method return with some error, so that the end() can check them.
Further, the Thread needs to know if this blocking I/O is
interruptible in Java, for example, the ServerSocket.accept() and
ServerSocketChannel.accept() probably uses same system call, but Thread
should know ServerSocket cannot be interrupted while ServerSocketChannel
can...I have no any idea how Thread can do this without interaction with
NIO channels.
So, Archie, I'm very interested in how Classpath handle this problem.
Would you please help to give more details for it (if no legal concern)?
To be honest I'm not sure how exactly it works, or even that it does (I haven't
played with the nio stuff at all).. I only know that Thread implementations in
Classpath don't have special stuff for NIO channels.
Taking a look at Classpath...
In Classpath, if select(2) returns EINTR, the select just returns normally
(with nothing selected) and then the code checks Thread.interrupted().
If set, it closes and throws the exception as necessary.
Also, on UNIX at least, one thread may close a file descriptor that
another thread is waiting on and the second thread will immediately
wake up with an error. So that case is easy to handle.
So the only hard part is waking up the sleeping thread that you have
interrupted. Once it wakes up, the rest can be handled in Java.
A thread blocking on select() will get EINTR if a signal is received. A thread
can signal other threads (via native code) using pthread_kill(). So one
approach would be for the VM to signal a thread with an otherwise ignored
signal when that thread is interrupted. The only possibilities I see are:
1. Interrupt select(2) with a signal
2. select(2) listens on an additional secret file descriptor for reading
and the VM writes a byte into it
3. select(2) is called with a short timeout, and each time it returns
with timeout we check Thread.interrupted(), then try again.
#1 is most efficient and simplest, but requires VM
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Paulex Yang wrote: But after all, the implementation details(class name, fields/methods, etc) are different, so the idea is to provide the three JNI methods' implementation in NIO module, and add them into VMI, so that VM vendor can choose to add them into the JNI function table. I think this will make it easier to integrate Harmony classlib and multi VMs. This seems like a good approach. The VM can just add the classlib-provided function pointers to its JNI invoke table and not need to know anything else. Of course, the classlib implementations will have to be written as JNI functions (they can't use direct access to the objects or classes) but that's fine. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote: Seems Thread's implementation must be aware of what operation it is blocking on. So I propose the following solution: I don't think the VM or java.lang.Thread needs to be involved. First of all, the code performing the blocking operation knows what kind of operation it is, so when it wakes up abnormally it can take the appropriate action. This code doesn't necessarily reside in java.lang.Thread. In Classpath the java.nio stuff is all implemented in native libraries without the VM or java.lang.Thread being specially aware of anything. However, classlib's design may be different enough to need it (I haven't studied it as much as you guys). E.g., the java.nio native code does invoke Thread.interrupt() and Thread.interrupted(), but these are normal, API-specified methods. Might be worth taking a look for some design ideas. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) FYI, here is how this is handled in Classpath-based VMs like JCHEVM. The direct buffer classes derive from a common superclass containing the well known fields data and capacity. The latter is an int, while the former is of type gnu.classpath.Pointer32 (or Pointer64), which is just a container that stores a native pointer in an int/long. The native pointer points to the native buffer. These two fields are accessed by GetDirectBufferAddress() and GetDirectBufferCapacity(). There is also a constructor available for the JNI code to call, taking: gnu.classpath.Pointer32/64, and int (capacity). This is used for NewDirectByteBuffer(). The resulting JNI code is fairly simple. You can see it on line 2580 of https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm/libjc/jni_native.c -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jchevm+classlibadapter] Running classlib tests
Mark Hindess wrote: I fixed it by using the RI javac rather than the eclipse compiler. Thanks.. that worked. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] moving to 1.5 for real - discuss
Alexey Petrenko wrote: The only question from me for now: does all the Harmony VMs (DRLVM, j9, jchevm) support 1.5 version of class files? JCHEVM should handle the new CONSTANT_Class and classfile version, but other stuff like 1.5 reflection won't work yet. So far little attention and testing other than for the class file format has been payed so far. 1.5 support is of course a goal, so I'm in favor of the change. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: There are a bunch of patches already attached to Harmony-483. Reflection, system classloader works now reasonably well. My main testing workload is eclipse and I am slowly moving forward. Eclipse already can successfully use logging. I am investigating why it cannot load its own jars. A small note about patch sequence in jira: all patches should apply cleanly except wrong patch: 2. classlibadapter-incremental-update-20060522-20060528.diff (163 kb) It was sent by mistake and contains exact the same content as initial patch classlibadapter-update-20060522.diff. Ivan, I've applied the patches in HARMONY-483 in r411596. Please take a look to make sure I applied them correctly. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Archie Cobbs wrote: Ivan Volosyuk wrote: This code checks access control in eclipse. The caller of the method should be member function of class EditorsUI. As jchevm also reports exception creation stack frames the access check doesn't work. I can make a workaround in classlibadapter, but I think it should be better fixed in the vm code, as the fix will work with gnu classpath too. If you are too busy, I can make this fix for jchevm. Thanks for hunting this down. I'll work on a fix, which should be easy. Done (r410737). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: Archie, current version of jchevm has hard coded optimizations in configure.ac, it is difficult to debug the code with optimizations. When disabling optimizations in it (-O0) - there are compilation and execution problems. I have small fix for compilation problems and small dirty fix for execution. Interested? Sure, you can email them to me. We should add a ./configure flag like --disable-optimization or something that would do this. In my experience it's fairly rare that I need to disable optimization because gdb still works well with it (although you have to be aware that sometimes variables disappear etc), but indeed sometimes it's necessary. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: I have prepared my modifications and posted a patch against the SVN/classlibadapter. http://issues.apache.org/jira/browse/HARMONY-483 I was able to get rid of all native modifications and some of modified classes. NewWeakGlobalRef implementation on vm needed though. FYI, I've implemented NewWeakGlobalRef in r408937, so that patch is no longer needed. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: That's great! I have seen the notification. There are quite a few changes I see. I've implemented NewWeakGlobalRef in r408937, so that patch is no longer needed. If you update make sure you get at least r408953, which contains a bug fix. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Weldon Washburn wrote: I just now looked at 483. Good work. I'd like to check-in these mods into svn but don't have check-in permission. I can check them in, but I think Ivan's code needs official blessing first. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Weldon Washburn wrote: Please hold off the check-in for a few days. I would like to try Ivan's mods on my machine to make certain they are complete. The intention is to reduce the chance of secondary patch-up check-ins and the related blizzard of emails. No problem.. I'll wait for both (a) your confirmation and (b) Apache contributor license thingie. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: I have recently built jchevm and tried to run eclipse with it. When loading a error window appeared. It looks like a bug or unimplemented functionality. Yes, this is a bug I haven't been able to track down yet. Any insights appreciated. Also check out: http://sablevm.org/wiki/Eclipse for some command line flags that may help. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: Sure, if I have some outstanding results I'll share it. As for now... The classpath adapter is very primordial at this point. On the other hand JCHEVM on Classpath's class library should be fairly mature (limited mainly by Classpath itself). By comparing the two, as well as JCHEVM vs. other JVMs that use Classpath, and eventually other Classpath-based JVM's using the adpater, we'll be able to pinpoint which parts are (mis)behaving, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98 to run
Weldon Washburn wrote: Good idea. I will try to look at mauve soon. I don't know anything about it. Do you know if there there any Apache license compatibility issues? Not unless you're planning to resell it or something... :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods
Geir Magnusson Jr wrote: We have 9 votes in favor, none against, and one reasonable question about destination. I think that we should let Archie bring it into SVN. :) It was suggested as enhanced/gnuclasspathadapter/trunk/ but I'd suggest enhanced/classlibadapter/trunk/ to make it generic, because ya never know - there could be other VMs out there for which we might make an adapter to the Apache Harmony clsaslib ;) So far, we work with IBMs VM directly, soon any GNU Classpath capable VM, and maybe.. Archie, please do as is in the zip file and then cleanup from there for traceable accountability. Thx Done.. r398726. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods
Weldon Washburn wrote: Thanks for getting this entered into SVN so quickly. I did a quick check and it looks like you grabbed the most recent version. By the way, the directory structure is still somewhat ambiguous. I keep thinking we may want to put .../gnu.../... in the tree to distinguish this specific adapter. The reason is that someday someone may want to build an adapter for a non-GNU class library. It would be nice to get this kind of directory organization sorted out now. Making mods to the directory structure at a later date probably means hardcoded makefiles will need to be changed. I agree. How about classlibadapter/trunk - adapter/gnu/trunk? Now next questions... let's talk about how we want to build and package this. It looks like basically we need to build two things, (a) a ZIP/JAR file containing the adapter classes, and (b) a native libarary for java.io.File. #1. It's possible to get rid of (b) because Classpath already contains native libraries that implement java.io.File functionality. However, because classlib has native methods in java.io.File (instead of VMFile adapter classes) this would mean writing our own File implementation, which would involve copying (and tracking changes to) the classlib version, so this is probably not a good option. For now, we'll leave it as is but that's an option that's out there. Perhaps eventually we can get classlib to either add a VMFile class or else implement java.io.File itself... any thoughts from classlib hackers? #2. Should the build just produce a distribution subtree in dist/ similar to the way classlib builds, or should it use automake, etc. and support a make install target? I'd prefer the latter. That way we can have a standard install location, e.g. we'd install under /usr/local/harmony/adapter/gnu or something. This would faciliate VM's that want to make it easy to use the adapter because it would always be in a known location. If you like this idea then I can add all the configure and automake magic, replacing the doit.sh scripts. This will aid portability as well, especially because we can use libtool for #1. The auto* stuff should be simple because we won't be doing anything very unusual. #3. I think we'll need to have Classpath installed to do the build. It's standard location is /usr/local/classpath. That way we can compile our adapter classes with javac against all the VMFoo classes that they will delegate to. I can add a --with-classpath=DIR flag to ./configure to make this location configurable. Let me know what you think. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods
Geir Magnusson Jr wrote: I agree. How about classlibadapter/trunk - adapter/gnu/trunk? I'd keep it specific to classlib yet simple and mimic the classlib structure with classlibadapter/trunk/module/gnu or something. OK... although I'm not sure what purpose the module part serves. We can of course always insert it later. Now next questions... let's talk about how we want to build and package this. It looks like basically we need to build two things, (a) a ZIP/JAR file containing the adapter classes, and (b) a native libarary for java.io.File. #1. It's possible to get rid of (b) because Classpath already contains native libraries that implement java.io.File functionality. Classpath? The assumption here is that you don't need to have GNU Classpath, right? Argh, my apologies, for some reason I was thinking completely backwards. Ignore most of what I said :-) We don't need Classpath to build and it won't be available at runtime of course. We could do that, but then that kindof defeats the whole purpose... I think I was imagining this on my laptop which has Classpath but that would be a special case... We will be providing VMFoo classes that define the same API to the VM that Classpath does. Essentially we'll have replacements for all of Classpath's vm/reference classes, plus the glue that goes on top of that to hook it all up to classlib. Hope that makes more sense... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods
Archie Cobbs wrote: Classpath? The assumption here is that you don't need to have GNU Classpath, right? Argh, my apologies, for some reason I was thinking completely backwards. Ignore most of what I said :-) OK now I remember why I thought that before: if you're going to be using JVM X which is designed for Classpath, then most likely you're going to have Classpath installed if you have JVM X installed. So, you might as well take advantage of it. That was the idea anyway. But I agree, it's not worth the added dependency. The only downside of not doing it that way is that it becomes slightly harder to maintain compatibility (because e.g., the adapater's VMFoo API classes will have to manually track changes in Classpath's VMFoo API). But the VMFoo API is fairly stable now anyway so this shouldn't be a huge problem. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods
Geir Magnusson Jr wrote: We have all the docs for HARMONY-114 and they are in SVN Please vote to accept or reject this codebase into the Apache Harmony class library : +1 from me. I think it should probably be a separate (peer) project from JCHEVM and classlib, e.g., under harmony/enhanced. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
Geir Magnusson Jr wrote: Google again is running their Summer Of Code http://code.google.com/summerofcode.html program, and I think it would be great for the Harmony project to take advantage of it, assuming we can find willing students. ... Lets agree on projects here first. Great idea.. certainly one project that seems suitable is completing the gnuclasspathadapter stuff started by Weldon. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib hello world
Weldon Washburn wrote: 1) libtool was not behaving. So, I gave up and used raw ld. 2) dlopen() refused to load the output of ld. Google turned up help pages that showed dlopen() only likes files ending in *.a 3) Once dlopen() was able to open the shared lib containing the native method, gdb was getting lost. Googling the web again turned up a magic input arg to ld called --enable-auto-image-base. Apparently gdb internals are stepping on the same virtual addr as the newly loaded lib?? In any case, the --enable worked around it. 4) There was real difficulty lining up the native method's incoming arguments. Finally I declared the native method with input arguments (int a1, int a2, int a3, int a4). Then passed the character to be printed in all four arg slots. Surprise! The second arg of the C routine actually held the correct argument. So the native method was modified to print just a2. It works fine. Question for SableVM/JCHEVM guys: Did I miss the documentation on lining up native method args? Can you point me to the correct place to figure out how to do this? All of the above is completely mysterious to me and a good example of why I avoid Windows at all costs. Sorry I can't be more help... There's nothing unusual about JCHEVM's native code dispatch. However, JCHEVM constructs dynamic function calls itself (instead of using libffi like SableVM does). So if C calling conventions under Cygwin (which are what?) are different than Linux, you could see misalignment of parameters, etc. Also, I modified files in Harmony Classlib's native-src directory. This might mean we need to add an additional level below enhanced/gnuclasspathadapter/. Something like enhanced/gnuclasspathadapter/native-src... Another issue is that different GNU Classpath JVMs may require different name decoration and different build options. Two ways of handling this are 1) add a subdirectory for each JVM that contains the code that is unique to the jvm and 2) use #ifdefs and make file options to handle the differences. I don't yet see why the gnuclasspath adapter can't be completely generic. Doesn't (or shouldn't) the adapter consist only of Java classes? Not sure what you mean by name decoration and build options. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib hello world
Weldon Washburn wrote: There's nothing unusual about JCHEVM's native code dispatch. However, JCHEVM constructs dynamic function calls itself (instead of using libffi like SableVM does). So if C calling conventions under Cygwin (which are what?) are different than Linux, you could see misalignment of parameters, etc. hmmm this is starting to sound like classic ABI issues. I will investigate and report back. Different tool chains take different approaches to passing arguments. I noticed a comment in arch_functions.c that says, We use __attribute__ ((regparm(3))) which places the first three arguments... I gdb stepped through _jc_dynamic_invoke() and noticed that it copies three slots off of the machine stack and puts them in registers. I guess I need to compile the native method with __attribute__ ((regparm(3))) ?? The regparm() stuff is only used for JCNI native dispatch, not JNI dispatch. I.e., it's only used internally within JCHEVM itself. So this should not affect handling of JNI native dispatch. Not sure what you mean by name decoration and build options. The problem is aligning the java classes with the native methods they call. The goal is definitely zero mods to native-src directory. But I suspect this will depend on ABI issues for the different platforms. In specific, netBSD vs. Linux vs. Windows vs. Cygwin vs. Xen... I still don't understand... the consistency of Java native method name and parameter declarations with the C code that implements them (which is specified exactly in the JNI specification and is the same everywhere) seems like a completely different issue from whether the JVM and native methods were compiled using the same ABI. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs
Mark Hindess wrote: While Weldon is correct that the adapter isn't specific to any JVM but neither is it a required component of the classlib. So I agree with Etienne and Tim; it should be a separate project. On 4/8/06, Etienne Gagnon [EMAIL PROTECTED] wrote: Weldon Washburn wrote: Create a new branch under Harmony/modules/ called gnuclasspathadapter. It will contain all the java source that is needed to glue Harmony Classlib to a GNU Classpath compatible JVM. Make/ant will generate gnuclasspathadapter.jar from this sub-tree. Does this mean that it will always build along harmony, whether needed or not? Wouldn't the following location be more appropriate: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/gnuclasspathadapter/ Any place in SVN is fine with me. Let's just get it checked in somewhere so it can get worked on... so, who'll commit it? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs
Tim Ellison wrote: I would object to making the Harmony kernel GNU Classpath specific, so why not make the adapter a separate 'project', i.e. just gnuclasspathadapter/src/java/java/lang/VMx.java GNU Classpath needs unique pointer classes. We could put them at kernel/src/gnuclasspathadapter/java/gnu/classpath/Pointerx.java or gnuclasspathadapter/src/java/gnu/classpath/Pointerx.java Thoughts on the above? it's more important to get the code working than figure out where in the Harmony repository it would end up isn't it? Wherever it goes I expect it will simply be built into one or more JARs that are put on the bootclasspath to run Classpath-oriented VMs (just like any other VM provides its own own kernel implementation). We can commit the kernel_path stuff into JCHEVM somewhere under java. I started working on this but never heard from Geir whether it was OK to check it in. If someone will confirm it's OK to commit the kernelpath stuff I'll do it. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-318) mods to Harmony Classlib that eliminate most of the changes to JCHEVM
Geir, [resend] Is it OK to commit this stuff to the repo?? Thanks, -Archie weldon washburn (JIRA) wrote: mods to Harmony Classlib that eliminate most of the changes to JCHEVM - Key: HARMONY-318 URL: http://issues.apache.org/jira/browse/HARMONY-318 Project: Harmony Type: Bug Components: Classlib Environment: cygwin Reporter: weldon washburn Most of the modifications to JCHEVM to support Harmony Classlib have been removed. The one remaining mod is because JCHEVM uses cygwin dlopen() to load a DLL. And dlopen(), for an unknown reason, refuses to load hynio.dll. __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vmi] JNI spec interpretation?
Tim Ellison wrote: So what should a VM do if somebody calls ExceptionDescribe() and there is no pending exception? (a) blow up (b) silently ignore it, since there is nothing to describe (c) print out something along the lines of 'no exception' FWIW, here is what JCHEVM will do: If assertions enabled: assertion failure If assertions disabled: core dump with a segfault Since anyone can call the function at any time I'd argue that option (a) is not a good choice. I disagree.. I prefer for things to be written with assertions, so that when assertions are enabled we catch any suspicious behavior as soon as possible, and when assertions are disabled, we assume good behavior and can run as quickly as possible. In this case, the spec seems to be clear that calling this function when there is no exception pending is bogus, so that's why JCHEVM behaves as it does. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vmi] JNI spec interpretation?
Tim Ellison wrote: Understood -- my point is that blowing up and corrupting internal data structures is not something you would do by design. Agreed. By using assertions you get the best of both worlds. Assertions are especially useful for detecting badly behaving JNI native code, which can otherwise result in very hard to track down errors. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vmi] JNI spec interpretation?
Robert Lougher wrote: It's all very well bombing out with an assertion failure, but to the average end-user it's still the VMs fault, especially if it works with other runtimes (i.e. Suns). Sure.. sometimes theory gets trumped by practice. Then you have to decide which is less work: convincing 3rd parties to fix their code or implementing a hack/workaround. If there is lots of JNI code out there doing this, then you're certainly right that the workaround (which costs essentially nothing) would be easier. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vmi] JNI spec interpretation?
Oliver Deakin wrote: The word pragmatic springs to mind. FWIW, JamVM will print nothing if no exception is pending. It didn't do this originally -- it blew up with a SEGV. I changed it because a user reported an application which didn't work with JamVM but it did with Suns VM (can't remember which application, it was a long time ago). This sounds right to me. As a user Id expect a call that prints exception output to the screen to just print nothing and return if there is no pending exception. It's all very well bombing out with an assertion failure, but to the average end-user it's still the VMs fault, especially if it works with other runtimes (i.e. Suns). Exactly - isn't this one of those differences to undocumented RI behaviour that we should try to match? There is nothing undocumented about this. The JNI spec says (though not very clearly) that you should not call this function unless you know there is a pending exception. However, that's not to say that we shouldn't be pragmatic, though, and try to handle the situation gracefully. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.reflect
Etienne Gagnon wrote: Tim Ellison wrote: Gary Clark wrote: 3) Do any of the current VMs support the 1.5 features? Off the top of my head I don't recall if anything changed within the VM to support them. I'll let Etienne, Archie, Dalibor, et al describe their status wrt Java 1.5 support. The IBM VM can switch to 1.5 support trivially but we are limiting it to 1.4 until there is reasonable coverage in the open source VMs. One of my former students succeeded to run SableVM with the generic branch of GNU Classpath over the holidays, by only implementing one or two additional native methods in SableVM (the code should be in his sandbox somewhere). As far as I know, the type erasure stuff was chosen by Sun as to minimize the impact of generics on the virtual machine. So, I don't expect the switch to 1.5 to be something big. But, first, it would be nice to get SableVM to work with current Harmony... So, I'm working on that for the time being. JCHEVM already supports the 1.5 bytecode change (Class literals) but does not yet have reflection support for the new 1.5 stuff. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vmi] JNI spec interpretation?
Etienne Gagnon wrote: It seems that the launcher assumes that it is OK to call (*env)-ExceptionDescribe() even when there is no pending exception. Definitely sounds like a bug (in the launcher) to me. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Importing HARMONY-114
Geir, Is is OK to check the files in: http://issues.apache.org/jira/browse/HARMONY-114 into the jchevm SVN? That way we can start working on it further. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r390246 [1/15] ...
Tim Ellison wrote: Wow. This patch touched lots of files to fix spelling mistakes, and the commit fell foul of the EOL diff problem being discussed elsewhere. Hand-on-heart, I looked at every incoming change and swear that they are simple typo fixes in comments and a few error strings. I know that nobody can figure that out from the commit messages. Interesting.. so you are using a tool (Eclipse?) that shows a different pending diff that svn diff does? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: EOL differences in svn diffs
Tim Ellison wrote: Can we set up the server to recognize .java / .xml / etc files as text/plain native types? Sounds good to me $ find . -name \*.java -o -name \*.xml \ | xargs svn propset svn:eol-style native \ svn ci -m Set native EOL style Etienne Gagnon wrote: Actually, you need to set 2 properties: svn:mime-type : text/plain svn:eol-style : native Hmm.. in my experience, only svn:eol-style native is required, as by default subversion treats files as text files.. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: SableVM / Harmony Collaboration
Stefano Mazzocchi wrote: (DREAM WARNING) Personally, I wouldn't mind seeing a hybrid SableVM/JikesRVM where bootstrap happens in C (no complex platform dependent image generation process), but adaptive compilation happens in Java... Boy, that would be indeed sweet. As long as you have an interpreter written in C (which we do) then this is fairly easy: 0. Start out interpreting everything 1. Adaptively compile as you see fit 2. Switch over dispatch of compiled methods from interpreter to their compiled code. This is sortof how the original JCVM worked except the compilation happened before execution and/or during runtime dumbly (it compiled every method, not just hot ones, and was pretty slow in doing so). Then its also possible to accumulate a filesystem cache of compiled method code, as JCVM did (using ELF objects). Not sure if this is really worth it or not, as you'd have to record lots of dependencies, and only makes sense if the JIT/compile operation is fairly slow. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: SableVM / Harmony Collaboration
Etienne Gagnon wrote: I am all in favor of implementing IBM's proposed VMI in SableVM directly. Where do I find more information about the VMI? My opnion (just one of many of course) is that it might make more sense to fill out the IBM VMI so that it closely (or better yet, exactly) matches the current Classpath VM API. I'd be interested in your thoughts on that idea. See the thread [jchevm] porting harmony classlib to JCHEVM for a previous discussion: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] In short, the Classpath VM API is lower layer than the IBM VMI, so you'll end up implementing a bunch of the same stuff anyway. You might as well implement it in Java instead of in the VM, and doing it in the same way as Classpath would allow for much more flexibility in terms of Java class library and VM combinations and would mean many fewer changes to SableVM. Note I'm referring only to the Java/VM API, not the Java/native code API, which is really an issue private to the class library. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: SableVM / Harmony Collaboration
Etienne Gagnon wrote: Also, I would like to think about the VMI with the view of a pure virtual machine implementor, not that of a binary compiler implementor or that of a hybrid system implementor. It would just be more fun for me. I already don't like much working on VMI and class libraries; I might as well try to make it as enjoyable as possible. That makes sense.. i.e., if you want to make it into something of a research project to define the best possible Java/VM API then I'd be interested in that as well. Of course this will take more work. First of course is defining what the goals and priorities are (if your goal were to do it quickly, then re-using the existing Classpath API would be the best option imho). In any case, there is lots of remaining Java code lying just above this API to be written. Doing so will naturally bring up those questions about the right way to define the VM API. Do you have any general guiding thoughts? E.g. we both agree that doing stuff in Java whenever possible and reasonable is better. What else? Some interesting areas to think about.. - Class loading. Can maintenance of initialized and/or derived types trees be done in Java? Loading constraints? Etc. - VM private data structures: could more of these be stored in byte[] arrays, so that Java code can just pass the byte[] array to native code where appropriate? - Class initialization: SableVM already does this in Java I think. - Threads - Exceptions - Stack walking - GC: any Java possibilities here? - Bytecode verification The more you push down the more it starts to get into the VM written in Java concept a la Jikes RVM. Another idea: the VM API is just POSIX (or some subset), and you have some way to manipulate (pack/unpack) C types via Java. Yet another idea (from JCVM): mix/embed C code in Java code analgous to the way GCC's asm() statement embeds assembly into C code, then auto-gen all the VM's native methods. Etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Etienne Gagnon wrote: 1- I do claim shared copyright on JCVM/JCHEVM. I do not and will not back down from this. 2- As far as I can tell from the above, both the ASF and Archie Cobbs seem to agree to acknowledge this shared copyright. Um, I think I agree... so what is the practical import? In other words, if JCVM/JCHEVM can be licensed under the Apache license, then I'm satisfied. I don't plan on ever trying to take this stuff closed source or whatever.. so anyone else sharing copyright shouldn't matter (to me) right? 3- The only obscure area that is left (i.e. an area where there is no explicit agreement between all involved) is: which exact parts can be claimed independent work and which cannot not. It seems easier to agree to simply state the shared copyright on JCHEVM and leave the detail of exact files and lines out. Personally, I claim co-ownership on the whole derivative of SableVM. I am sure Archie Cobbs would do the reverse. Unfortunately, it would probably be quite difficult to settle this out of court. Do you really want this to escalate that far? I agree it would be messy to try to separate it out, even though most of JCVM is not derivative (e.g., the garbage collector, weak and phantom reference support, finalization support, bytecode interpreter, ZIP file reader, class file parser, class loader and resolution code, class file dump tool, javah tool, JAR file launcher, heap structure, Thread.interrupt support, reflection support, signal handler, etc.). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] JCHEVM discussion
Geir Magnusson Jr wrote: I applaud Archie for his candor and openness wrt these issues so far, and suggest that Archie is in the best position to lead off the discussion :) [hint] Umm, ok here goes :-) There are a couple of different issues. I'll try to separate them out to the best ability of my own understanding. A little background: copyright covers the expression of an idea. To cover the idea itself, a patent is required. This issue is about copyright; nobody is claiming that SableVM has exclusive rights to any algorithms AFAIK. 1. As for credit, clearly JCVM uses and reimplements many ideas and algorithms from SableVM. This should be obvious. I have a lot of respect for Etienne's work. The SableVM project as a whole deserves all of our respect. Quoting the JCVM manual: http://jcvm.sourceforge.net/share/jc/doc/jc.html An acknowledgment is due here. JC borrows heavily from Etienne Gagnon's innovative SableVM Java virtual machine implementation. Several ideas have been blatantly stolen from SableVM, including bidirectional object layout, the object lockword design and spin-free thin lock algorithm, per-class loader memory allocation, and thread management. In fact, without SableVM as an example to work from this project would probably have never been attempted. Of course, any errors in translation are mine. Whether credit is due is not in question. 2. The copyright issue is the main one in question. JCVM was LGPL, so there was never an issue. When I donated JCVM as JCHEVM, copyright became an issue because of the new license. My thoughts at the time are here: http://issues.apache.org/jira/browse/HARMONY-3 In JCHEVM, the thread handling and thin lock algorithms are very much the same algorithms, and my implementation contains similiar function names to SableVMs, etc. The code is written differently but basically does the same thing. After all, an algorithm is a bunch of exact steps that must be executed in a certain order. So does JCVM constitute a different expression under the copyright law? That's the question -- and not one for me, for IANAL and TINLA. The truth is apparently no one really knows for sure. How different does some software have to be before the copyright no long applies? (Rhetorical question) There is a spectrum between cut and paste (clear violation) and completely different implementation of the same idea or algorithm (clearly allowed as long as there is no patent). In between people can have different opinions of where the line is drawn of course. 3. So what do we do? My wish is to give SableVM the benefit of the doubt. If there's something in there they claim is theirs, we can take it out and replace it. I'd rather do that than argue about it. We should remember that JCVM owes SableVM a debt of gratitude and respect their wishes. In particular there are lots of thread handling and locking algorithms, and these AFAICT are the only two areas of the code that might be considered not different enough (though I haven't heard back from them yet exactly what they are claiming), and these are easily replaced. There's also the possibility that SableVM folks could give their blessing and donate their code, but that might have practical difficulties because all the SableVM contributors would have to agree to the new license (though I'm one of them, so my vote would be easy :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
Weldon Washburn wrote:
Please take a look at bootstrap.c It would be great if we can do the
final integration in the next 2 days while this code is still fresh in
my mind.
Looks reasonable, you just commented out or changed the classes
and methods that would not load yet.
What's the plan for dealing with the Pointer class? Here are some
possibilities that preserve Classpath compatibility:
1. Implement gnu.classpath.Pointer{32,64} in classlib
2. Have jchevm autodetect whether gnu.classpath.Pointer or
java.lang.Pointer is to be used.
Either solution is OK with me, but I'd much prefer #1 because it's
cleaner code and I'd rather not start adding hacks at this point that
move us away from the current common API.
Eventually I'd like jchevm to have a command line flag that allows
you to easily switch between Classpath and classlib at startup, for
quick side-by-side behavior comparisions. This will greatlyl increase
our ability to debug the classlib/jchevm interface.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
Weldon Washburn wrote: Either solution is OK with me, but I'd much prefer #1 because it's cleaner code and I'd rather not start adding hacks at this point that move us away from the current common API. I agree that #1 is the cleanest, easiest technical approach. The difficulty is convincing an attorney that a file in Harmony Class Lib called blah blah GNU blah blah CLASSPATH has nothing to do with gnu or classpath. I vote for adding a few lines of code to avoid spending hours with an attorney. Hmm.. honestly I'm starting to lose patience with all this legal nonsense. Not your fault of course Weldon. Rhetorically I ask how is using gnu.classpath in a class name any worse than using java.lang? Sun has a trademark on the work java you know. Can someone (Geir?) give us a quick answer on this so we can proceed?? How about an algorithm that first checks for gnu.classpath.PointerXX and if its not found then looks for xxx.yyy.zzz.Pointer class? I am not happy with putting Pointer classes in the java.lang package. Maybe create a new package called kernel_path. Thoughts? Putting it in java.lang is fine -- as long as the class is package private, which makes it invisible to user code. This is what's done with all the other VM related classes like java.lang.VMThread, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] Harmony Class Lib does Hello World on a GNU Classpath JVM
Weldon Washburn wrote: I can now run the below multithread Hello.java on JCHEVM using Apache Harmony Class Library. The output toggles between clumps of Hello World and clumps of * as WindowsXP schedules the two application threads. This is behavior I would expect. I use System.out.write() because System.out.println() does not work yet. A summary follows: Wow! Impressive achievment very cool. Mods to JCHEVM to get it to work 1) I was not able to find the _JC_LIB_ENTRY that is intended for read/writing files. I gave up and borrowed JCNI_java_lang_VMThread_nativeSetPriority(). Instead of actually changing thread priority, it now does a fprintf(stdout, %s, priority); fflush(stdout); Perhaps you can tell me what native method I should be using. Classpath supplies its own native methods for file I/O. That is, you can implement file I/O normally using normal native methods. This is not something the VM needs to be directly involved with. So the fix would be for classlib to implement this itself. There's no reason you couldn't write a gnu.classpath.Pointer class if you wanted to. There's no copyright on the package name :-) By the way jchevm's Thread.setPriority() doesn't work because I don't know how to implement it using POSIX. 2) I commented out some stuff in bootstrap.c that was dragging in specific gnu classpath *.class files like Lgnu/classpath/Pointer; We should discuss the best solution for this item. This is use as part of the NIO implementation for direct buffers. A Pointer object simply contains an int or long that holds a void *. One last item. I don't know which SVN repository to place this work in. Any suggestions? You could create a branch of classlib in the sandbox. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] Harmony Class Lib does Hello World on a GNU Classpath JVM
Weldon Washburn wrote: Classpath supplies its own native methods for file I/O. That is, you can implement file I/O normally using normal native methods. This is not something the VM needs to be directly involved with. So the fix would be for classlib to implement this itself. I suspected this. But I could not figure out how to add a new entry into _JC_LIB_ENTRY. I tried but got a bunch of misc error messages so I gave up. If you give me some hints on how to add enties to _JC_LIB_ENTRY, I will take a second stab at it. You would not modify that code (or any other part of jchevm) at all. Instead, you'd build a JNI native library as part of classlib and then load in your Java code it via System.loadLibrary(). This is just the usual Java code with native library pattern. The _JC_LIB_ENTRY() stuff is only for native methods that are provided by jchevm itself, e.g., java.lang.VMThread.start(), Runtime.gc(), etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jira] Updated: (HARMONY-188) ObjectOutputStream.useProtocolVersion(version) should check a parameter value.
Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] workarounds for Cygwin zip/jar problems that makes hello world work
Enrico Migliore wrote: I noticed that Ivan introduced the macro __CYGWIN__. Did you merge the macro in the source tree, or it exists only in Ivan's code? All of the Cygwin fixes that I know of (except unzipping the zip files) should be merged into the source now. If there's one I missed, let me know and I'll add it. let's do this way: during the weekend, starting from my, your, Ivan's, Waldon's threads, and from the current source tree of JCHEVM, I'll write (and test, of course) the HOWTO. Then, on monday, I'll submit it to the list for discussion, so that you can evaluate which fixes to apply to the source. Sounds good...thanks. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] questions about libjc/zip.c
Weldon Washburn wrote: I tried the pread() patch but I still get: I just checked in support for systems without pread(2) in r382047. The patch should no longer be needed. Let me know how/if it works. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] questions about libjc/zip.c
Weldon Washburn wrote: It looks like it is finding glibj.zip. But I still get the same error message when I try to build. Weird.. I have no idea why it's not working. There may be some problem when zip.c tries to read glibj.zip that causing it not to work. At this point I think it's time to resort to the tried and true stragegy of strategically inserted printf() statements... sprinkle some into zip.c to see how far it gets reading from glibj.zip. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Strange thing with jchevm/classpath
Jean-frederic Clere wrote: So either something weird is happening (always possible), or you have some other incompatible version of log4j on your classpath, or something in your classpath was compiled against another version of log4j, etc. My test is using: Class.forName(org.apache.commons.logging.impl.Log4JLogger); I have rebuild commons-logging using the log4j I am using in the test and the test is working now. But I still don't understand why it was working with the Sun JVM before!!! Probably due to classpath differences. E.g. do you have a CLASSPATH environment variable set? Sun pays attention to it, jchevm does not. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: After applaing your fix it no more crashes. Cool. Just tested this with QuickSort algorithm. It's running OK. (but a bit slow under cygwin in comparison to SUN's JVM under Win) JCHEVM will definitely be slower right now because there's no JIT yet, i.e., it always operates in interpreter mode. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] runtime performance
Enrico Migliore wrote: I read an article that said that the performance of the SableVM, in terms of speed, was quite impressive. What's the difference between JCHEVM and the SableVM? JCHEVM should be roughly the same speed as SableVM's direct intepreter mode.. SableVM's threaded interpreter mode will be somewhat faster, as it eliminates some of the goto overhead assocated with each instruction. All of the above is theoretical, the best answer of course is to do some real benchmarking tests. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Strange thing with jchevm/classpath
Jean-frederic Clere wrote: However, how did the classes change? I tried to reproduce this with log4j-1.2.13 but couldn't. I am using logging-log4j-1.2.13 and I have downloaded it. Can you give more detail on how you compiled Classpath and what version of log4j you're using? That is on a debian machine I have used apt-get install to install it. I can't tell what the problem is without more info. You could try running with --verbose=class to see where jchevm is looking for class files. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: This one is mysterious and will take some debugging by someone on a Cygwin platform. I'd start by checking what r is (i.e., what's the return value). Then try to come up with a simple test case of a condition variable, etc. As I can check _r = 22 and vm-vm_destruction = 0 According to docs 22 is EINVAL and |pthread_cond_signal returns when | [EINVAL] The value /cond/ does not refer to an initialised condition variable. D'oh! This one is easy, we weren't initializing the condition variable. Fixed in r381407. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Strange thing with jchevm/classpath
Jean-frederic Clere wrote: I am using logging-log4j-1.2.13 and I have downloaded it. There is no such method: org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V in the JAR file that comes with that version of log4j. So either something weird is happening (always possible), or you have some other incompatible version of log4j on your classpath, or something in your classpath was compiled against another version of log4j, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Strange thing with jchevm/classpath
Jean-frederic Clere wrote:
I have a strange error:
+++
java.lang.NoSuchMethodError:
org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
at java.lang.VMThrowable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:498)
at java.lang.Throwable.init(Throwable.java:159)
at java.lang.Error.init(Error.java:81)
at java.lang.LinkageError.init(LinkageError.java:72)
at
java.lang.IncompatibleClassChangeError.init(IncompatibleClassChangeError.java:71)
at java.lang.NoSuchMethodError.init(NoSuchMethodError.java:72)
at java.lang.VMClass.forName(Native Method)
at java.lang.Class.forName(Class.java:161)
at toto.main(toto.java:8)
+++
Looking log4j I have found the following in Category.java:
+++
void log(String callerFQCN, Priority level, Object message, Throwable t)
+++
and in Level.java :
+++
public class Level extends Priority implements Serializable {
+++
So why is the method log no found?
The method matching algorithm that would allow a method having
2nd parameter type Priority to be used for an invocation that
has a 2nd parameter of type Level happens during compilation,
not runtime. In other words, an incompatible class change has
truly occurred it seems and in such a case the exception is
expected.
However, how did the classes change? I tried to reproduce this
with log4j-1.2.13 but couldn't. Can you give more detail on how
you compiled Classpath and what version of log4j you're using?
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] problems with gnu classpath and also jchevm builds
Geir Magnusson Jr wrote: does this mean that JCHEVM has a hard dependency on native methods from GNU Classpath? Not sure exactly what you're asking, but I think the answer is no. There shouldn't be any dependencies beyond what is required. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] problems with gnu classpath and also jchevm builds
Geir Magnusson Jr wrote: meaning that with some minor gluecode that weldon is writing, we don't need to have GNU Classpath to run JCHEVM and Harmony classlib? does this mean that JCHEVM has a hard dependency on native methods from GNU Classpath? Not sure exactly what you're asking, but I think the answer is no. There shouldn't be any dependencies beyond what is required. That's correct. All that's required from any class library to work with jchevm right now is that it use the Java/VM API that jchevm supports (defined by Classpath). Of course any class library has to come with some native libraries of its own, but that's really it's own business and not a concern of the VM (other than the VM being the channel through which the two communicate). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: Still havn't solved problem with jc: assertion failure: _r == 0 jc: location: file `thread.c' line 1023 This one is the reason for simple thread test crash after few itterations This one is mysterious and will take some debugging by someone on a Cygwin platform. I'd start by checking what r is (i.e., what's the return value). Then try to come up with a simple test case of a condition variable, etc. Note condition variables are also used during garbage collection. What happens when you run a program that invokes System.gc() ? The other fixes you mention I've committed in r380969, except as noted below... 8. in libjc\zip.c pread(..) replaced with lseek + read calls This fix is really a workaround that introduces a new race condition (when two threads are reading from the same ZIP file at the same time). More work is required, e.g., adding a mutex. I'll add this to my list, or if you have a candidate patch email it to me. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] problems with gnu classpath and also jchevm builds
Weldon Washburn wrote: Next, I tried to configure JCHEVM. I think the top-level directory is supposed to have a configure file. Its not there. I did an svn update jchevm. It shows, At revision 381045. But still no configure file. I have svn version 1.3.0 installed. Check out the APACHE.README in the top level directory. It describes how to bootstrap jchevm to get a buildable distribution from the SVN sources. If you have access to a Linux machine that would be another way to avoid the Cygwin porting issues. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Harmony tools and utilities
Stepan Mishura wrote: FYI, jchevm contains a javah program (called jcjavah for now). Are you planning to move it to harmony/enhanced/tools? A version needs to stay with jchevm (required for the build) but there's no reason it couldn't be copied there also. It does also use a few other files from the vm library, so they would have to go too. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Artem Aliev wrote: There is no free() memory call. You could destroy only whole memory pool. This works well only for short living threads or tasks. This is typical for HTTP server, not Java application. (All apr_*_create functions require apr_pool_t* as argument) I tried to create sub-pool for each object as workaround. This hits memory footprint and performance. So APR memory model should be extended. For example portlib memory pools could be integrated into APR. You can always still use plain old malloc(), right? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: Today I've made changes to eliminate the requirement that _JC_FULL_ALIGNMENT be at most sizeof(_jc_word), so this will fix the assertion in heap.c. Just compared my local version with svn repository at Harmony project.. Don't see any changes. Do you commit this changes in JCVM repository ? Yes, r378953. Sorry for bothering you. This number is something not very clear for me. I'm not guru in CVS but I just checkouted latest JCVM from sourceforge ...latest modifications dates are 21.01.2006 How and where can I get diff for this changes to apply it for my local JCHEVM installation ? You seem to be checking out JCVM, which is not the same as JCHEVM. You need to use Subversion (not CVS) for JCHEVM and point it at https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm Also.. today started working on assertions.. This one in vm.c under cygwin JC_ASSERT(vm-threads.prio_min = vm-threads.prio_max); caused by a bit strange implementation of * *sched.cc on cygwin (source can be found here: http://www.koders.com/cpp/fidFCD804607170E62E066B115DCE4FCB2BEA405E30.aspx ) All functions operates (accept as params and returns) with unix-like thread priorities, mapping it to reverse windows style priorities. But for some strange reasonsched_get_priority_max (int policy) and sched_get_priority_min (int policy) return windows style reverse priorities from 15(min) to -14(max) Just defined wrapping functions in i386_libjc.h and used these functions instead of original ones. Can you report this bug back to the Cygwin developers? I checked in a version of your fix as r379838. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Artem Aliev wrote: You can always still use plain old malloc(), right? Unfortunately, all apr_*_create functions require apr_pool_t* as argument. I meant, if you have some function that just needs to allocate some heap memory temporarily, you can use malloc() directly .. as if APR were not even present. I.e., you don't have to use APR for *everything*. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Harmony tools and utilities
Stepan Mishura wrote: Tool name Status Priority javadoc missing high javah missing medium keytool missing medium policytool missing low klist missingN/A FYI, jchevm contains a javah program (called jcjavah for now). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: Today I've made changes to eliminate the requirement that _JC_FULL_ALIGNMENT be at most sizeof(_jc_word), so this will fix the assertion in heap.c. Just compared my local version with svn repository at Harmony project.. Don't see any changes. Do you commit this changes in JCVM repository ? Yes, r378953. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] Cygwin issues
Enrico Migliore wrote: Archie Cobbs wrote: Today I've made changes to eliminate the requirement that _JC_FULL_ALIGNMENT be at most sizeof(_jc_word), so this will fix the assertion in heap.c. hope that doesn't sacrifice any of the features of jchevm Nope.. it's all gain and no pain :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [classlib] build / test system
David Tanzer wrote: A friend of mine is currently developing a program to manage Java project resources (jars and others) called gc resource repository (gc-rr): http://dev.guglhupf.net/commons/rr/index.html Some of the features are: * Central resource repository to share resources between multiple projects. * Needed resource are downloaded and stored in a local repository. * Dependencies between resources are solved. * Setup the classpath with all needed resources (jars). * Start java progams with the needed resources. * Ant integration to setup the classpath. * Modular ant build script support * Eclipse classpath builder to setup the classpath in eclipse. You may want to take a look at it. It is distributed under the Apache License, and I guess I could convince Rene Pirringer (the main developer of gc-rr) to contribute it to Apache Harmony if this is desired. FYI, this sounds very similar to Jpackage.org... is it supposed to be better somehow? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Enrico Migliore wrote: great! I'll try it tomorrow on my PC. I think there are still quite a few things to fix on Cygwin, because, for example, if we enable the assertions, JCHEVM exits. The results we've got are encouraging though :-) Archie: what are we supposed to do now? Today I've made changes to eliminate the requirement that _JC_FULL_ALIGNMENT be at most sizeof(_jc_word), so this will fix the assertion in heap.c. As for the failure to exit properly, this is probably related to the assertion on line 1023 of thread.c (which you said was failing in a previous email on Cygwin). This will take some further debugging.. there may be a bug in the handing of the vm_destruction condition variable but since I don't see the assertion it may be easier for you guys to debug it. I'll try a visual inspection though. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: Well one more question. In file jchevm\libjc\arch\i386\i386_libjc.h there wasn't branch for cygwin as result compilation failed with Unsupported O/S for i386 machine context functions message.. Someway I defined this inline function _jc_jmpbuf_sp(const sigjmp_buf buf) but guess I did it wrong way. Do you know how to do it correctly? You just have to figure out where the stack pointer is saved in a sigjmp_buf and pull it out. But in any case this function is only used for garbage collection. If you avoid GC then it doesn't matter what this function returns (except for the assertion in stack.c, which you can disable). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
snowdosker wrote: Please share the link you've found :-) Here is similar problem in postgress and some explanations http://archives.postgresql.org/pgsql-cygwin/2003-11/msg00024.php I don't have Cygwin but it appears that something like the attached patch should work. If so let me know and I'll commit it. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: libjc/arch/i386/i386_definitions.h === --- libjc/arch/i386/i386_definitions.h (revision 378678) +++ libjc/arch/i386/i386_definitions.h (working copy) @@ -31,5 +31,10 @@ #define _JC_BIG_ENDIAN 0 +#ifdef __CYGWIN__ +#undef _JC_LIBRARY_FMT +#define _JC_LIBRARY_FMT cyg%s.dll +#endif + #endif /* _ARCH_I386_DEFINITIONS_H_ */
Re: compiling JCHEVM with GCC/Cygwin
snowdosker wrote: vm.c - line 46 message = assertion failure: _JC_FULL_ALIGNMENT = (sizeof(_jc_word)) This assertion is there because we align the start of an object with the first reference (which is in front of the object header). The fix for this is to modify the code to align non-array objects on 8 byte boundaries even if they have an odd number of reference words (yuck). This requires changing the algorithm for determining object size and heap block size, as well as skip word handling, etc. (blah blah gnarly internals). However, I'm curious why double alignment is 8 under Cygwin but only 4 under Linux but both are x86. Obviously that can't derive only from the hardware. So for now I'd say just comment out that assertion and proceed. If you get funny floating point results then we'll know why :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] native method API for _jc_new_intern_string -- do you plan to add to _jc_ilib_entry table?
Tim Ellison wrote: sure -- String interning is in the kernel precisely so that the VM implementor (i.e. you) can choose to do it in native or Java code. Of course, they have to be interned into the same table as the JLS string literals. Of course :-) JCHEVM handles this correctly. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [classlib] build / test system
Geir Magnusson Jr wrote: So to that end, I'd like to set things up so that by default, we use the eclipse compiler, but that means that people have to go through a [painful] process to get the jars (2 of them) - namely if you don't have Eclipse installed, you have to go get it and dig two jars out. I'd like to set things up so we don't have to put in ant/lib to make it less intrusive to people - we could have a local lib dir and do that maybe. Anyway, anyone have strong feelings or suggestions? I haven't been paying close attention so this may be a dumb question... what about using jikes? Jikes is nice for Java VM projects where you have a bootstrap problem associated with Java compilers themselves written in Java. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] native method API for _jc_new_intern_string -- do you plan to add to _jc_ilib_entry table?
Weldon Washburn wrote: I am working on kernel_path String.java. It wants to call a native method to do the intern work. If you plan to add a native method that does String intern, I won't spend the time doing interning in Java code. I think this code is related to _jc_ilib_entry table. Do you have thoughts on the best approach? The best approach (imho) is to do interning in Java, using a WeakHashMap, which is perfect for the task. The Classpath implementation is a mere 10 lines or so. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Weldon Washburn wrote: I agree with most everything you said below. The Thread class is indeed tricky. I can't look at GNU Classpath code as I am doing this port. I want kernel_path to be Apache licensed and not a GPL Not looking is certainly a safe approach, but make sure you don't unnecessarily restrict yourself. Re-implemnting an algorithm in your own words is not a copyright violation. And certainly there's less at stake with Classpath code than e.g. looking at Sun's code. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Geir Magnusson Jr wrote: The state of things now is that the VM API defined by Classlib is, well, not very well defined :-) That's not actually true. We may be missing documentation or something, but the Harmony Classlib VM API is a well-tested production API used by IBM in their commercial VM offerings. Hard to argue with that. That's why the IBM J9 VM that was offered for evaluation purposes just works. My understanding from Weldon's emails is that while it's true that Classlib runs on J9, that's true because J9 provides its own glue for Classlib to make things work. To make Classlib run on any other VM, there would still be a lot of work that needs to be done, which fortunately Weldon is already forging ahead on (if you don't believe me, compare the two java.lang.Thread classes I mentioned (Classpath's and Classlib's) for example). My comment is simply that there would be *lots* of benefits if the bottom of this glue layer we're developing is the same as the VM API that Classpath uses, and moreover this is actually the easiest path to take anyway. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Weldon Washburn wrote: I like your idea of zero mods to JCHEVM. I will attempt to localize all mods to Classlibrary's Kernel Classes. Maybe this set of modified Kernel Classes could be used by any VM that runs GNU Classpath. I will try some experiments with java class name space to see if we can create wrappers that satisfy all the stakeholders. Sounds great! -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Geir Magnusson Jr wrote: I like your idea of zero mods to JCHEVM. I will attempt to localize all mods to Classlibrary's Kernel Classes. Maybe this set of modified Kernel Classes could be used by any VM that runs GNU Classpath. I assume you're talking about making a glue layer that the standard Harmony Classlibrary can work with? Yes.. will try some experiments with java class name space to see if we can create wrappers that satisfy all the stakeholders. TO me, the ideal is to have a very clear demarcation of what is the Harmony Classlibrary VM interface. So I'd see Harmony VM Interface -- Harmony/Classpath Adapter -- JCHEVM Is this what you mean? Yes.. that's the basic near term idea... (although technically if the adapter is written in Java (as we've discussed) then the Harmony VM interface is not really a VM interface). However I think ideally Classlib's API should be implemented to be equal Classpath's API. That may sound strange so let me try to explain why. The state of things now is that the VM API defined by Classlib is, well, not very well defined :-) Compare Classlib's Thread.java: trunk/modules/kernel/src/main/java/java/lang/Thread.java with these files from Classpath: http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17root=classpathview=markup http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9root=classpathview=markup Note every method in Classlib's Thread.java is: return null. On the other hand, Classpath's API is much more complete and fully developed, race conditions have been analyzed and handled, SecurityManager implications have been taken into account, etc. To get Classlib to the same level, you'd have to duplicate a whole bunch of (at times very tricky and subtle) work -- not only implementing the API, but figuring out what the right API is -- that's already been figured out over several years in Classpath. In short there is lots of unimplemented stuff remaining in Classlib's existing API. From a simple argument of expediency, not to mention the benefits for debugging previously mentioned, adopting the already baked Classpath API makes lots of sense. For example: if there's more than one Harmony VM, you'd have to have a different version of the complicated adapter glue for each one. Instead, why not write the glue once, include it as part of Classlib, and make the VM interface really be a native interface, instead of a big grey area. Plus there's already a working example of what the glue should look like to base it on. There's also this important principle lurking here, which has been learned over the years in Classpath: if there's a choice between implementing something in Java or forcing the VM to implement it, it's almost always preferable to implement it in Java. Java is much easier to debug, and you only have to debug it once - not N times for each of N VM implementations. FYI, the Classpath Java/VM API is defined by the files in this subtree: http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/?root=classpath -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Geir Magnusson Jr wrote: I think that doing our implementations using APR is a solid way to go. A good place to start looking is JCHEVM and BootVM... I haven't looked at APR in detail, but the O/S requirements of the VM proper are not that involved and I'm sure APR could handle them. There's probably more corner case requirements from the class library's native code, as that stuff implements most of Java's I/O, networking, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Weldon Washburn wrote: Do you know if anyone is working on a port of Harmony Classlib to JCHEVM? If false, I would like to start this port. I can't guarantee I have time to finish the port but intend to at least sketch out what needs to be done so that others can join the effort. I don't know of anyone working on it yet. That would be great to do some exploration. Since JCHEVM already works with the VM interface defined by Classpath, as much re-use of that API as possible makes a lot of sense. If we can't import Classpath files directly (which itself is stupid and highly ironic imho, but that's another discussion) then we can write new files that provide the same API (doing that should not have any copyright problems). From my initial glances the Classpath API is often lower level than the Classlib API, so all that would be needed in theory is to fill the resulting gap with some Java code glue. I have started looking at JCHEVM to figure out how to glue the Harmony Classlibrary kernel classes (see …modules/kernel/src/main/java/java/lang/*.java) to the native entry points listed in jchevm/libjc/native_lib.c. The goal is to make only absolutely essential mods to JCHEVM code. Ideally, there would be zero changes to JCHEVM. All the glue would reside in JCHEVM's private copy of Classlib's kernel classes. The overlay approach, which works well. Because the wrapper is adding a layer of identically named methods and thus potentially really confusing the name space, I renamed java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray(). All the enties in _jc_ilib_table[ ] would also be decorated with wrapper. Is that really necessary? It seems to me that the existing JCHEVM native API can remain intact. There are great advantages in being able to run JCHEVM with both Classlib and Classpath at the same time for debugging purposes (not to mention Classlib on J9). The more combinations you can try, the easier it is to hone in on a bug's source. So I'd strongly prefer that the Java/VM API remain the same as much as possible. Certainly this can be done with the right overlay classes. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Building harmony/enhanced/jchevm from svn
Jean-frederic Clere wrote: Hi, I have the following problem: +++ etc/Makefile.am:5: invalid variable `dist_jcetc_DATA' include/Makefile.am:13: invalid variable `nodist_jc_include_HEADERS' automake: libjc/Makefile.am: not supported: source file `native/gnu_classpath_VMStackWalker.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/gnu_classpath_VMSystemProperties.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/java_lang_VMClass.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/java_lang_VMClassLoader.c' is in subdirectory ... +++ When running etc/makedist.sh --with-classpath=/usr. What version of automake do you have? I'm using 1.9.6. I'm not an automake expert; my only guess is that your version is too old to support dist_* and nodist_* targets ... ? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
Enrico Migliore wrote: pread() problem - In the zip.c file, I temporarily substituted the pread() call with the following two calls: lseek(fd,offset,SEEK_SET); read(fd,buf,len); Those are perfectly equivalent to pread() except that they are not atomic That is a reasonable workaround; it's not thread safe however. In practice is probably won't matter though. You'd have to be loading the same class at the same time from two different class loaders for that to matter (highly unlikely). problems -- jc.exe enters the main function and crashes at the first call, which is _jc_invoke(); In order to investigate the problem I did the following thngs: 1. Commented _jc_invoke() and added a dummy poptGetContext() call. It crashes 2. Commented _jc_invoke() and added a printf(Hello World!); It doesn't crash and print the message to the stdandard output It seems to me that the problem is the calling convention. I don't know enough about Windows or Cygwin to help here. Can you run it under GDB? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
Enrico Migliore wrote: The bad news is that the RedHat guys hasn't ported ucontext library to Cygwin. The good one is that: 1. You call just one of the 4 ucontext library functions, and you call it in just one source file (stack.c) 2. I've found an example explaining how to port the ucontext library in Cygwin (Don't know if it works though) Good, hopefully #2 will work. The use of ucontext is pretty critical, because otherwise we could leak references and accidentally GC an object still in use. Actually there could be an alternative implementation using setjmp(), I'll look into that if time permits. zip problem I downloaded the source code of zip-2.3 and, at line 373 of zip.c, I got this: #ifdef MACOS Sorry, I meant JCHEVM's zip,c: jchevm/libjc/zip.c. Looks like the pread(3) function is not working properly under Cygwin. This error occurs on line 373 of zip.c if you want to try to debug it (sorry, I'm Windows illiterate). Yet, I can't find, in the Zip source files, the the pread( ) function that you told me about pread(3) is something that Cygwin would supply, not zip. I.e., it's part of the standard C library (per Unix98). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
Enrico Migliore wrote: After compiling some C source files, thoug, it stopped saying: jcjavah: can't load class 'gnu/classpath/VMStackWalker': java/io/IOException: error reading entry 'gnu/classpath/VMStackWalker.class' in ZIP file 'usr/local/classpath/share/classpath/glibj.zip': No error make[2]: *** [gnu_classpath_VMStackWalker.h] Error 1 (Note that VMStackWalker.class is present in my zip file: /usr/local/classpath/share/classpath/glibj.zip) Looks like the pread(3) function is not working properly under Cygwin. This error occurs on line 373 of zip.c if you want to try to debug it (sorry, I'm Windows illiterate). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
Enrico Migliore wrote: P.S. During the compilation phase, that is, before stopping on the mentioned error, the compiler issues the following warning: gcc: unrecognized option '-pthread' I've removed this configure hack, which is no longer needed. P.S. I put the ucontext.h file in the dirs: /include and /include/sys at the moment they are empty That's a bad sign.. :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Proposal to relocate jchevm
Hi all. I'm planning to move jchevm from: enhanced/trunk/sandbox/contribs/jchevm/jchevm to: enhanced/jchevm i.e., to move it out of the sandbox. Let me know if anyone has any issues. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: editing the website
Tim Ellison wrote: Heads-up that I tweaked the website http://svn.apache.org/viewcvs?rev=369469view=rev Archie: can you do something for the JCHEVM builds/downloads Sure.. I'm out of town now but will be back on Weds. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: windoze download
Geir Magnusson Jr wrote: Take a look at this page for links to Harmony's (build it yourself) Windows and Linux class library code, and where to get a compatible VM: http://people.apache.org/~tellison/building_classlib.html Please stop with the personal pages - put on the main website. It's trivial to use. Not trivial for me, guess I'm just dumb... :-) I.e., you still haven't explained how. I managed to find /x1/www/incubator.apache.org/harmony on svn.apache.org but I can't write to that directory. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: windoze download
Geir Magnusson Jr wrote: I managed to find /x1/www/incubator.apache.org/harmony on svn.apache.org but I can't write to that directory. Great question. Our website - svn co https://svn.apache.org/repos/asf/incubator/harmony/standard/site That's the whole website for the tree. I thought I had the readme in there, but alas. I'll put it in. Simple form : 1) edit the document in xdocs/ 2) type ant in site/ root (implies you have ant installed) 3) look at the changes in docs/ 4) repeat #1 until happy 5) svn commit 6) ssh to minotaur 7) cd /www/incubator.apache.org/incubator/harmony 8)`cat UPDATE` That's it to publish. So are you saying to publish a snapshot tarball I should do this? If so that's fine.. just want to make sure though because it means committing tarballs into the repository. In any case, something is still broken. I don't have permission to modify /www/incubator.apache.org/incubator/harmony on minotaur: drwxr-xr-x 4 geirm apcvs 1024 Dec 16 22:33 /www/incubator.apache.org/harmony You need to chmod g+w /www/incubator.apache.org/harmony. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Publishing a JCHEVM snapshot
Geir Magnusson Jr wrote: Ok - lets do this. Lets make this repeatable - I put that in quotes becuase our toolchain configs are tough right now, but we do want to be working towards repeatability. So lets write down how we do it, make sure it's scripted, and do it - so Tim does it for the classlib, and archie for the JCHEVM, but lets work towards being able to automate completely (i.e. let the systme do the nightly). Once you have that in place, bellow - we'll put them on svn.apache.org/snapshots/incubator-harmony/ I'll go create that so any committer can move code there. When anyone puts up a snapshot, please send a short note to the list for the record (so we know where the binaries that are there came from...) I'd like to better understand this process... Does snapshots/incubator-harmony contain the scripts to build the snapshots, or the snapshots themselves? Seems like the latter wouldn't make any sense.. we don't want to check in redundant tarballs of code that lies elsewhere in the tree do we? (Besides, if this is going to be totally scripted, we don't want scripts to have to make commits.) If the directory contains scripts, how do they get run? Seems like we'll need some svn:externals on that directory so the code we're building gets checked out below, so the script has something to build.. then what should the script do with the resulting tarball (or RPM, etc)? Just leave it in that directory or copy it somewhere? I.e, how does what gets built end up on a web page somewhere where people can download it? Etc.. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
