[drlvm] src/test side-by-side with vm and build?
Hi,
in the below commit Geir has added several dozens files
under
drlvm/trunk/src/test
Since we have two directories on the top-level, build with build
system, and vm with everything else (sources, tests, documentation),
it seems very confusing to have 'src' directory at the top level.
Some time ago DRLVM team had very hot debates on directory structure,
and we ended up with following structure:
drlvm/trunk
+ vm
+ vmcore
+ jitrino
+ ... (other components)
+ doc (documentation)
+ tests (tests)
+ include (header files)
+ build(build system)
The tests that are now checked into src/test look like they are put to a
wrong place.
More correct place would be something like
vm/tests/verifier
Pavel, could you suggest a convenient place for your verifier tests?
--
Salikh Zakirov, Intel Middleware Products Division
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 8:31 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r428043 - in
/incubator/harmony/enhanced/drlvm/trunk: src/test/verifier_aastore/
src/test/verifier_aastore/src/ src/test/verifier_empty_init/
src/test/verifier_empty_init/src/ vm/vmcore/src/verifier/
Author: geirm
Date: Wed Aug 2 09:30:51 2006
New Revision: 428043
URL: http://svn.apache.org/viewvc?rev=428043&view=rev
Log:
HARMONY-973
Add check for empty init method
Also added both test sets included in JIRA to
src/test for further integration
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tAastore2.j
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
tInterface.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/HowT
o.txt (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
Test.java (with props)
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_empty_init/src/
TestEmptyInit.j
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_datafl
ow.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier/ver_utils.
cpp
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_aastore/HowTo.txt?rev=428043&view=auto
==
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt Wed Aug 2 09:30:51 2006
@@ -0,0 +1,14 @@
+How to compile and run test:
+
+1) To compile you need to have a Jasmin version 1.1.
+This can be downloaded from http://jasmin.sourceforge.net
+
+2) The Jasmin distribution contains a jasmin.jar file holding the
Jasmin assembler.
+To compile sources execute the following commands:
+
+$ java -jar /jasmin.jar src/*.j
+$ javac -d . src/*.java
+
+3) To run test execute the following command:
+
+$ java Test
Propchange:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/HowTo.t
xt
--
svn:eol-style = native
Added:
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/src/
test/verifier_aastore/src/Test.java?rev=428043&view=auto
==
---
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java (added)
+++
incubator/harmony/enhanced/drlvm/trunk/src/test/verifier_aastore/src/Tes
t.java Wed Aug 2 09:30:51 2006
@@ -0,0 +1,14 @@
+public class Test {
+public static void main(String[] args) {
+// verify aastore instruction
+try {
+new TestAastore().test();
+System.out.println("TestAastore: failed");
+} catch (LinkageError e) {
+System.out.println("TestAastore: passed: " + e);
+} catch (Throwable e) {
+System.out.println("TestAastore: failed: unexpected error "
+ e);
+e.printStackTrace();
+}
+ }
+}
\ No newline at end of file
Propchange:
incubator/harmony/enhanced/drlvm/trun
[general] Commit comments
Geir, I believe it is probably unintentional, but you have forgot to include any comment on what the change does to the code. I think we should strive to make commit messages self-sufficient. Specifying JIRA issues can be nice, but in the long run, it is not very convenient to have to look up external database just to find out what the change is about. Can we agree on principles how to construct commit messages? -- Salikh Zakirov, Intel Middleware Products Division -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 1:44 AM To: [EMAIL PROTECTED] Subject: svn commit: r427749 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/jni/jni.cpp Author: geirm Date: Tue Aug 1 14:43:57 2006 New Revision: 427749 URL: http://svn.apache.org/viewvc?rev=427749&view=rev Log: HARMONY-835 committed patch and tested on linux Would be nice to have test cases to illustrate the problems... Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/jni/jni.cpp Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/jni/jni.cpp URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/v mcore/src/jni/jni.cpp?rev=427749&r1=427748&r2=427749&view=diff == --- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/jni/jni.cpp (original) +++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/jni/jni.cpp Tue Aug 1 14:43:57 2006 @@ -810,7 +810,7 @@ return 0; } -CallVoidMethodA(env, new_handle, methodID, args); +CallNonvirtualVoidMethodA(env, new_handle, clazz, methodID, args); if (ExceptionCheck(env)) return NULL; else - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove --non-interactive from svn commaind line in svn-prop (HARMONY-980)
Geir, I thought HARMONY-980 was intended for enhanced/drlvm/trunk/build/make/build.xml Could you please apply the change there too? Thanks a lot! -- Salikh Zakirov, Intel Middleware Products Division -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 2:40 AM To: [EMAIL PROTECTED] Subject: svn commit: r427776 - /incubator/harmony/enhanced/trunk/build.xml Author: geirm Date: Tue Aug 1 15:40:12 2006 New Revision: 427776 URL: http://svn.apache.org/viewvc?rev=427776&view=rev Log: HARMONY-980 tweak to federated build script for those w/ svn clients that don't support "--non-interactive" option. I'm not entirely convinced we need it anyway for anyone properly setup... Modified: incubator/harmony/enhanced/trunk/build.xml Modified: incubator/harmony/enhanced/trunk/build.xml URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/trunk/build.xml? rev=427776&r1=427775&r2=427776&view=diff == --- incubator/harmony/enhanced/trunk/build.xml (original) +++ incubator/harmony/enhanced/trunk/build.xml Tue Aug 1 15:40:12 2006 @@ -431,7 +431,6 @@ - - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: removed String.java
Hi Mark, DRLVM developers, it looks like the issue HARMONY-666 to remove String and StringBuffer was not accompanied with corresponding update of org.apache.harmony.kernel.vm.VM (move intern() native method from String to VM). As I am planning to do some experiments with string interning in DRLVM, it caught my interest and I looked into it. The fix is attached to HARMONY-721. By the way, there are some other issues with current state of DRLVM, as the following smoke tests (run by 'build.sh test') fail on Linux/ia32: util.DoPrivileged classloader.LogLoader classloader.SysRes I'm going to bisect recent commits to find the failure cause. -- Salikh Zakirov, Intel Middleware Products Division -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 29, 2006 12:58 PM To: [EMAIL PROTECTED] Subject: svn commit: r417969 - in /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/jav asrc/java/lang: String.java StringBuffer.java Author: hindessm Date: Thu Jun 29 01:57:36 2006 New Revision: 417969 URL: http://svn.apache.org/viewvc?rev=417969&view=rev Log: Applied changes from "[#HARMONY-666] String & StringBuffer should be removed from the DRLVM sources". Removed: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/java src/java/lang/String.java incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/java src/java/lang/StringBuffer.java - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DRLVM contribution - try this out!
> I took a brief look at the code and the documentation, and noticed > that DRLVM is written in C++ instead of plain C. > Is there any particular reason for using C++? DRLVM reuses some C++ code from earlier Intel research projects (of course, code origin was carefully tracked and certified), and developers had more C++ experience, so C++ was natural choice. By the way, some parts of DRLVM are in Java and C. The interfaces between dynamically linked components are extern "C", and most of the complicated C++ features are used very moderately, so plugging in C code is easy. > Could you briefly tell us the story of DRLVM? DRL = dynamic runtime layer I hope we could write the rest of the story for "Harmony VM" :) -- Salikh Zakirov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compiling JCHEVM with GCC/Cygwin
Hi, > "The application failed to initialize properly (0xc005)". > Any ideas what does it mean? > I guess library linking problems. But have no ideas which one cause it. Do you have cygwin1.dll in the PATH? you may want to use 'depends.exe' or 'dumpbin.exe /dependents' from Microsoft SDK or 'objdump --private-headers' from Cygwin distribution to find out what specific dynamic libraries jc.exe depends on.
[vm] finalization subsystem design
Hi,
I would like to discuss a design of finalization subsystem.
Note, that these are my thoughts only, they have not been
really implemented yet. Some of the design
issues are still not clear, so I am looking forward to hear
your opinion.
Thanks a lot!
==
0. Introduction.
The detailed design I am going to discuss is based on the following
high-level
design:
* at allocation time, all finalizable objects are registered
with
live finalization queue. Dead finalization queue is initially
empty.
* all finalizable objects are kept alive
while referenced from finalization queue, either from live
or dead queue.
* every once in a while, the GC initiates the process of
finalization
detection. The GC scans objects from live finalizable queue one
by one, and moves some of them to the dead finalization queue.
* a dedicated finalization thread (or several threads)
asynchronously check if the dead finalization queue
is not empty, and runs finalize() method for those objects.
The reference to objects is then dropped from
the dead finalization queue.
* finalized objects, which are no more referenced either from
finalization
queue or static fields are reclaimed by the GC in exactly the
same way
as ordinary java objects.
0. Data structure: Finalization queue
The finalizable object queue may be implemented in a number of ways,
and the most appealing one is to keep it all within the java heap.
Keeping finalizable queue within the java heap will give following
"for free":
* the shortage of memory for finalizable queue automatically
results in OutOfMemoryError
* the memory availability in java heap is more predictable
than native heap memory availability
* reclamation of memory used by the finalization queue and
finalizable objects is done automatically by the GC.
For example, the following java class may be used to keep both the live
finalization queue and dead finalization queue:
class FinalizationQueue {
FinalizationQueue next; // null-terminated
linked list
Object[] array; // the storage of the
queued objects
int live; //
array[0..live-1] are live objects
int dead; //
array[live..live+dead-1] are dead objects
}
Generally, I do not expect that the sequential organization
of finalization queue will cause any performance issues, as most of the
operations with finalization queue are sequential anyway.
1. GC interface
The finalization subsystem interacts with the GC on three occasions
* allocation of finalizable object
* promotion of finalizable object from live to dead queue
* enumeration of the root set of the finalizable queue
These interaction can be implemented in following interface
ManagedObject* f_object_allocated(ManagedObject* obj)
void f_handle_finalization_queue()
bool gc_is_object_live(ManagedObject* obj)
void f_enumerate_roots()
void gc_add_root_set_entry(ManagedObject** root)
Prefix "f_" denotes functions provided by the finalization subsystem,
that the GC will call, and prefix "gc_" denotes GC callbacks.
The context for these functions is the GC interface, suggested earlier
by Weldon Washburn in
http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/atta
chments/gc_interface.txt.
The GC will interact with the finalization subsystem in the following
way:
- on a object allocation, the GC checks if the object class has
finalize()
method overridden by calling (class_is_finalizable()).
If the GC finds out that just allocated object is finalizable,
it calls f_object_allocated().
- finalization subsystem receives a newly allocated finalizable
object
reference and registers it with a live finalization queue.
Registration in the queue may require other object allocation,
which in turn may cause garbage collection.
Finalization subsystem returns object pointer after it registers
it successfully. It may return NULL if the registration was not
successful due to shortage of memory.
Some care must be taken to protect the pointer to the allocated
objects if other allocations take place, because any allocation
may cause garbage collection, and the garbage collection may
move objects.
- The finalization subsystem returns the object pointer to GC,
and the GC passes it further to the caller of allocation
function.
- Later, some time in the middle of the next garbage collection
cycle
after the GC has completed tracing and marking of strongly
reachable
objects, the GC calls f_handle_finalization_queue().
- The finalization subsystem iterates ove
