Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 This is a great news! On 21/10/06, Weldon Washburn [EMAIL PROTECTED] wrote: +1 On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of when a community gets organized enough to vote itself out of the Incubator, it's appropriate. So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it hosted by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division -- Best regards, Pavel Rebriy
Re: [drlvm][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
Regarding patching generation of native callback, function gen_native_readinternal() doesn't use in VM and this is a dead code. As to me it should be eliminated. -s = mov(s, M_Base_Opnd(esp_reg, 0), Imm_Opnd((int)jni_native_intf)) ; // o0=jni_native_intf +s = mov(s, M_Base_Opnd(esp_reg, 0), Imm_Opnd((int)p_TLS_vmthread-jni_env)) ; // o0=jni_native_intf Regarding patching SingleStep, it's so trivial patch I think it can be applied with issue with or without it TI doesn't work anyway. Anyway, I vote for a quick inclusion of this patch. Good point!. -- Best regards, Pavel Rebriy
Re: [drlvm][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
The fix is ready. See http://issues.apache.org/jira/browse/HARMONY-1826 On 10/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Pavel Rebriy wrote: Hello, Fix for Harmony-1582 brocks initialization of JVMTI support. I'm investigating the problem and going to create fixing JIRA as soon as possible. Great - thanks P.S. May be include several JVMTI tests into build test. Yes, please do. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
[drlvm][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
Hello, Fix for Harmony-1582 brocks initialization of JVMTI support. I'm investigating the problem and going to create fixing JIRA as soon as possible. P.S. May be include several JVMTI tests into build test. -- Best regards, Pavel Rebriy
Re: [drlvm] too tired, need help
File vm/vmcore/src/init/vm_main.cpp, line 68.
Global_Env env(m, properties);
On 06/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I know the type. The question is where is that variable env declared
and set?
geir
Weldon Washburn wrote:
The first parameter to create_vm() is of type Global_Env.
Global_Env is defined in environment.h
vm_init() in vm_init.cpp initializes a bunch of Globla_Env's members.
On 10/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to trace through the boot sequence chasing some boot
classpath property thing (luniglob sets it, and I can't figure how it
gets to us...), and I'm too tired, too dumb, or both to figure this
out.
Launcher calls JNI_CreateJavaVM. In our vmcore/src/jni/jni.cpp, we
define it, and it is :
VMEXPORT jint
JNICALL JNI_CreateJavaVM(JavaVM **p_vm, JNIEnv **p_env, void *vm_args)
{
static int called = 0;
init_log_system();
TRACE2(jni, CreateJavaVM called);
if (called) {
ASSERT(0, Not implemented);
return JNI_ERR;
} else {
create_vm(env, (JavaVMInitArgs *)vm_args);
*p_env = jni_env;
*p_vm = jni_env.vm;
return JNI_OK;
}
}
For the life of me, I can't figure out where env is defined or set.
create_vm() uses it...
Can anyone give me a hint? Eclipse's C++ plugin seems to be useless
here...
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Pavel Rebriy
Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code
I've just repeated kernel.test run today several times on fresh build, and tests pass. It's a very stange crash. Execute JIT stack iterator in interpreter mode.. It's outlandishly. On 28/09/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I do not observe this crash - I ran kernel tests yesterday and today several times, no crashes on interpreter on Linux IA32... 2006/9/28, Gregory Shimansky [EMAIL PROTECTED]: On Wednesday 27 September 2006 16:35 Geir Magnusson Jr. wrote: sob :) Is there an easy fix, or do we rollback? Interpreter is meant for the development for the most part. I think it is not critical if it doesn't work for a short time. It is not used by most of the community anyway because they don't specify -Xint option to run the programs. I hope the patch submitter will respond with a fix soon enough. -- Gregory Shimansky, 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
Re: [drlvm] sanity check - can someone build from svn and test ActiveMQ?
Ok, I'll try to explain it.
Function vf_resolve_class with true as the second parameter asks class
loader to load a class with a given class name. If the second parameter
equals to false, function just checks if a given class is loaded, and get it
if it is.
The patch claims that if class loader tries to load a given class and fails
and then asks it to lookup among loaded classes it appears to be
successfully loaded. That is a class is failed to load, but it is
successfully loaded in VM. It could work only is a class loader is bugged.
On 17/08/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Right - what I was worried about was that I *thought* that
HARMONY-956 got me to where Gergory is describing, but he's applying
HARMONY-1179.
I'll just stop worrying about this for the snapshot, post it, and
move on w/ 1179 and keep going.
Thanks all for looking into this - I could *swear* that 956 had a
visible effect, but I was clearly mistaken.
And what is dutty hacking? :)
geir
On Aug 17, 2006, at 8:11 AM, Pavel Rebriy wrote:
Anton, your patch is a dutty hacking.
With and without the patch ActiveMQ crashes as Gregory described.
On 17/08/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
Please try to apply patch
Index: vm/vmcore/src/verifier/ver_utils.cpp
===
--- vm/vmcore/src/verifier/ver_utils.cpp(revision 432184)
+++ vm/vmcore/src/verifier/ver_utils.cpp(working copy)
@@ -1391,6 +1391,9 @@
// get stack reference class
class_handler source = vf_resolve_class( constraint-source,
true,
ctex );
+if(source == NULL) {
+ source = vf_resolve_class( constraint-source, false, ctex );
+}
if( !source ) {
VERIFY_DEBUG( verifying class class_get_name( ctex-
m_class
)
(method method_get_name( constraint-method )
Unfortunately I cannot attach it to the JIRA issue because the
issue is
closed.
On 8/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to create snapshots, and when testing w/ ActiveMQ, I
still
have the same problems w/ ActiveMQ as reported originally in
HARMONY-956.
Can someone do a sanity check? it's a release build.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
Regards,
Anton Luht,
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: harmony-dev-
[EMAIL PROTECTED]
--
Best regards,
Pavel Rebriy
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Pavel Rebriy
Re: [drlvm] sanity check - can someone build from svn and test ActiveMQ?
Anton, your patch is a dutty hacking.
With and without the patch ActiveMQ crashes as Gregory described.
On 17/08/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
Please try to apply patch
Index: vm/vmcore/src/verifier/ver_utils.cpp
===
--- vm/vmcore/src/verifier/ver_utils.cpp(revision 432184)
+++ vm/vmcore/src/verifier/ver_utils.cpp(working copy)
@@ -1391,6 +1391,9 @@
// get stack reference class
class_handler source = vf_resolve_class( constraint-source, true,
ctex );
+if(source == NULL) {
+ source = vf_resolve_class( constraint-source, false, ctex );
+}
if( !source ) {
VERIFY_DEBUG( verifying class class_get_name( ctex-m_class
)
(method method_get_name( constraint-method )
Unfortunately I cannot attach it to the JIRA issue because the issue is
closed.
On 8/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I'm trying to create snapshots, and when testing w/ ActiveMQ, I still
have the same problems w/ ActiveMQ as reported originally in
HARMONY-956.
Can someone do a sanity check? it's a release build.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
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]
--
Best regards,
Pavel Rebriy
Re: [vote] acceptance of HARMONY-856 : assorted bug fixed for DRLVM
+1 And I wrote about restrictions to verifier patches. On 23/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-856 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
[VM] Bytecode Subroutine Verification
There are several virtual machines in Harmony project and none of them provides subroutine verification for Java bytecode. I would like to discuss appropriate methodology of subroutine verification. In Java bytecode, subroutines represent code in finally construction. The use of such subroutines makes bytecode analysis very difficult. Fortunately, modern compilers eliminate usage of subroutines through inlining. Subroutine verification approach described in the Java Virtual Machine Specification 2nd Edition has a fundamental limit and rejects a legal Java code. The limit is inherent to approach of tracking modified variables and selectively propagating from ret to jsr instructions. A possible approach is to inline subroutines for bytecode verification. After inlining, the simpler data flow analysis can be run. In certain cases it's not clear how to define subroutine boundaries for inlining so in general, some analysis is needed to define subroutines' boundaries. The question is whether it is better to inline subroutines and then run a simpler data flow analysis, or to run directly a more complex data flow analysis. -- Best regards, Pavel Rebriy
Re: [jira] Created: (HARMONY-919) [drlvm] Verifier: invokespecial instruction check fix
Hello, I'd like to explain the correct work of verifier with invokespecial instruction. There are 2 structural constraints in Java VM Specification which are directly related with invokespecial instruction: 1. About methods that instruction must invoke. 2. About protected methods invocation. These constraints apply restrictions on a type of object instance for invokespecial instruction. If invokespecial instruction invokes an instance initialization method, the type of the class instance being accessed must be the direct super class of invoked method class. If instruction invokes another method, the type of the class instance being accessed must be the same as or a subclass of the current class. Verifier checks both these cases. Volunteers are welcome to fix the issue described in Harmony-919! On 19/07/06, Pavel Rebriy (JIRA) [EMAIL PROTECTED] wrote: [drlvm] Verifier: invokespecial instruction check fix - Key: HARMONY-919 URL: http://issues.apache.org/jira/browse/HARMONY-919 Project: Harmony Issue Type: Bug Components: VM Reporter: Pavel Rebriy I've found a bug in DRLVM: verifier incorrectly checks invokes by invokespecial instruction as requested by Java VM Specification. Test tries to invoke public method of super class by invokespecial instruction and type of object is the direct super class of current class. To run the test use the following command: path to drl vm/bin/ij Test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Best regards, Pavel Rebriy
Re: [jira] Updated: (HARMONY-788) [drlvm] Verifier: parameters and dimensions limit checks fix
During the first pass through bytecode verifier builds an instruction array of the method. While building the instruction array verifier checks constraints for each processed instruction. For instance, for instruction working with local variables verifier checks a range of local variable index, for constant pool index – range of constant pool index and type of constant pool entry, and so on. Java VM Specification has a limitation for arrays dimensions (it's limited to 255). There are 2 instructions which create multi-dimensional arrays – anewarray and multianewarray. The limitation should be checked for these instructions. Checking it verifier constructs a type of created array and counts a number of dimensions and check the limit. Besides array dimensions Java VM Specification has a limit for number of a method arguments (the limitation is 255 arguments). Parsing a descriptor of an invoked method verifier counts the number of arguments and checks if it exceeds the limit. The test which checks the limitations seems to be quite synthetic but verifier should be able to correctly process all classes loaded by VM. On 06/07/06, Pavel Rebriy (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-788?page=all ] Pavel Rebriy updated HARMONY-788: - Attachment: 0001-Verifier-parameters-and-dimensions-limit-checks-fix.patch Patch to fix the problem. [drlvm] Verifier: parameters and dimensions limit checks fix Key: HARMONY-788 URL: http://issues.apache.org/jira/browse/HARMONY-788 Project: Harmony Type: Bug Components: VM Reporter: Pavel Rebriy Attachments: 0001-Test.zip, 0001-Verifier-parameters-and-dimensions-limit-checks-fix.patch I've found a bug that DRLVM verifier doesn't check array dimensions and method parameters limits as requested in Java VM Specification. Test checks multianewarray instruction array dimensions and number of arguments for invokevirtual, invokespecial, invokeinterface and invokestatic instructions. To run test use the following command: path to drl vm/bin/ij Test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Best regards, Pavel Rebriy
Re: [drlvm] what's next?
On 29/06/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Andrey Chernyshev wrote: Hello, In addition to the already proposed generic tasks like 5.0 support or concurrent GC mentioned by Ivan, I'd like to add some more specific things that might be interesting for people to look at as well: (1) Complete Java bytecode verifier Class structure verification and subroutines (e.g. finally blocks) has to be added to the bytecode verifier in order to make it full-functional (as required by JVMS spec). Do you think that it will be complete at that point? It's my understanding that it's fairly difficult and subtle to get it right. I'm hoping that we can just get that from Sun :) IMHO, developing of verifier is not so difficult. Is it subtle? - yes, but not difficult. It is not harder then developing of JIT :) (2) Handling out of C memory conditions VM must throw OutOfMemoryException when there is a lack of C memory. For example, if local or global handle cannot be allocated then OOME should be thrown – OutOfMemoryException must be thrown (this is required by JNI/JVMTI spec). What does it do now? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Besides, verifier code should be updated to support Java 5 changes. On 22/06/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Geir, Not sure at what level of detail you are asking, but we need some changes in the DRLVM class support code to handle the new class format. These include the acc_synthetic , acc_annotation etc. access modifiers, the new attrs like enclosingClass, runtime visible/invisible attrs, signatures for generics support and the class/interface naming convention changes etc. There should be some small changes in the interpreter and JIT to support the ldc CONSTANT_Class . There are possibly some minimal associated changes to the kernel classes also even without the full implementation of annotation, reflection etc. kernel classes as Alexey pointed out on the previous 1.5 thread. Rana On 6/22/06, Tim Ellison [EMAIL PROTECTED] wrote: There are modest changes to the classfile format that need to be supported; once they are in place we can remove the compiler-hack. Regards, Tim Geir Magnusson Jr wrote: It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
Re: [VOTE] Acceptance of HARMONY-211 : Contribution of java.rmi
+1 On 09/05/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I have received the ACQs and the BCC for Harmony-211 in paper form and have reviewed them, so I can assert that the critical provenance paperwork is in order. It is not in SVN yet, but I wanted to get this vote going at the same time as the Intel contribution in the same area. I will get scanned and in SVN ASAP. This is the contribution from ITC. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below Lets let this run 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Pavel Rebriy
