Re: [drlvm][unit] 100% of class library tests pass

[Alexey Varlamov]

2006/11/16, Tim Ellison [EMAIL PROTECTED]:

Pavel Ozhdikhin wrote:
 We have to evolving systems - classlib and DRLVM. To check commits to
 classlib we need a stable DRLVM which can pass 100% of HUT. Otherwise it's
 impossible to use DRLVM for pre-commit testing - you never know whether
 your
 test fail because of your patch or due to latest changes in DRLVM.

 I remember the time when DRLVM and Jitrino actively evolved - for some time
 JIT had to use an older version of DRLVM which could pass all commit
 criteria because newer versions suffered from regressions. And finally we
 came to comon strict commit criteria which prevented regressions in both VM
 and JIT.

 To avoid regressions using DRLVM in classlib testing I see 3 possible
 solutions:

 1. Use one fixed DRLVM version which can pass 100% HUT test. Update this
 version from time to time.
Pros: + Less time to run DRLVM pre-commit tests
  + Classlib does not suffer from regressions in DRLVM
Cons: - DRLVM will suffer from regressions
   - Classlib can not use the latest DRLVM
   - Need additional efforts to regain stability on DRLVM
 when we want to update the version for classlib testing

 2. Add HUT to CruiseControl testing on DRLVM and rollback commits causing
 regressions
Pros: + Less time to run DRLVM pre-commit tests
  + Classlib can use the latest DRLVM
Cons: - Classlib can suffer from DRLVM regressions (time lag before
 rollback)
   - It is not always clear which commit caused a regression
   - Rollbacks are costly

 3. Add HUT to the commit criteria for DRLVM
 Pros: + Classlib always can use the latest DRLVM
   + DRLVM has no regressions regarding to HUT
 Cons: - More time to run DRLVM pre-commit tests (I was told that HUT
   take 25 minutes running in single JVM mode)

 I think that preventing a problem is better than solving it afterwards. So,
 I personally would choose the 3rd approach, don't mind against the second
 and dislike the first one. Probably some combination of these is possible.

While I appreciate the desire to keep things stable, I think it is
unreasonable to ask developers to run the entire test suite each time.
As we have seen in the classlib code, running targeted tests before
commit and leaving the build machines to run continuous tests ensures
that we are productive and are notified of breakages in time to easily
back out a patch and re-evaluate.

With the amount of machine time we have running harmony tests on
different cpu's/os's/compilers/etc we are getting better coverage than
any individual could be expected to provide.

Which is a long way of saying I think option (2) above is best -- and
relies on the bid machines letting us know if things break, and the
commitment from all of us to go straight in and fix it.


I can't say it better. Thank you Tim :)
Maybe just to reinforce:
1) We have absolutely stable model VM for classlib verification - j9
it's name. Therefore I really don't think DRLVM can affect classlib's
progress disruptively.
2) Yes, there are times when some component advances in leaps as
against accustomed smooth evolution. I do believe we'll be able to
manage such cases individually, w/o overburdening everyday activities.



Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [drlvm] [testing] Excluding commit tests until the problem is fixed

[Alexey Varlamov]

+1
I like this approach too - more flexible than current.

2006/11/16, Vladimir Ivanov [EMAIL PROTECTED]:

On 11/16/06, Tim Ellison [EMAIL PROTECTED] wrote:

 Vladimir Ivanov wrote:
  As part of solution for this issue the
  *HARMONY-2197*http://issues.apache.org/jira/browse/HARMONY-2197 was
  created.
 
  I suggest using the separate exclude list for each platform. I hope in
 this
  case the test enabling for the different platforms will be easy. Please,
  look at it.
 
  Any comments are welcome :)

 Maybe a dumb question by why hard-code

 property name=hy.test.vm.name value=ibm /

 Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
 a short form suitable as a directory name?



Actually, this property is defined before the test run by Ant's VM. In my
case it is

'Java HotSpot(TM) Client VM'.



As variant, the java from 'test.jre.home' may be run with -version option
and output may be parsed and mapped to some value. In this case all Harmony
VM should support this option and print different messages. Is it OK?



I suggest implementing version with hard coded vm name and than extend it by
auto-detecting capability.



 Thanks, Vladimir



 Regards,
 Tim

 --

 Tim Ellison ([EMAIL PROTECTED])
 IBM Java technology centre, UK.

Re: [drlvm][em64t] build fails

[Alexey Varlamov]

16 Nov 2006 14:48:05 +0600, Egor Pasko [EMAIL PROTECTED]:

On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
 Gregory Shimansky wrote:
  Geir Magnusson Jr. wrote:
 
 
  Gregory Shimansky wrote:
 
  -Xss is the lower stack limit, it doesn't specify the maximum
  stack size, doesn't it?
 
  What does lower stack limit mean? :)  I think that it's the size
  of the stack, max.
  I thought it is a starting stack size, like -Xms for heap size. Now
  that I searched the web it appears that it is the maximum indeed.

 0 is minimum stack size.

 
  I think all you need to do then is set the stack size :
 
 ulimit -s 8192
 
  or something.  We should probably do this before each run on linux
  so that things are well defined and reproducible.
  I think 64-bit SuSE9 is just the only weird distribution which
  doesn't have this limit. In 10th version they fixed this. So ulimit
  -s is not necessary in most cases.

 But harmless.  And it makes the test predicable across platforms.  and
 if the StackSize test is forked, we can make it small to make it
 quick...

I know nothing about forking Java processes. Does it make sense?
Secondly, fork() is fast regardless of the stack size (stacks are COW).


Determinative time here is test execution time, not forking time. The
point is to make SOE happen quickly instead of stressing host machine.



  I'd still like to have a recursion limit in StackTest but Rana has
  convinced me that no SOE shouldn't mean that test has failed. I'll
  patch it now.
 

 I agree that your fix is utterly bogus :) but we want to test SOE
 machinery, so I think that we should set the ulimit to ensure an
 environment in which the SOE will happen if DRLVM is working
 right. Therefore, we need to set things up such that not getting an
 SOE is indeed a failure.

What a user would most likely expect on a system with no stack limit?
Something like on the other systems with stack limit as in
run-anywhere concept. And that would be SOE, not swapping.  So, let's
limit the stack by, say, 10M if not set with an option. We can
implement the option later.

This is arguable - remember essays about users frustrated by
artificial Java heap limits :)
Another point can be slightly different meaning for -Xss on RI and
DRLVM, the latter has united stack as opposite to separate Java stack
on RI...



--
Egor Pasko

Re: [performance] a few early benchmarks

[Alexey Varlamov]

Stefano,

It is a bit unfair to compare *debug* build of Harmony with other
release versions :)
I suppose all VMs where run in default mode (i.e. no special cmd-line switches)?

2006/11/17, Stefano Mazzocchi [EMAIL PROTECTED]:

There are lies, damn lies and benchmarks which don't really tell you
if an implementation of a program is *faster* but at least it tells you
where you're at.

So, as Geir managed to get the DSO linking problem go away in DRLVM, I
was able to start running some benchmarks.

The machine is the following:

Linux harmony-em64t 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16
01:50:50 UTC 2006 x86_64 GNU/Linux

dual Intel(R) Pentium(R) D CPU 3.20GHz
bogomips 6410.31 (per CPU)

There is nothing else running on the machine (load is 0.04 at the time
of testing).

The various virtual machines tested are:

harmony
---
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java version 1.5.0
pre-alpha : not complete or compatible
svn = r476006, (Nov 16 2006), Linux/em64t/gcc 4.0.3, debug build

sun5
---
java version 1.5.0_09
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b03, mixed mode)

sun6

java version 1.6.0-rc
Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-rc-b104, mixed mode)

ibm
---
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build
pxa64dev-20061002a (SR3) )
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64
j9vmxa6423-20061001 (JIT enabled)
J9VM - 20060915_08260_LHdSMr
JIT  - 20060908_1811_r8
GC   - 20060906_AA)
JCL  - 20061002

bea
---
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
BEA JRockit(R) (build
R26.4.0-63-63688-1.5.0_06-20060626-2259-linux-x86_64, )


--

Test #1: java scimark2 (http://math.nist.gov/scimark2/)

command: java jnt.scimark2.commandline

NOTE: bigger number is better

Sun6
Composite Score: 364.5832265230057
FFT (1024): 220.8458713892794
SOR (100x100):   696.1542342357722
Monte Carlo : 149.37978088875656
Sparse matmult (N=1000, nz=5000): 326.37451873283845
LU (100x100): 430.1617273683819

BEA
Composite Score: 359.13480378697835
FFT (1024): 303.8746880751562
SOR (100x100):   454.25628897202307
Monte Carlo : 93.23913192138497
Sparse matmult (N=1000, nz=5000): 530.44112637391
LU (100x100): 413.8627835924175

Sun5
Composite Score: 332.84987587548574
FFT (1024): 216.5144595799027
SOR (100x100):   689.429322146947
Monte Carlo : 25.791262124978065
Sparse matmult (N=1000, nz=5000): 317.5193965699373
LU (100x100): 414.99493895566377

IBM
Composite Score: 259.8249218693683
FFT (1024): 296.8415012789055
SOR (100x100):   428.974881649179
Monte Carlo : 89.15159857584082
Sparse matmult (N=1000, nz=5000): 144.3524241203982
LU (100x100): 339.8042037225181

Harmony
Composite Score: 113.65082278962575
FFT (1024): 203.76641991778123
SOR (100x100):   224.37761309236748
Monte Carlo : 9.063866256533116
Sparse matmult (N=1000, nz=5000): 65.4051866327227
LU (100x100): 65.6410280487242

In this test harmony is clearly lagging behind... at about 30%
performance of the best JVM, it's a little crappy. Please note how FFT's
performance is not so bad awhile monte carlo is pretty bad compared to
BEA or IBM.

Overall, it seems like there is some serious work to do here to catch up.

--

Test 2: Dhrystones (http://www.c-creators.co.jp/okayan/DhrystoneApplet/)

command: java dhry 1

NOTE: bigger is better

NB: I modified the code to accept the count at input from the command line!

sun6: 8552856 dhrystones/sec
sun5: 6605892
bea:  5678914
harmony:   669734
ibm:   501562

The performance here is horrific but what's surprising is that J9 is
even worse. No idea what's going on but it seems like something is not
working as it should (in both harmony and J9)

--

Test 3: Sieve (part of http://www.sax.de/~adlibit/tya18.tgz)

command: java Sieve 30

NB: I modified the test to run for a configurable amount of seconds.

sun6 8545 sieves/sec
sun5 8364
bea  6174
harmony  1836
ibm   225

IBM J9 clearly has something wrong on x86_64 but harmony is clearly
lagging behind.

Stay tuned for more tests.

--
Stefano.

Re: [general][testing] cruise control on the WinXP and SUSE linux

[Alexey Varlamov]

Apparently this is a long awaited working (at least for drlvm
testing), I'll be utterly surprised if somebody objects. Thank you!
Here is My Big +1 :)

15.11.06, Vladimir Ivanov[EMAIL PROTECTED] написал(а):

Hello everyone,
I started cruise control (stored in the buildtest module with patch from
issue 995) on the Windows XP and SUSE Linux boxes.
Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD).

On each platform cruise control runs (as separate projects in СС terms, all
settings have default values):
 - build of classlib module (target: 'rebuild');
 - classlib tests on J9 VM (target 'test' in the classlib module);
 - build of drlvm module (target: 'build');
 - vm tests (kernel+smoke+cunit, target: 'test' in the drlvm module);
 - classlib tests on DRL VM (target: 'test' in the classlib module with -
Dtest.jre.home=drlvm);

Is it OK to send my cruise control notifications to the harmony-commits list
in order to notify about regressions?

I suspect the notifications are not ideal but I will work on their
improvement upon precedents (false alarms) and your feedback

 Thanks, Vladimir

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:

Alexey Varlamov wrote:
 The guilty change is the following, which effectively turns on
 VM_LAZY_EXCEPTION support in exceptions_impl.cpp:

Well this is a patch from HARMONY-2018 which doesn't hide the fact that
it enables lazy exceptions. Why shouldn't we enable them?


The point is not that we should or should not enable them, rather the
fact that the regression appeared due to this change. I just tried to
localize the problem hoping it will help to resolve this regression
soon instead of reverting.



Actually if you revert the patch (I've tried) this doesn't seem to fix
the test. At least the exceptions are still there, not sure about test
PASSED status.


Verbose test output is confusing but itself does no harm. I found so
far the following:
1) the test fails on this assertion (ClassGenericsTest4.java:799):
if (!(e.getCause() instanceof java.lang.reflect.GenericSignatureFormatError)) {
   fail(test_3, case 003 FAILED: GenericSignatureFormatError should
be risen.);
}
because of e.getCause() returns null. That is, lazy machinery drops
the cause of InvocationTargetException, I did not yet figured out why.
2) Test report provides the following diagnostics:
java.lang.NullPointerException at
junit.framework.TestCase.runTest(TestCase.java:168). This seems to
point to the same problem: lost cause exception after reflection.



 Modified:
 
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp

 URL:
 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diffrev=475029r1=475028r2=475029

 ==

 ---
 
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp

 (original)
 +++
 
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp

 Tue Nov 14 14:45:45 2006
 @@ -26,6 +26,7 @@
 #include Class.h
 #include classloader.h
 #include exceptions.h
 +#include exceptions_impl.h
 #include exceptions_jit.h
 #include exceptions_type.h
 #include environment.h

 So the problem most probably in exn_throw_by_class_internal()
 function, will look closer after lunch.

 2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
 Heh, this regression is more interesting than it looked at first glance:
 JITs give the same output with identical stack trace, but test result
 is PASSED.
 By lucky chance I have older debug build at hand (svn = r474646) and
 it also spills this stacktrace to system err but status is PASSED for
 all execution engines.
 Looks like smth hase changed in exceptions processing for interpreter.

 2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
  Hello
 
  Today a kernel tests which used to pass a day ago started to fail.
 It is
  java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert
 some VM
  and classlib (since some important classes like URLClassLoader,
 Hashtable and
  TreeMap were changed recently) patches but no reversion helped. It
 may be a
  cumulative effect of the patches now makes the test fail.
 
  It fails somewhere deep inside of signature parser. The problem is
 also that
  class format parses uses antlr which makes the whole parsing quite
 complex.
  The failure happens on a BadSignatureTemplate class which is
 constructed from
  bytes, parsed and its method is invoked. Apparently it has a wrong
 signature
  (surprise :) ).
 
  The whole purpose of the test is not clear to me more surprising is
 that it
  works on RI (not on BEA). If someone could point to what may be
 wrong now
  with this test I would be very grateful.
 
  I also wonder why there is no InvocationTargetException which should be
  chained with the down the stack Exception. The test_3 method uses
 reflection
  to invoke a method BadSignatureTemplate.test_1 which in its turn
 threw an
  Exception in parser. Shouldn't there be an InvocationTargetException
 as the
  result of Method.invoke?
 
  Where can I look at BadSignatureTemplate.java, specifically line 13
 which
  according to the stack called Class.getTypeParameters?
 
  [1]
 
  [EMAIL PROTECTED]:
  10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint
 
-Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar
 -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
  junit.textui.TestRunner java.lang.ClassGenericsTest4
 
 
/lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class

  java.lang.Exception
 at
 
 
org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)

 at antlr.TokenBuffer.fill(TokenBuffer.java:69)
 at antlr.TokenBuffer.LA(TokenBuffer.java:80)
 at antlr.LLkParser.LA(LLkParser.java:52)
 at
 
 
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:

2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
 Alexey Varlamov wrote:
  The guilty change is the following, which effectively turns on
  VM_LAZY_EXCEPTION support in exceptions_impl.cpp:

 Well this is a patch from HARMONY-2018 which doesn't hide the fact that
 it enables lazy exceptions. Why shouldn't we enable them?


Gregory,

I've just re-read my posts and couldn't find anything critique or
offending - please don't take regressions too personal. I'm sure we
will be able to fix this one quite soon.
--
Peace,
Alexey





The point is not that we should or should not enable them, rather the
fact that the regression appeared due to this change. I just tried to
localize the problem hoping it will help to resolve this regression
soon instead of reverting.


 Actually if you revert the patch (I've tried) this doesn't seem to fix
 the test. At least the exceptions are still there, not sure about test
 PASSED status.

Verbose test output is confusing but itself does no harm. I found so
far the following:
1) the test fails on this assertion (ClassGenericsTest4.java:799):
if (!(e.getCause() instanceof java.lang.reflect.GenericSignatureFormatError)) {
   fail(test_3, case 003 FAILED: GenericSignatureFormatError should
be risen.);
}
because of e.getCause() returns null. That is, lazy machinery drops
the cause of InvocationTargetException, I did not yet figured out why.
2) Test report provides the following diagnostics:
java.lang.NullPointerException at
junit.framework.TestCase.runTest(TestCase.java:168). This seems to
point to the same problem: lost cause exception after reflection.


  Modified:
  
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
 
  URL:
  
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diffrev=475029r1=475028r2=475029
 
  
==
 
  ---
  
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
 
  (original)
  +++
  
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
 
  Tue Nov 14 14:45:45 2006
  @@ -26,6 +26,7 @@
  #include Class.h
  #include classloader.h
  #include exceptions.h
  +#include exceptions_impl.h
  #include exceptions_jit.h
  #include exceptions_type.h
  #include environment.h
 
  So the problem most probably in exn_throw_by_class_internal()
  function, will look closer after lunch.
 
  2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
  Heh, this regression is more interesting than it looked at first glance:
  JITs give the same output with identical stack trace, but test result
  is PASSED.
  By lucky chance I have older debug build at hand (svn = r474646) and
  it also spills this stacktrace to system err but status is PASSED for
  all execution engines.
  Looks like smth hase changed in exceptions processing for interpreter.
 
  2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
   Hello
  
   Today a kernel tests which used to pass a day ago started to fail.
  It is
   java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert
  some VM
   and classlib (since some important classes like URLClassLoader,
  Hashtable and
   TreeMap were changed recently) patches but no reversion helped. It
  may be a
   cumulative effect of the patches now makes the test fail.
  
   It fails somewhere deep inside of signature parser. The problem is
  also that
   class format parses uses antlr which makes the whole parsing quite
  complex.
   The failure happens on a BadSignatureTemplate class which is
  constructed from
   bytes, parsed and its method is invoked. Apparently it has a wrong
  signature
   (surprise :) ).
  
   The whole purpose of the test is not clear to me more surprising is
  that it
   works on RI (not on BEA). If someone could point to what may be
  wrong now
   with this test I would be very grateful.
  
   I also wonder why there is no InvocationTargetException which should be
   chained with the down the stack Exception. The test_3 method uses
  reflection
   to invoke a method BadSignatureTemplate.test_1 which in its turn
  threw an
   Exception in parser. Shouldn't there be an InvocationTargetException
  as the
   result of Method.invoke?
  
   Where can I look at BadSignatureTemplate.java, specifically line 13
  which
   according to the stack called Class.getTypeParameters?
  
   [1]
  
   [EMAIL PROTECTED]:
   10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint
  
-Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar
  -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
   junit.textui.TestRunner java.lang.ClassGenericsTest4
  
  
/lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
 
   java.lang.Exception

Re: [general][testing] cruise control on the WinXP and SUSE linux

[Alexey Varlamov]

15.11.06, Gregory Shimansky[EMAIL PROTECTED] написал(а):

Vladimir Ivanov wrote:
 Hello everyone,
 I started cruise control (stored in the buildtest module with patch from
 issue 995) on the Windows XP and SUSE Linux boxes.
 Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD).

 On each platform cruise control runs (as separate projects in СС terms, all
 settings have default values):
 - build of classlib module (target: 'rebuild');
 - classlib tests on J9 VM (target 'test' in the classlib module);
 - build of drlvm module (target: 'build');
 - vm tests (kernel+smoke+cunit, target: 'test' in the drlvm module);
 - classlib tests on DRL VM (target: 'test' in the classlib module with -
 Dtest.jre.home=drlvm);

 Is it OK to send my cruise control notifications to the harmony-commits
 list
 in order to notify about regressions?

 I suspect the notifications are not ideal but I will work on their
 improvement upon precedents (false alarms) and your feedback

I am +1 for cruise control and notifications to harmony-commit.

But I wonder about linux version choice. If it is SuSE9, then could we
upgrade it to SuSE10 or install another distribution like FC5 with gcc
4.1.x? This will help a lot with compilation errors which gcc 3.3.3 on
SuSE9 doesn't report.

Good point, I support this.
--
Alexey



--
Gregory

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:

Alexey Varlamov wrote:
 2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
 Alexey Varlamov wrote:
  The guilty change is the following, which effectively turns on
  VM_LAZY_EXCEPTION support in exceptions_impl.cpp:

 Well this is a patch from HARMONY-2018 which doesn't hide the fact that
 it enables lazy exceptions. Why shouldn't we enable them?

 The point is not that we should or should not enable them, rather the
 fact that the regression appeared due to this change. I just tried to
 localize the problem hoping it will help to resolve this regression
 soon instead of reverting.


 Actually if you revert the patch (I've tried) this doesn't seem to fix
 the test. At least the exceptions are still there, not sure about test
 PASSED status.

 Verbose test output is confusing but itself does no harm. I found so

Ah this explains it. When I tried to investigate the regression I've
reverted the patch and tried the test alone. I saw exceptions and
thought that the test failed. I didn't realize that it is just an output.

 far the following:
 1) the test fails on this assertion (ClassGenericsTest4.java:799):
 if (!(e.getCause() instanceof
 java.lang.reflect.GenericSignatureFormatError)) {
fail(test_3, case 003 FAILED: GenericSignatureFormatError should
 be risen.);
 }
 because of e.getCause() returns null. That is, lazy machinery drops
 the cause of InvocationTargetException, I did not yet figured out why.

I see. If the problem appears to be hard to solve we should revert the
HARMONY-2018 patch.


What really confuses me, why this failure is interpreter specific?
AFAIU functions for creating exceptions are common, so the root cause
may be in stale exceptions due to improper cleanup somewhere...



 2) Test report provides the following diagnostics:
 java.lang.NullPointerException at
 junit.framework.TestCase.runTest(TestCase.java:168). This seems to
 point to the same problem: lost cause exception after reflection.

--
Gregory

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

Err, what I found is really trivial bug. But it took quite a few time
to discover - seems today was not my day :(

Index: vm/vmcore/src/exception/exceptions_impl.cpp
===
--- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
+++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
@@ -281,7 +281,7 @@

if (NULL != exception-exc_cause) {
tmn_suspend_disable_recursive();
-jthrowable exc_cause = oh_allocate_local_handle();
+exc_cause = oh_allocate_local_handle();
exc_cause-object = exception-exc_cause;
tmn_suspend_enable_recursive();
}


OK, we definitely need a regression test for this.

2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:

Alexey Varlamov wrote:
 2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
 2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
  Alexey Varlamov wrote:
   The guilty change is the following, which effectively turns on
   VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
 
  Well this is a patch from HARMONY-2018 which doesn't hide the fact that
  it enables lazy exceptions. Why shouldn't we enable them?

 Gregory,

 I've just re-read my posts and couldn't find anything critique or
 offending - please don't take regressions too personal. I'm sure we
 will be able to fix this one quite soon.

I wasn't offended in any way. I was just thinking that you know some
secret knowledge that lazy exceptions do not work and thus enabling them
is wrong.

--
Gregory

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

Pardon for my English - a bit sleepy already...

2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:

Err, what I found is really trivial bug. But it took quite a few time
to discover - seems today was not my day :(

Index: vm/vmcore/src/exception/exceptions_impl.cpp
===
--- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
+++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
@@ -281,7 +281,7 @@

if (NULL != exception-exc_cause) {
tmn_suspend_disable_recursive();
-jthrowable exc_cause = oh_allocate_local_handle();
+exc_cause = oh_allocate_local_handle();
exc_cause-object = exception-exc_cause;
tmn_suspend_enable_recursive();
}


OK, we definitely need a regression test for this.

2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
 Alexey Varlamov wrote:
  2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
  2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
   Alexey Varlamov wrote:
The guilty change is the following, which effectively turns on
VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
  
   Well this is a patch from HARMONY-2018 which doesn't hide the fact that
   it enables lazy exceptions. Why shouldn't we enable them?
 
  Gregory,
 
  I've just re-read my posts and couldn't find anything critique or
  offending - please don't take regressions too personal. I'm sure we
  will be able to fix this one quite soon.

 I wasn't offended in any way. I was just thinking that you know some
 secret knowledge that lazy exceptions do not work and thus enabling them
 is wrong.

 --
 Gregory

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

2006/11/16, Gregory Shimansky [EMAIL PROTECTED]:

Alexey Varlamov wrote:
 Err, what I found is really trivial bug. But it took quite a few time
 to discover - seems today was not my day :(

 Index: vm/vmcore/src/exception/exceptions_impl.cpp
 ===
 --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
 +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
 @@ -281,7 +281,7 @@

 if (NULL != exception-exc_cause) {
 tmn_suspend_disable_recursive();
 -jthrowable exc_cause = oh_allocate_local_handle();
 +exc_cause = oh_allocate_local_handle();
 exc_cause-object = exception-exc_cause;
 tmn_suspend_enable_recursive();
 }

Cool. Could you please commit the fix?


Committed along with regression testcase at r475590.



 OK, we definitely need a regression test for this.

 2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
 Alexey Varlamov wrote:
  2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
  2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
   Alexey Varlamov wrote:
The guilty change is the following, which effectively turns on
VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
  
   Well this is a patch from HARMONY-2018 which doesn't hide the
 fact that
   it enables lazy exceptions. Why shouldn't we enable them?
 
  Gregory,
 
  I've just re-read my posts and couldn't find anything critique or
  offending - please don't take regressions too personal. I'm sure we
  will be able to fix this one quite soon.

 I wasn't offended in any way. I was just thinking that you know some
 secret knowledge that lazy exceptions do not work and thus enabling them
 is wrong.

 --
 Gregory





--
Gregory

Re: [classlib][testing] Showing test failures (Re: [drlvm] New regression: java.lang.ClassGenericsTest4)

[Alexey Varlamov]

2006/11/16, Tim Ellison [EMAIL PROTECTED]:

Rana Dasgupta wrote:
 I think that a problem with the junit tests is that some failures spit out
 to the console, but show up in the test run results as passed. I find this
 very confusing. So unless you are watching all the time, you can miss them.

Hmm, this doesn't sound right.  I've not seen classlib tests fail but be
reported in the html report as passed.  Is that what you meant? (I
realize your mail subject was [drlvm] but just checking.)

One confusing aspect is that the classlib ant build fails if you run the
tests 'globally', but passes if you run the tests in a single module.


Yes, this was a nasty surprise for me when I saw exactly this
sutiation few days ago; I just had no time to speak up. We definitely
should fix this.



We could fix that by making the current test sequence an internal target
(for the 'global' test), and checking for failures after a 'modular' test.

e.g.

Index: build.xml
===
--- build.xml   (revision 474801)
+++ build.xml   (working copy)
@@ -41,8 +41,19 @@

target name=build depends=compile-java, copy-resources,
build-jar /

-target name=test depends=build, compile-tests, run-tests /
+target name=test depends=-test
+fail message=Some tests failed
+condition
+or
+isset property=test.failures /
+isset property=test.errors /
+/or
+/condition
+/fail
+/target

+target name=-test depends=build, compile-tests, run-tests /
+
target name=clean
delete file=${hy.jdk}/jre/lib/boot/beans.jar /
delete file=${hy.jdk}/jre/lib/boot/beans-src.jar /


That would be more intuitive to me, so unless anyone objects I'll do it.


Absolutely reasonable solution, please do. Thank you so much!

--
Alexey



Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

Well, we all learned the lesson. Here are my own thoughts, and some
more answers are inlined:
1) Explicit separate testing for all execution engines (JET, OPT,
interpreter) is really valuable; so far we found bugs in many
components including classlib (!), especially due to interpreter. I
bet JIT guys will soon beseech for the same in classlib testing, at
least by CI :)
2) Time required to run all pre-commit tests for DRLVM is near to
inadmissible. I believe this is the main reason why patch submitters
may not exercise them truly. Another reason is poor diagnosticdebug
services of available build infrastructure.
We really need to think how we can improve it - e.g. using sameVM
mode as much as possible, provide more reliable and convenient results
reporting, more unified harness, etc.
3) It would be nice to invest some efforts to cleaning  sorting out
available tests, smoke and kernel first of all. I suspect there might
be some duplication in coverage, and it certainly does present between
DRLVM-kernel and classlib-luni suites. Ideally we would merge them
into common VM-kernel.

2006/11/16, Gregory Shimansky [EMAIL PROTECTED]:

Alexei Fedotov wrote:
 Guys,

 This is a good discussion, and let me praise Alexey for the wonderful fix.

 I'm a bit concerned about our accepptance checks. How this could be
 that regression was missed by a committer and an engineer durring
 acceptance test runs?

 Bug comments showed that Gregory ran the tests before a commit. Do
 tests report such problems clearly?

I saw that they failed on interpreter and saw an additional failure by
ClassGeneticsTest4, but when I reverted the patch I ran the test
individually (because running kernel tests is quite a long task). I saw
exceptions output from ClassGeneticsTest4 with reverted patch and
decided that it wasn't the one to blame. I tried reverting other patches
but all of them produced the same output. Today Alexey explained to me
that exceptions output was just a verbose test output not to related to
test passed/failed status. So the answer to your question is not very
clearly :)

Well, junit always output total status after run, just some practice
is needed to distinguish between noise and vital output :) But me too
dislikes stacktraces in output very much.


After I saw that reverting the patches doesn't help very much I decided
that regression somehow slipped earlier but wasn't noticed. The problem
with kernel tests is that they don't pass stably. Often j.l.ThreadTest
fails and j.l.RuntimeTest2 fails on XP. So I thought that negative
result of kernel tests run was assumed to be ok because
ClassGeneticsTest4 failure was not noticed since some tests which fail
often failed.

Unfortunately yes, drlvm tests and kernel in particular gained some
mournful reputation. But in fact, they (mostly) failed justly. Now
DRLVM becomes more mature and we should adopt zero regression policy
soon.


The output of kernel tests is not very good too. They run 3 times on
JET, OPT and interpreter. The last output is for interpreter, and if the
output prints PASSED it is necessary to check result for JET and OPT. I
think the tests should either fail/ after the first test run which
didn't pass (similar to how smoke tests stop tests execution), or print
a summary at the end for all 3 runs with fail/ if case any of them
didn't pass.

1) Fail-fast behaviour is not very informative, especially if
instability faced. It might be useful to enforce zero regression
rule, but I vote for run them all mode. BTW, this is how classlib
tests behave and this is just convenient. Yet we may want to add a
cmd-line switch ala haltonfailure in junit task.
2) I agree about more informative summary, will take care.

[snip]

--
Alexey

Re: [drlvm][unit] 100% of class library tests pass

[Alexey Varlamov]

2006/11/16, Mikhail Loenko [EMAIL PROTECTED]:

why not?

But what benefit it would bring? build test in DRLVM takes too much
time already, I'm afraid people will just stop using it :(

This is analogous to enforcing full testing in classlib for every
change regardless of module. Evidently this is too expensive.



2006/11/16, Geir Magnusson Jr. [EMAIL PROTECTED]:


 Pavel Ozhdikhin wrote:
  On 11/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 
  Be sure to not miss anyone :)  This was a great community effort, with
  everyone pitching in.
 
  DRLVM is now a full peer  to J9 in Harmony testing.  :)  We still need
  to use J9 (and another VM that happens to work with our classlibrary),
  as a sanity check, but we should from now on use DRLVM in our CI testing
  framework.
 
 
  On the other hand, to make sure DRLVM has no regressions regarding
  to Classlibrary Unit Tests it makes sense to add these tests to the test
  target of DRLVM build.
  What do people think?

 Adding classlib unit tests to DRLVM test target?  No thanks :)

 geir

 
  Thanks,
  Pavel
 
 
 
  geir
 
 
  Alexei Fedotov wrote:
   Oops, I've missed:
   * Andrew Zhang for reviewing class library patches and helpful
  discussions
  
   On 11/16/06, Alexei Fedotov [EMAIL PROTECTED] wrote:
  
   Folks,
   According to http://harmonytest.org, today 100% of class library unit
   tests pass on DRLVM. Thank you all! It takes 44 days for the great
   team we are. Thanks for your thoughtful, diligent work and deep
   inspiration. Kudos to you for the following (and not limited to this):
  
   * Alexey Varlamov and Elena for driving the whole process
   * Anton and Vladimir Ivanov for automating test runs
   * Geir and Gregory for checking and committing related DRLVM patches
   * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and
   committing related class library patches
   * Alexey Petrenko for becoming ICU expert and writing good JIRA issue
   resolution guidelines
   * Alexei Zakharov for resolving class library test issues
   * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for
   fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay
   Sidelnikov and Alexander Astapchuk for making execution engines work
   * Tatiana and Maxim for filing JIRA issues about test failures
   * Nikolay Kuznetsov for completing thread interruption handling and
   reverting consequences of park/unpark integration
   * Pavel Afremov for fixing exception handling
   * Boris Kuznetsov for intelligent fixing of security tests
   * Rana and Salikh for evaluating and discussing problems, reviewing
   and trying DRLVM patches
   * Pavel Pervov and Evgueni for help with DRLVM patches
   * Artem for discovering and fixing weird Windows* behavior
   * My wife for bringing hot tea to the computer during sleepless nights
  
   There are still open issues with reliability, multiprocessor and other
   special configurations, so the page
   http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains
   active. But this shouldn't prevent us from including class library
   testing into Harmony zero regression policy. What do you think?
  
   --
   Thank you,
   Alexei
  
  
  
 
 

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

[Alexey Varlamov]

Heh, this regression is more interesting than it looked at first glance:
JITs give the same output with identical stack trace, but test result is PASSED.
By lucky chance I have older debug build at hand (svn = r474646) and
it also spills this stacktrace to system err but status is PASSED for
all execution engines.
Looks like smth hase changed in exceptions processing for interpreter.

2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:

Hello

Today a kernel tests which used to pass a day ago started to fail. It is
java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert some VM
and classlib (since some important classes like URLClassLoader, Hashtable and
TreeMap were changed recently) patches but no reversion helped. It may be a
cumulative effect of the patches now makes the test fail.

It fails somewhere deep inside of signature parser. The problem is also that
class format parses uses antlr which makes the whole parsing quite complex.
The failure happens on a BadSignatureTemplate class which is constructed from
bytes, parsed and its method is invoked. Apparently it has a wrong signature
(surprise :) ).

The whole purpose of the test is not clear to me more surprising is that it
works on RI (not on BEA). If someone could point to what may be wrong now
with this test I would be very grateful.

I also wonder why there is no InvocationTargetException which should be
chained with the down the stack Exception. The test_3 method uses reflection
to invoke a method BadSignatureTemplate.test_1 which in its turn threw an
Exception in parser. Shouldn't there be an InvocationTargetException as the
result of Method.invoke?

Where can I look at BadSignatureTemplate.java, specifically line 13 which
according to the stack called Class.getTypeParameters?

[1]

[EMAIL PROTECTED]:
10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint 
-Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar
 -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
junit.textui.TestRunner java.lang.ClassGenericsTest4
/lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
java.lang.Exception
   at
org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
   at antlr.TokenBuffer.fill(TokenBuffer.java:69)
   at antlr.TokenBuffer.LA(TokenBuffer.java:80)
   at antlr.LLkParser.LA(LLkParser.java:52)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
   at
org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
   at
org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
   at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
   at java.lang.Class.getTypeParameters(Class.java:1020)
   at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
(BadSignatureTemplate.java:13)
   at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
   at java.lang.reflect.Method.invoke(Method.java:381)
   at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
   at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
   at java.lang.reflect.Method.invoke(Method.java:381)
   at junit.framework.TestCase.runTest(TestCase.java:154)
   at junit.framework.TestCase.runBare(TestCase.java:127)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:118)
   at 

Re: [drlvm][test]Exclude some tests from build test target, make 'build test' pass

[Alexey Varlamov]

2006/11/14, Gregory Shimansky [EMAIL PROTECTED]:

On Monday 13 November 2006 15:51 Elena Semukhina wrote:
 On 10/26/06, Elena Semukhina [EMAIL PROTECTED] wrote:
  After H-1823 has been committed, I still see intermittent failures of
  drlvm kernel ThreadTest. Normally this test passes but today I got
  ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
  There is H-1789 for the first issue but it is not reprodiced with the
  attached test anymore. For the second test I filed H-1876 to make the
  test more stable. The patch has been committed recently but the test
  still may fail. I'd like someone to review the above mentioned tests to
  be sure they are correct otherwise we need to investigate failures and
  file JIRA's before the tests are exclued.

 I looked at ThreadTest again and found one more incorrectness in
 testGetStateBlocked(): it does not wait for the thread's run() method
 actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166
 and attached the patch. I ran the test more than 100 times and did not see
 a failure.

Cool! I'd like to see this patch applied (in case it really helps) ASAP.
Alexey V, please don't hold it for long. I would really like to see all
acceptance to pass again on all platforms and then we'll maintain no
regression state.


Verified and applied (at r474672). BTW, seems we are very close to
100% pass rate for classlib tests on DRLVM. The wiki status page [1]
lists just few pending issues, hopefully we'll fix them all in a
couple of days.

[1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM

Re: [drlvm][classlib] thread library - let there be one!

[Alexey Varlamov]

2006/11/10, Weldon Washburn [EMAIL PROTECTED]:

hmm it seems that we need to create kernel natives, the C version
of java kernel classes.  The expectation is that the JVM supplier would
write their own kernel natives.  And the classlib native code would only
call kernel natives.  Thoughts?


I don't understand this. We already have VMI (for common purposes),
and even if hythread shed implementation, it preserves functioning as
interface to threading nevertheless. If this means we should somehow
restructure portlib module - please add some more reasoning?






On 11/10/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:

 On 10/26/06, Angela Lin [EMAIL PROTECTED] wrote:
  On 10/24/06, Weldon Washburn [EMAIL PROTECTED] wrote:
  
   If an arbitrary commercial JVM decided to use classlib, will it need
 to be
   modified to reflect the existing Harmony Classlib threading model?
 
  This is the case no matter how you split the thread library. Whatever
  interface you specify for the classlib will need to be supported by
  the VM.
 
   Also, does this mean VM design is constrained by classlib design?  And
   classlib  design is constrained by J9 design?
 
  The classlib and the VM have certain dependencies on each other. This
  is not a J9-specific issue.
 
  I would aim for a thread API that is generic enough to support
  multiple implementations.

 I think it may be hard (if possible at all) to create high-level
 threading library which would make just every VM happy. For instance,
 DRLVM has a complex synchronization scheme with garbage collector
 which is built into the threading library (for example, each time
 thread goes into wait state, it must instruct the GC that the thread
 can be garbage collected). There also could be VM-specific
 optimizations for monitors which are tied to the object layout used in
 a particular VM.

 Finally, there might be pure-Java written VM's which may choose to
 implement threading library almost entirely in Java (may be on top of
 j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
 may be sort of fork operations from the native code. How could we have
 a threading library which will work equally for all VM's?

 I agree that bypassing layer (2) by the classlib can be undesirable
 because of loosing track for thread/lock states. So it seems that:
 - both VM and classlib need to use single thread library, and at the
 same level (or, saying that differently, Java code and native code
 from classlib should use same threading lib);
 -  threading lib is likely be VM-specific (consider DRLVM as an example)

 If we agree with the above, doesn't it just mean that the hythr must
 be declared as a part of VM? Classlib may probably continue to keep a
 stub library for the compilation purposes. But there must be the
 possibility for other VM's to easily replace it with it's own version.
 I guess we do something similar with the luni-kernel-stubs.jar.

 
  Mature VMs that switch to the Harmony classlib would probably
  implement a portability layer between the existing VM's thread model
  and the Harmony thread API.

 I guess mature VM's would likely to have their own very carefully
 written and optimized threading libraries, integrated with GC, JIT
 e.t.c. It will be easier for them to provide a suitable interface for
 classlib rather than rewrite VM on top of hythread, no matter how
 perfect is it.


 
  Has anyone considered how ThreadMXBean would be supported by the
  proposed classlib thread API subset?

 May be ThreadMXBean is just a good candidate for the kernel class set?
 At least the spec says interface for the thread system of the Java
 virtual machine. I guess other MXBeans are also interfaces to some of
 VM services.


 Thanks,
 Andrey.


 
   On 10/24/06, Angela Lin [EMAIL PROTECTED] wrote:
   
Consider the group of monitor-related functionality: enter/exit,
wait/notify, and interrupt. The implementations of these functions
 are
closely related in the J9-derived hythread, particularly for 3-tier
locking. We need to coordinate when we lock the thread mutex, when
 we
lock the monitor mutex, how we use spinlocks, etc. It would be
unnatural to split out enter/exit from this group.
  
  
   
On 10/24/06, Weldon Washburn [EMAIL PROTECTED] wrote:
 On 10/23/06, Angela Lin [EMAIL PROTECTED] wrote:
 
  What is the goal here?
 
  1. If the goal is to create a single thread library that can be
 used
  by multiple VM and classlib implementations, then the unified
 thread
  lib should contain everything needed to support a VM
 implementation.
 
  2. If the goal is to simply define the interface between the
 classlib
  and the VM, then the 3rd option may be acceptable. This option
 seems
  to imply splitting up functionality that requires deep knowledge
 of
  the threading implementation, which I don't like. Each VM
  implementation would need to implement both the VM and classlib
 sides
   

Re: [drlvm] Class unloading support - tested one approach

[Alexey Varlamov]

[snip]

  My proposal has been measured at ~1% overhead in GC time, or 0.1% in
  execution time (caveats as above).  If there is some complexity in
  establishing classloader reachability from this basis, I would assume it
  can easliy be absorbed.


Sorry if it was already discussed, but I believe this approach also
requires marking vtable bit/byte on each object allocation, unitl the
unloading GC pass is strictly stop-the-world full-heap collection.
Robin, did you include this particular overhead too in your
measurements?

--
Regards,
Alexey

Re: [drlvm][testing] the DRLVM silently exit to run the classlib tests.

[Alexey Varlamov]

Yes, I have the same troubles on SUSE, probably after Weldon's commit r472773...


2006/11/9, Vladimir Ivanov [EMAIL PROTECTED]:

Hello everyone,
today I can't run classlib tests over the DRLVM on SuSe linux. Could
somebody else reproduce this failure and fix it?

 thanks, Vladimir

Note, these tests work OK on IBMVM and on both VM on WindowsXP.

Execution log:
[EMAIL PROTECTED]:/export/viv/trunk/cc/projects/classlib/trunk ant -
Dtest.jre.home=/export/viv/trunk/cc/projects/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre-
Dbuild.module=archive test

compile-support:
   [javac] Compiling 56 source files to
/export/viv/trunk/cc/projects/classlib/trunk/build/test_support
   [javac] Since fork is false, ignoring memoryMaximumSize setting

support-jar:
 [jar] Building jar:
/export/viv/trunk/cc/projects/classlib/trunk/deploy/build/test/support.jar

test-modules:

compile-java:
[echo] Compiling ARCHIVE classes

copy-resources:

svn-info:

build-jar:

build:

copy-test-resources:

compile-tests:
[echo] Compiling ARCHIVE tests

run-tests:
   [mkdir] Created dir:
/export/viv/trunk/cc/projects/classlib/trunk/build/test_report
   [junit] Running
org.apache.harmony.archive.tests.java.util.zip.ZipOutputStreamTest
   [junit] Tests FAILED

touch-failures-file:

touch-errors-file:

test:

full-report:
[junitreport] Transform time: 516ms
[echo] The test report is in
/export/viv/trunk/cc/projects/classlib/trunk/build/test_report/html/index.html

short-report:

gen-report:

check-test-result:

BUILD FAILED
/export/viv/trunk/cc/projects/classlib/trunk/build.xml:167: The following
error occurred while executing this line:
/export/viv/trunk/cc/projects/classlib/trunk/make/build-test.xml:128: There
were test failures.

Total time: 8 seconds
[EMAIL PROTECTED]:/export/viv/trunk/cc/projects/classlib/trunk
/export/viv/trunk/cc/projects/drlvm/trunk/build/lnx_ia32
_gcc_debug/deploy/jre/bin/java
-version

Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java version 1.5.0
pre-alpha : not complete or compatible
svn = r472773, (Nov  9 2006), Linux/ia32/gcc 3.3.3, debug build
http://incubator.apache.org/harmony
[EMAIL PROTECTED]:/export/viv/trunk/cc/projects/classlib/trunk

Re: [drlvm][classlib] DaCapo benchmark regressions

[Alexey Varlamov]

Robin,

1) it must be debug build of drlvm;
2) syntax is -Xstats:[1|2|3] , the number denotes detalization level.

Actually this options gives various *statistics* for run, rather than
performance data or profile. E.g. number of particular byte ops
performed, exceptions thrown/caugth, most frequently allocated
classes, usage of internal memory pools, etc.

I'm not sure this is what you requested - do you need to tune the VM
for best performance or collect additional info during run or smth
else?


2006/11/9, Robin Garner [EMAIL PROTECTED]:

Hmmm ...

$ $DRLVM_HOME/jre/bin/java -Xbootclasspath/p:antlr.jar -XcleanupOnExit
-Xstats -jar $HOME/dacapo-2006-10.jar antlr
Unknown option -Xstats
Use java -help to get help on command line options

$ $DRLVM_HOME/jre/bin/java -version
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java version 1.5.0
pre-alpha : not complete or compatible
svn = r472802, (Nov  9 2006), Linux/ia32/gcc 4.0.3, release build
http://incubator.apache.org/harmony

Anything else I need to add ? :-)

Evgueni Brevnov wrote:
 Unfortunately, YES. It's a known problem. You need to specify
 -XcleanupOnExit as well :-) I'm working in it currently will
 provide a fix soon...

 Thanks
 Evgueni

 On 11/9/06, Robin Garner [EMAIL PROTECTED] wrote:
 Evgueni Brevnov wrote:
  On 11/9/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
  The logs for some benchmarks does not have error messages.
  Is this possible to fix?
 
  SY, Alexey
 
  2006/11/9, Robin Garner [EMAIL PROTECTED]:
   I've just finished adding drlvm to the nightly DaCapo benchmark
   regression tests.  The results are available here:
  
   http://cs/people/Robin.Garner/dacapo/regression/
  
   JikesRVM and DRLVM/Harmony classlib are built from svn checkouts
 taken
   when the nightly run kicks off (00:35 Australian Eastern time).
  
   I'm currently working on adding performance stats for DRLVM and
   JikesRVM, so some suggestions about the best command line
 parameters to
   use would be appreciated.
 
  DRLVM accepts -Xstats parameter for that purpose.

 -Xstats doesn't work for me - is there something I need to do
 specifically to make it work ?

  Thanks
 
  
   cheers
  
   --
   Robin Garner
   Dept. of Computer Science
   Australian National University
  
 


 --
 Robin Garner
 Dept. of Computer Science
 Australian National University



--
Robin Garner
Dept. of Computer Science
Australian National University

Re: [drlvm] Class unloading support - tested one approach

[Alexey Varlamov]

[snip]

Alexey,

it looks like what you are thinking about is *concurrent* collector,
and concurrent garbage collections brings substantial complexity
even without class unloading.


Salikh,

You are correct. Maybe I'm running ahead of the train, but my concern
is that scalability of unloading design is not the last criteria.
The decision we'll do now should not strike back at us in some months.


However, the design we were discussing was for *stop-the-world* garbage
collectors, because this is the only thing currently supported by DRLVM,
and all existing GCs are stop-the-world.


I'm kinda optimistic on gcv5 progress, feeling that concurrent
collection is not improbable to be workable before H2/2007 :)



So, the correctness of unloading algorithm can easily be proved if we consider
that the final unloading collection is a full heap collection,
i.e. both nursery and mature space is collected.

Yes, things are more or less clear for the case of STW GC so we can
concentrate on scripting more detailed technical proposal...

[skip]

Re: [classlib] NLS exception messages arn't displayed correctly

[Alexey Varlamov]

2006/11/8, Oliver Deakin [EMAIL PROTECTED]:


Evgueni Brevnov wrote:
 On 11/8/06, Tim Ellison [EMAIL PROTECTED] wrote:
 Oliver Deakin wrote:
 SNIP!
  2) The bogus FAILED to invoke JVM message.
  Looks like this is coming from the launcher (Im running
  Harmony + IBM VME).
  It appears that this happens because in main_runJavaMain
  (in the launcher main.c) after we make the CallStaticVoidMethod()
  call to run main, we do the following:
 
  if ((*env)-ExceptionCheck (env))
 {
   if (rc == 0)
 rc = 100;
 }
 
  which causes a return code of 100 to be passed back to
  gpProtectedMain() via the invocation() function, where it is used
  in the following way:
 
  if (invocation(...))
 {
   hytty_printf (PORTLIB, FAILED to invoke JVM.\n);
   goto bail;
 }
 
  I imagine this misleading message also appears with DRLVM?
  I'm not setup at the moment to test it.
  Is there a reason we set the return code to 100 if there's an
  unhandled exception?

 I'll leave that one for the person who changed the code ;-)

 Yes, I also observed such message when running with DRLVM. Actually,
 there is  the patch already which fixes the problem with the error
 code returned by the launcher to OS. Moreover this patch removes the
 misleading message as well. Look at
 http://issues.apache.org/jira/browse/HARMONY-2006 
 classlib_exit_code.patch

Hi Evgueni,

I have taken a look at the launcher patch for H2006, and for the most
part it looks good. The only thing that caught my eye was that you
have commented out the FAILED to invoke JVM error message completely.
This is still a useful message in some cases (where the VM fails to launch)
but should not be printed for cases where the VM has actually executed.
So perhaps we need a check here for the return value of invocation to
determine whether to print the message or not?


Sounds reasonable - VM should not die silently. Please go for it.

--
Regards,
Alexey



Regards,
Oliver

 Thanks
 Evgueni


 Regards,
 Tim

 --

 Tim Ellison ([EMAIL PROTECTED])
 IBM Java technology centre, UK.



--
Oliver Deakin
IBM United Kingdom Limited

Re: [DRLVM] General stability

[Alexey Varlamov]

2006/11/7, Vladimir Ivanov [EMAIL PROTECTED]:

On 11/7/06, Alexey Varlamov [EMAIL PROTECTED] wrote:


 But do we have needed scripts/tools readily available to run and
 analyze such stability testing? I'm also pretty sure existing c-unit
 and smoke tests would help to reveal certain problems if run
 repeatedly - just need to add this stuff to CC and run it nightly.
 Anybody volunteer?
 And yet there are a lot of excluded tests in smoke suite...



Actually, we have one. The task 'ant test' from the drlvm module is running
under CC on linux and windows boxes. Every one can easily reproduce it
(checkout 'buildtest' module and run it, updated version is available in the
issue 995).

The problem is: CC will be useful only to track the regression. While we
have some failed tests it should be fixed asap. At present time some issues
that prevent successful CC runs wait for integration more than 1 month :(


AFAIU CC only tracks status changes between subsequent runs, right?
This is not really helpful to detect stability issues.
Apparently a few race conditions present in DRLVM threads suspension,
classloading, and/or elsewhere. So one rather need to collect
statistics to spot suspicious areas. Results can be represented as %%
of failures per test and groups of  failures by symptoms, e.g. the
same assert failed for different tests. Further analysis could bred
better tests with higher failure probability...
Alternative approach could be to employ custom stressing test
harness, running a test in several concurrent threads, etc.

Although this is just a temp solution until we have thorough stress
tests and more decent coverage of VM code by unit tests, the latter
will hardly happen in foreseeable future. So we should try to derive
maximum benefit from already available tests.

--
Regards,
Alexey


 thanks, Vladimir

Re: [drlvm] Class unloading support - tested one approach

[Alexey Varlamov]

2006/11/8, Robin Garner [EMAIL PROTECTED]:

Robin Garner wrote:
 Aleksey Ignatenko wrote:
 Robin.

 OK, well how about keeping a weak reference to the j.l.ClassLoader
 object instead of a strong one.  When the reference becomes (strong)ly
 unreachable, invoke the class-unloading phase.


 If you have weak reference to j.l.Classloader - GC will collect it
 (with all
 appropriate jlClasses) as soon as there are no references to
 j.l.Classloaderand appropriate classes. But there is possible
 situation when there are some
 live objects of that classes and no references to jlClassloader and
 jlClasses. This will lead to unpredictable consequences (crash, etc).



 I want to remind that there 3 mandatory conditions of class unloading:

 1. j.l.Classloader instance is unreachable.

 2. Appropriate j.l.Class instances are unreachable.

 3. No object of any class loaded by appropriate class loader exists.

 Let me repeat.  I offer an efficient solution to (3).  I don't purport
 to have a solution to (1) and (2).

Let me just add:  This is because I don't think (1) or (2) are
particularly difficult from a performance point of view, although I'm
happy to accept that there may still be some subtle engineering challenges.


Robin,

While your idea to (3) looks brilliant and quite convincing, it only
covers part of the whole mission. We really need to derive complete
design solution (like Etienne did), and I feel the voting started in
the neighbor thread is a bit premature.
Some of considerations below are beyond of my understanding, could you
please clarify them (inlined)?

And yet, it would be nice to have a confirmation that the notion of
epoch of full-heap-collection does not imply strict limitations on
GC algorithms. Maybe this is something obvious for people with more
decent GC background than me?



Now this is just off the top of my head, but what about this for a design:
- A j.l.ClassLoader maintains a collection of each of the classes it has
loaded
- A j.l.Class contains a pointer to its j.l.ClassLoader
- A j.l.Class maintains a collection of its vtable(s) (or a pointer if 1:1).
The point of this is that a class loader and its classes are a 'self
sustaining' data structure - if one element in it is reachable the whole
thing is reachable.

Right. The special case is for system classes which are always in VM
root set so never reclaimed.


The VM maintains a weak reference to all its j.l.ClassLoader instances,
and maintains a ReferenceQueue for weakly-reachable classloaders.
ClassLoaders are placed on the ReferenceQueue if and only if they are
unreachable from the heap (including via their j.l.Class objects).

Here: should it actually read as WeakReference instances for
weakly-reachable classloaders are placed on the ReferenceQueue?
Otherwise this sentence completely escapes my mind, sorry.
If the former, when how VM could obtainrescue referent CL objects (+
it's j.l.Class instances) after GC pass - AFAIU references are cleared
automatically before enqueuing? I suppose we are not going to
introduce inter-phase communication between VM and GC...


Note this is an irreversible condition: objects that are unreachable can
never become reachable again, except through very specific methods.

When it sweeps the ReferenceQueue for unreachable classloaders, the VM
places the unreachable classloaders in a queue of classloaders that are
candidates for unloading.  This queue is part of the root set of the VM.

Strongly referenced now I suppose.


 A classloader in this queue is unreachable from the heap, and can be
unloaded when there are no objects of any class it has loaded.

So if the VM decides it is time to try unloading, it should:
1) Check if the full epoch has passed;
2) for each unloadable CL, scan corresponding vtables;
3) if none of the vtables were marked reachable, drop the CL from root
set completely and clean corresponding native structures; Java
instances will be reclaimed at nearest GC iteration;
4) Reset epoch marker and vtable words.

Do I get it right?




This is where my mechanism comes into play.

If an object executes getClass() then its classloader is removed from
the unloadable classloader queue, its weak reference gets recreated  and
we're back at the initial state.  My guess is that this is a pretty
infrequent method call.

I think this stage of the algorithm is easy in performance terms -
difficult in terms of proving correctness, but if you have an efficient
reachability mechanism for classes I think the building blocks are
there, and the subtleties are nothing that a talented engineer can't solve.


Yes, a bit complicated. Taking into account the issues with
ReferenceQueue above, I'd rather suggest the following:

1) The j.l.Class and defining CL have mutual strong references, as said above.
2) Normally, the VM reports all CLs as strong roots thus preserving
them from premature reclamation;
3) When the VM decides (by whatever heuristic) it is time to perform
unloading, it checks epoch 

Re: [drlvm] Class unloading support - tested one approach

[Alexey Varlamov]

Uhm, Etienne overtook me with earlier posts.
Seems we are beginning to converge with design.

2006/11/9, Alexey Varlamov [EMAIL PROTECTED]:

2006/11/8, Robin Garner [EMAIL PROTECTED]:
 Robin Garner wrote:
  Aleksey Ignatenko wrote:
  Robin.
 
  OK, well how about keeping a weak reference to the j.l.ClassLoader
  object instead of a strong one.  When the reference becomes (strong)ly
  unreachable, invoke the class-unloading phase.
 
 
  If you have weak reference to j.l.Classloader - GC will collect it
  (with all
  appropriate jlClasses) as soon as there are no references to
  j.l.Classloaderand appropriate classes. But there is possible
  situation when there are some
  live objects of that classes and no references to jlClassloader and
  jlClasses. This will lead to unpredictable consequences (crash, etc).
 
 
 
  I want to remind that there 3 mandatory conditions of class unloading:
 
  1. j.l.Classloader instance is unreachable.
 
  2. Appropriate j.l.Class instances are unreachable.
 
  3. No object of any class loaded by appropriate class loader exists.
 
  Let me repeat.  I offer an efficient solution to (3).  I don't purport
  to have a solution to (1) and (2).

 Let me just add:  This is because I don't think (1) or (2) are
 particularly difficult from a performance point of view, although I'm
 happy to accept that there may still be some subtle engineering challenges.

Robin,

While your idea to (3) looks brilliant and quite convincing, it only
covers part of the whole mission. We really need to derive complete
design solution (like Etienne did), and I feel the voting started in
the neighbor thread is a bit premature.
Some of considerations below are beyond of my understanding, could you
please clarify them (inlined)?

And yet, it would be nice to have a confirmation that the notion of
epoch of full-heap-collection does not imply strict limitations on
GC algorithms. Maybe this is something obvious for people with more
decent GC background than me?


 Now this is just off the top of my head, but what about this for a design:
 - A j.l.ClassLoader maintains a collection of each of the classes it has
 loaded
 - A j.l.Class contains a pointer to its j.l.ClassLoader
 - A j.l.Class maintains a collection of its vtable(s) (or a pointer if 1:1).
 The point of this is that a class loader and its classes are a 'self
 sustaining' data structure - if one element in it is reachable the whole
 thing is reachable.
Right. The special case is for system classes which are always in VM
root set so never reclaimed.

 The VM maintains a weak reference to all its j.l.ClassLoader instances,
 and maintains a ReferenceQueue for weakly-reachable classloaders.
 ClassLoaders are placed on the ReferenceQueue if and only if they are
 unreachable from the heap (including via their j.l.Class objects).
Here: should it actually read as WeakReference instances for
weakly-reachable classloaders are placed on the ReferenceQueue?
Otherwise this sentence completely escapes my mind, sorry.
If the former, when how VM could obtainrescue referent CL objects (+
it's j.l.Class instances) after GC pass - AFAIU references are cleared
automatically before enqueuing? I suppose we are not going to
introduce inter-phase communication between VM and GC...

 Note this is an irreversible condition: objects that are unreachable can
 never become reachable again, except through very specific methods.

 When it sweeps the ReferenceQueue for unreachable classloaders, the VM
 places the unreachable classloaders in a queue of classloaders that are
 candidates for unloading.  This queue is part of the root set of the VM.
Strongly referenced now I suppose.

  A classloader in this queue is unreachable from the heap, and can be
 unloaded when there are no objects of any class it has loaded.
So if the VM decides it is time to try unloading, it should:
1) Check if the full epoch has passed;
2) for each unloadable CL, scan corresponding vtables;
3) if none of the vtables were marked reachable, drop the CL from root
set completely and clean corresponding native structures; Java
instances will be reclaimed at nearest GC iteration;
4) Reset epoch marker and vtable words.

Do I get it right?



 This is where my mechanism comes into play.

 If an object executes getClass() then its classloader is removed from
 the unloadable classloader queue, its weak reference gets recreated  and
 we're back at the initial state.  My guess is that this is a pretty
 infrequent method call.

 I think this stage of the algorithm is easy in performance terms -
 difficult in terms of proving correctness, but if you have an efficient
 reachability mechanism for classes I think the building blocks are
 there, and the subtleties are nothing that a talented engineer can't solve.

Yes, a bit complicated. Taking into account the issues with
ReferenceQueue above, I'd rather suggest the following:

1) The j.l.Class and defining CL have mutual strong references, as said above.
2) Normally

Re: Harmony passes 94% on derby tests.

[Alexey Varlamov]

2006/11/7, Nina Rinskaya [EMAIL PROTECTED]:

Thanks for your reply! And I agree that the right thing is to file
bugs on EUT. But maybe it is ok to make the patches first as a
temporary workaround just to be able to run EUT on Harmony and not to
wait too long for EUT bugs fixes? Does it make sense?


Sure, the patches would be useful even if just hanging in a JIRA. I
suggest to separate issues intended for commit from temporary stuff,
please file additional JIRA for the last.

--
Best regards,
Alexey



Thanks,
Nina

On 11/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
 +1 to integration. As for the patches, I'd rather suggest filing bugs
 on EUT and let respective community to resolve those issue for good -
 either find more universal approach (like java.management or JVMTI
 features) or hardcode harmony too :).

 Thanks for spending these efforts, anyway!

 03 Nov 2006 14:01:14 +0600, Egor Pasko [EMAIL PROTECTED]:
  On the 0x215 day of Apache Harmony Nina Rinskaya wrote:
   Hi,
  
   I might have chosen the wrong thread for this message, but this is
   about another well-known unit tests suite - Eclipse Unit Tests. I've
   recently filed new JIRA issue
   (https://issues.apache.org/jira/browse/HARMONY-2038) with the ant
   script to run EUT on Harmony. Does it make sense to integrate it to
   the buildtest module?
 
  I think, yes!
 
   For a moment EUT pass rate on Harmony is ~77%. EUT runs results (on
   Linux/ia32 and windows/ia32) are being updated on wiki:
   http://wiki.apache.org/harmony/Eclipse_Unit_Tests_Pass_on_DRLVM
  
   A number of EUT test cases fail on Harmony because EUT uses some
   hard-coded Sun/Jrockit classlibs names. In particular,
   org.eclipse.jdt.core.tests.util.Util class uses specific paths to
   class libraries jar files (JRE_HOME/lib/rt.jar, for example).
   org.eclipse.jdt.core.tests.runtime.*VMLauncher classes use javaw as
   vm executable name that is missing in Harmony bundle. So what I would
   like to do now is to patch EUT to invoke Harmony correctly if it is ok
   with everyone here.
  
   Best regards,
   Nina
  
   On 10/25/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
Excellent!
   
   
   
I have one more idea: we already have buildtest module. Some time ago we
agreed to extends it by coverage and japi scripts (I hope it happens 
soon:)
). May be we extend it one more time and store here some scripts for
automatic run of other-projects unit tests? Seems, in this case we can
easily reproduce tests run and enable new platforms.
   
Of cause, we can not cover all application but we can define some list 
of
'most important application'.
   
Is it OK?
   
Leo, could you share your script for Derby?
   
Tony, could you share your scripts for ant and log4j?
   
   
   
 thanks, Vladimir
   
   
PS. The directory structure may be something like that:
builtest
- trunk
- cc
- coverage
- japi
- application_test
- derby
- ant
- etc
- misc (some other scripts)
On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 Nice work!

 More inline..

 Leo Li wrote:
  467 Tests Run
  94% Pass (443 tests passed)
  6% Fail (24 tests failed)
  5 Suites skipped
 
  The main progress focuses here:
  1. Harmony classlib fails to load class when user-defined security
 policy
  exists. It is due to the sequence of library loading of VM, which 
has
 been
  resolved now.
  2. A new workround for derby tests which allow useprocess to run 
test or
  else several testcases might fail due to derby lack these tests when
  useprocess = false.
  3. Derby source code uses the version and the name of java vm to 
decide
  what
  to do, while current IBM VM has the version of 1.4.2 and the name 
of
  j9,
  which has different output on the screen from that of standard RI 
1.5.
 At
  the same time Derby test compares the output of the iteractive test
 scripts
  to that of expected. I have made some slight modification in its 
source
  code, but I have not throughly change this odd behavior, ...,too 
much:(

 Have you approached the derby community with the changes?

 
  Besides, some testcase fails even on RI. I exclude
  a derbynetclientmats test suit since it will hang both RI and 
Harmony.
  Currently all the failure is irrelevant to Harmony. Hope I can find
  something in the left.
 
  I have updated the wiki of derby on Hamony:
  http://wiki.apache.org/harmony/Apache_Derby.
 

   
   
  
 
  --
  Egor Pasko
 
 

Re: [DRLVM] General stability

[Alexey Varlamov]

2006/11/7, Gregory Shimansky [EMAIL PROTECTED]:

Weldon Washburn wrote:
 Folks,

 I have spent the last two months committing patches to the VM.  While we
 have added a ton of much needed functionality, the stability of the system
 has been ignored.  By chance, I looked at thread synchronization design
 problems this week.  Its very apparent that  we lack the regression testing
 to really find threading bugs, test the fixes and test against regression.
 No doubt there are similar problems in other VM subsystems.   build test
 is necessary but not sufficient for where we need to go.  In a sense,
 committing code with only build test to prevent regression is the
 equivalent to flying in the fog without instrumentation.

 So that we can get engineers focused on stability, I am thinking of coding
 the JIRAs that involve new features as later or even won't fix.  Please
 feel free to comment.

 We also need to restart the old email threads on regression tests.  For
 example, we need some sort of automated test script that runs Eclipse and
 tomcat, etc. in a deterministic fashion so that we can compare test
 results.  It does not have to be perfect for starts, just repeatable and
 easy to use.  Feel free to beat me to starting these threads :)

In my experience on working with drlvm, stability problems are often
discovered on the existing VM acceptance tests. Big applications like
eclipse or tomcat with long workloads usually reveal problems like lack
of class unloading unless they crash on something like threading
problems. The acceptance VM tests that we have already are a good start
to test stability if they are ran nonstop many times.


Gregory,

But do we have needed scripts/tools readily available to run and
analyze such stability testing? I'm also pretty sure existing c-unit
and smoke tests would help to reveal certain problems if run
repeatedly - just need to add this stuff to CC and run it nightly.
Anybody volunteer?
And yet there are a lot of excluded tests in smoke suite...

--
Alexey


I don't say that we shouldn't have real application workloads. I just
want to say that acceptance tests already usually reveal threading
problems quite well if they are ran many times, and race conditions
happen in some circumstances.

However at the moment we already have failing tests, some of them like
gc.LOS on WinXP don't need multiple times to make them fail. There's
also java.lang.ThreadTest which fails for me on Windows 2003 server SP1
and now started to fail on Linux as well.

--
Gregory

Re: Harmony passes 94% on derby tests.

[Alexey Varlamov]

+1 to integration. As for the patches, I'd rather suggest filing bugs
on EUT and let respective community to resolve those issue for good -
either find more universal approach (like java.management or JVMTI
features) or hardcode harmony too :).

Thanks for spending these efforts, anyway!

03 Nov 2006 14:01:14 +0600, Egor Pasko [EMAIL PROTECTED]:

On the 0x215 day of Apache Harmony Nina Rinskaya wrote:
 Hi,

 I might have chosen the wrong thread for this message, but this is
 about another well-known unit tests suite - Eclipse Unit Tests. I've
 recently filed new JIRA issue
 (https://issues.apache.org/jira/browse/HARMONY-2038) with the ant
 script to run EUT on Harmony. Does it make sense to integrate it to
 the buildtest module?

I think, yes!

 For a moment EUT pass rate on Harmony is ~77%. EUT runs results (on
 Linux/ia32 and windows/ia32) are being updated on wiki:
 http://wiki.apache.org/harmony/Eclipse_Unit_Tests_Pass_on_DRLVM

 A number of EUT test cases fail on Harmony because EUT uses some
 hard-coded Sun/Jrockit classlibs names. In particular,
 org.eclipse.jdt.core.tests.util.Util class uses specific paths to
 class libraries jar files (JRE_HOME/lib/rt.jar, for example).
 org.eclipse.jdt.core.tests.runtime.*VMLauncher classes use javaw as
 vm executable name that is missing in Harmony bundle. So what I would
 like to do now is to patch EUT to invoke Harmony correctly if it is ok
 with everyone here.

 Best regards,
 Nina

 On 10/25/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
  Excellent!
 
 
 
  I have one more idea: we already have buildtest module. Some time ago we
  agreed to extends it by coverage and japi scripts (I hope it happens soon:)
  ). May be we extend it one more time and store here some scripts for
  automatic run of other-projects unit tests? Seems, in this case we can
  easily reproduce tests run and enable new platforms.
 
  Of cause, we can not cover all application but we can define some list of
  'most important application'.
 
  Is it OK?
 
  Leo, could you share your script for Derby?
 
  Tony, could you share your scripts for ant and log4j?
 
 
 
   thanks, Vladimir
 
 
  PS. The directory structure may be something like that:
  builtest
  - trunk
  - cc
  - coverage
  - japi
  - application_test
  - derby
  - ant
  - etc
  - misc (some other scripts)
  On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
  
   Nice work!
  
   More inline..
  
   Leo Li wrote:
467 Tests Run
94% Pass (443 tests passed)
6% Fail (24 tests failed)
5 Suites skipped
   
The main progress focuses here:
1. Harmony classlib fails to load class when user-defined security
   policy
exists. It is due to the sequence of library loading of VM, which has
   been
resolved now.
2. A new workround for derby tests which allow useprocess to run test or
else several testcases might fail due to derby lack these tests when
useprocess = false.
3. Derby source code uses the version and the name of java vm to decide
what
to do, while current IBM VM has the version of 1.4.2 and the name of
j9,
which has different output on the screen from that of standard RI 1.5.
   At
the same time Derby test compares the output of the iteractive test
   scripts
to that of expected. I have made some slight modification in its source
code, but I have not throughly change this odd behavior, ...,too much:(
  
   Have you approached the derby community with the changes?
  
   
Besides, some testcase fails even on RI. I exclude
a derbynetclientmats test suit since it will hang both RI and Harmony.
Currently all the failure is irrelevant to Harmony. Hope I can find
something in the left.
   
I have updated the wiki of derby on Hamony:
http://wiki.apache.org/harmony/Apache_Derby.
   
  
 
 


--
Egor Pasko

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Alexey Varlamov]

Egor, thanks for doing this.

03 Nov 2006 14:28:15 +0600, Egor Pasko [EMAIL PROTECTED]:

On the 0x216 day of Apache Harmony Geir Magnusson, Jr. wrote:
 Sure, so use wiki as a community collaboration tool, and then point to
 the JIRAs...

OK, my suggestion was to put links to JIRA tasks from the page:
http://wiki.apache.org/harmony/DRLVM%20newbie%20tasks

Now I think you all agree. So I did it.

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Alexey Varlamov]

Leo,
I've just tried and could not reproduce DRLVM failure (svn = r470676,
(Nov  3 2006), Linux/ia32/gcc 3.3.3, debug build, SUSE9).
I have only JRockit installed and got the following timings:

BEA JRockit 1.5.0
4.6/4.6

Harmony j9
1.4/1.4

Harmony DRLVM (debug)
6.5/6.5


2006/11/3, Leo Li [EMAIL PROTECTED]:

They are the total test run times and I really feel that harmony launches
slower than RI. It is the most abvious difference not only from the above
result.
I have once tested the performance about net and the result ensures me that
harmony performances almost as good as RI although the test I run cannot be
said a formal performance test.:)


On 11/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 2006/11/3, Alexey Petrenko [EMAIL PROTECTED]:
  More and more good new from day to day :)
 
  Thanks, Leo!
 
  SY, Alexey
 
  2006/11/3, Leo Li [EMAIL PROTECTED]:
   Hi, all
I have just tested JUnit4.1 on Harmony.
With J9 VM, harmony passes both on windows xp2 and redhat
 enterprise
   4.0. While drlvm fails on linux, which fails to create new thread
 becauseof
   out-of-memory-error. Since it can always be reproduced, I think
 actually
   system doesnot lack memory at the time. So I reported it as an
   application-oriented bugs as JIRA [1].
Besides I have got the time used in these tests which shows there
 is
   space for us to improve our performance.
  
   VM
  
   Windows xp2
  
 Redhat Enterprise4
  
   RI
  
   0.985+0.921
  
 0.75+0.717
  
   J9
  
   4.25+2.61
  
 2.888+2.897
  
   drlvm
  
   8.437+5.359
  
   /
  
   *The former data represents the time to run junit.tests.AllTests The
 latter,
   junit.samples.AllTests.
   For detailed information, including how to run tests, I have
 posted it
   on Harmony wiki[2].
  

 Looking at this times, I'd say they are mostly about startup time, not
 steady performance per se. I wonder how different these numbers are
 for release vs debug builds - guess Leo used debug versions.
 And surely there are some tricks RI does to achieve this momentary
 startup - as ClassDataSharing or resident-in-memory VM core after very
 first start.
 I eager to anticipate Harmony will compete strongly in this field soon
 enough.


  
   [1]http://issues.apache.org/jira/browse/HARMONY-2060
   [2]http://wiki.apache.org/harmony/JUnit
   --
   Leo Li
   China Software Development Lab, IBM
  
  
 




--
Leo Li
China Software Development Lab, IBM

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Alexey Varlamov]

Nadya,

Thanks for the links, I added new subpage to TODO_List_for_DRLVM.

2006/11/2, Morozova, Nadezhda [EMAIL PROTECTED]:

Alexey,
Do you think you can post these on Wiki? We actually have several pages
there that can help arrange and store such development items:
Starting point, choose your subpage
http://wiki.apache.org/harmony/TODO_List_for_DRLVM
Sample http://wiki.apache.org/harmony/JIT_Development_Tasks
Wiki seems easier to find and use than an email thread on the list. What
do you say?
Do you need my help with this?

Thank you,
Nadya Morozova


-Original Message-
From: Alexey Varlamov [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 9:24 AM
To: harmony-dev
Subject: [drlvm] more self-dependent VM tasks, newbies welcome

Below is a list of isolated development tasks which do not require
advanced knowledge of VM and could be a nice start for newbies to get
acquainted with the code. All items are targeted for better code
sharing.

1) Eliminate duplicate implementation of j.l.Runtime.Process in kernel
classes of DRLVM [1]. The classlib provides neat portlib-based
reference implementation [2], which should be reused. These 2 impls
are roughly identical, so one needs to made more scrupulous comparison
and squeeze some features/fixes of [1] which may be missing in [2],
then employ [2] in j.l.Runtime of DRLVM and drop [1].

2) Improve/re-implement a parser of generic signatures in DRLVM kernel
classes [3], and move this functionality to classlib (luni ?), so
other VMs could reuse it for 1.5 support. The current impl is somewhat
messy and half-baked, one need to invent more shaped and modular API
to the parser. One more possible issue is parser's dependency on
antlr, which may be considered overkill for this duty. I think antlr
has its pros, like more illustrative code with clear correlation to
formal grammar [4]; unfortunately this is not the case with the impl
in question. OTOH minimizing number of dependencies for VM is always
good.

3) Classlib's j.u.TimeZone expects user.timezone property value
initialized during VM startup (BTW I did not find explicit statement
in VMI docs for that, only indirect reference in kernel stub for
j.l.System). I believe this action should be done by hyluni natives
during JNI_OnLoad, no reason to burden VM with it. Therefore I suggest
to move port_user_timezone() function [5] from DRLVM to classlib
(luni/port), and fix DRLVM  hyluni accordingly.

[1]
working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
+ working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
[2]
working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\inte
rnal\process\*
+ working_classlib\modules\luni\src\main\native\luni\shared\process.c
[3]
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\
reflect\**
[4]
http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.
pdf
Para 4.4.4
[5] working_vm\vm\port\src\misc\[win|linux]\timezone.c

Comments? Should I put this somewhere on the Wiki?

Re: [drlvm] more self-dependent VM tasks, newbies welcome

[Alexey Varlamov]

2006/11/2, Geir Magnusson Jr. [EMAIL PROTECTED]:

Put them in as JIRAs


Done: HARMONY-2051, 2052, 2053.


Alexey Varlamov wrote:
 Below is a list of isolated development tasks which do not require
 advanced knowledge of VM and could be a nice start for newbies to get
 acquainted with the code. All items are targeted for better code
 sharing.

 1) Eliminate duplicate implementation of j.l.Runtime.Process in kernel
 classes of DRLVM [1]. The classlib provides neat portlib-based
 reference implementation [2], which should be reused. These 2 impls
 are roughly identical, so one needs to made more scrupulous comparison
 and squeeze some features/fixes of [1] which may be missing in [2],
 then employ [2] in j.l.Runtime of DRLVM and drop [1].

 2) Improve/re-implement a parser of generic signatures in DRLVM kernel
 classes [3], and move this functionality to classlib (luni ?), so
 other VMs could reuse it for 1.5 support. The current impl is somewhat
 messy and half-baked, one need to invent more shaped and modular API
 to the parser. One more possible issue is parser's dependency on
 antlr, which may be considered overkill for this duty. I think antlr
 has its pros, like more illustrative code with clear correlation to
 formal grammar [4]; unfortunately this is not the case with the impl
 in question. OTOH minimizing number of dependencies for VM is always
 good.

 3) Classlib's j.u.TimeZone expects user.timezone property value
 initialized during VM startup (BTW I did not find explicit statement
 in VMI docs for that, only indirect reference in kernel stub for
 j.l.System). I believe this action should be done by hyluni natives
 during JNI_OnLoad, no reason to burden VM with it. Therefore I suggest
 to move port_user_timezone() function [5] from DRLVM to classlib
 (luni/port), and fix DRLVM  hyluni accordingly.

 [1] working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
 + working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
 [2]
 
working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\*

 + working_classlib\modules\luni\src\main\native\luni\shared\process.c
 [3]
 
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**

 [4]
 http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
 Para 4.4.4
 [5] working_vm\vm\port\src\misc\[win|linux]\timezone.c

 Comments? Should I put this somewhere on the Wiki?

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Alexey Varlamov]

2006/11/3, Alexey Petrenko [EMAIL PROTECTED]:

More and more good new from day to day :)

Thanks, Leo!

SY, Alexey

2006/11/3, Leo Li [EMAIL PROTECTED]:
 Hi, all
  I have just tested JUnit4.1 on Harmony.
  With J9 VM, harmony passes both on windows xp2 and redhat enterprise
 4.0. While drlvm fails on linux, which fails to create new thread becauseof
 out-of-memory-error. Since it can always be reproduced, I think actually
 system doesnot lack memory at the time. So I reported it as an
 application-oriented bugs as JIRA [1].
  Besides I have got the time used in these tests which shows there is
 space for us to improve our performance.

 VM

 Windows xp2

   Redhat Enterprise4

 RI

 0.985+0.921

   0.75+0.717

 J9

 4.25+2.61

   2.888+2.897

 drlvm

 8.437+5.359

 /

 *The former data represents the time to run junit.tests.AllTests The latter,
 junit.samples.AllTests.
 For detailed information, including how to run tests, I have posted it
 on Harmony wiki[2].



Looking at this times, I'd say they are mostly about startup time, not
steady performance per se. I wonder how different these numbers are
for release vs debug builds - guess Leo used debug versions.
And surely there are some tricks RI does to achieve this momentary
startup - as ClassDataSharing or resident-in-memory VM core after very
first start.
I eager to anticipate Harmony will compete strongly in this field soon enough.




 [1]http://issues.apache.org/jira/browse/HARMONY-2060
 [2]http://wiki.apache.org/harmony/JUnit
 --
 Leo Li
 China Software Development Lab, IBM

Re: [general] Motorola to develop ME under ALv2

[Alexey Varlamov]

01 Nov 2006 16:08:28 +0600, Egor Pasko [EMAIL PROTECTED]:

On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
 AFAIK ME shares a lot of core classes and packages with SE. And we have
 these packages implemented.
 And now I'm really interesting if Motorola wants to reuse our code or
 develop the better one ?


At least there'll be no stumbling blocks from legal POV, code can flow
freely. Really cool!


we like to say more free software is not a problem :)

 On 11/1/06, Tim Ellison [EMAIL PROTECTED] wrote:
 
  http://biz.yahoo.com/prnews/061031/cgtu074.html?.v=46
 
  Now *that's* cool :-)
 
  For those of you that are not ME-enabled, Motorola is a major player in
  the ME space.  They are deeply involved in advancing the spec and have a
  track record of developing and collaborating 'in the open'.
 
  By declaring their intent to use ALv2 and Apache-style governance we can
  all look forward to an open and unrestricted exchange with the good folk
  at Motorola.
 
  Regards,
  Tim
 
  --
 
  Tim Ellison ([EMAIL PROTECTED])
 
 


 --
 Mikhail Fursov

--
Egor Pasko, Intel Managed Runtime Division

Re: [DRLVM][PORT] correct API to retrieve processor number

[Alexey Varlamov]

Just a wild guess: this may be caused by x86 emulation on em64t
(x86_64). SDK docs advise to use GetNativeSystemInfo() in such case,
instead of currently used GetSystemInfo(). (See
vm\port\src\misc\win\sysinfo.c).


2006/11/1, Xiao-Feng Li [EMAIL PROTECTED]:

Yes, both SUN JRE and DRLVM returns 1 for me. Java API has the same
problem. :-) Probably it should introduce an
availableCoresPerProcessor() or something more comprehensive.

Thanks,
xiaofeng

On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
 On 11/1/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
 
  Are you using Linux? Don't know why it doesn't work for my Pentium D.
  Actually my Windows seems not show two processors at first, while the
  API may depend on OS. My Linux has no problem with this.
 
  On the other hand, even your case is undesirable for Hyperthreading
  since we probably want more detailed info about processor(s) since
  hyperthreading sometimes wants to be treated differently than real SMP
  (or dual-core).  I believe there is such kind of API available
  somewhere, at least NUMA support of Linux from SGI has it.
 

 I use WindowsXP and here is more detailed info about CPU:
 Number of processors  1
 Number of cores  1 per processor
 Number of threads  2 (max 2) per processor
 Name  Intel Pentium 4 660
 Code Name  Prescott
 Specification  Intel(R) Pentium(R) 4 CPU 3.60GHz
 Package  Socket 775 LGA

 And I see 2 CPUs in Windows Task Manager.

 Did you tried Runtime.getRuntime().availableProcessors()  ?



 --
 Mikhail Fursov

Re: [security][testing] 2 tests failed today

[Alexey Varlamov]

2006/11/1, Tim Ellison [EMAIL PROTECTED]:

Mark Hindess wrote:
 Fixed in r469902.  Turns out the exec was putting double quotes around
 the classpath argument (which might make sense if it was going to a
 shell) but it doesn't for an exec syscall.  This resulted in classes
 being search for in the non-existent directory:

   /path/to/modules/luni/bin/test

 rather than:

   /path/to/modules/luni/bin/test

 Regards,
  Mark - confused as to why it didn't also fail on windows

...but, AIUI the code worked ok on Linux with DRLVM.
Can somebody confirm that?


This is true - DRLVM has it's own impl of Process. I'll raise this
issue in a separate thread.



Tim - even more confused

--

Tim Ellison ([EMAIL PROTECTED])

Re: 235 tests are missed at DRLVM test run for Windows

[Alexey Varlamov]

2006/11/1, Anton Luht [EMAIL PROTECTED]:

Alexey,

 1) allow to compare by exact id - e.g. I failed to compare #90 and #91
 due to missing tags.

First, you can obtain login (ask any registered user to add you) and
tag runs you are interested in.

Still I have to do extra steps while searching, looking for latest run
among other equally tagged, etc.


Second - you can do it if you enter two result ids into URL:

http://harmonytest.org/diff.do?method=viewid=id1id2=id2

Uhm, I'm not going to rememeber all that urls and parameters. Why not
to provide extra field? Or better yet, provide such field on the main
page:
Compare 2 results [123 125] which accepts common separators (white
spaces and comma).

Thank you in advance :)



 2) add filtering by tags on the main page - e.g. to see only drl or
 only linux results.

Feature request accepted - I think there will be ~20..30 latest
results on the first page and 'Search' link that will allow to search
by tags, other run properties (like uploader name - old request from
Tony Wu)

--
Regards,
Anton Luht,
Intel Java  XML Engineering

[drlvm] more self-dependent VM tasks, newbies welcome

[Alexey Varlamov]

Below is a list of isolated development tasks which do not require
advanced knowledge of VM and could be a nice start for newbies to get
acquainted with the code. All items are targeted for better code
sharing.

1) Eliminate duplicate implementation of j.l.Runtime.Process in kernel
classes of DRLVM [1]. The classlib provides neat portlib-based
reference implementation [2], which should be reused. These 2 impls
are roughly identical, so one needs to made more scrupulous comparison
and squeeze some features/fixes of [1] which may be missing in [2],
then employ [2] in j.l.Runtime of DRLVM and drop [1].

2) Improve/re-implement a parser of generic signatures in DRLVM kernel
classes [3], and move this functionality to classlib (luni ?), so
other VMs could reuse it for 1.5 support. The current impl is somewhat
messy and half-baked, one need to invent more shaped and modular API
to the parser. One more possible issue is parser's dependency on
antlr, which may be considered overkill for this duty. I think antlr
has its pros, like more illustrative code with clear correlation to
formal grammar [4]; unfortunately this is not the case with the impl
in question. OTOH minimizing number of dependencies for VM is always
good.

3) Classlib's j.u.TimeZone expects user.timezone property value
initialized during VM startup (BTW I did not find explicit statement
in VMI docs for that, only indirect reference in kernel stub for
j.l.System). I believe this action should be done by hyluni natives
during JNI_OnLoad, no reason to burden VM with it. Therefore I suggest
to move port_user_timezone() function [5] from DRLVM to classlib
(luni/port), and fix DRLVM  hyluni accordingly.

[1] working_vm\vm\vmcore\src\kernel_classes\javasrc\java\lang\Runtime.java
+ working_vm\vm\vmcore\src\kernel_classes\native\Runtime_[lnx|win].cpp
[2] 
working_classlib\modules\luni\src\main\java\org\apache\harmony\luni\internal\process\*
+ working_classlib\modules\luni\src\main\native\luni\shared\process.c
[3] 
working_vm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\lang\reflect\**
[4] http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf
Para 4.4.4
[5] working_vm\vm\port\src\misc\[win|linux]\timezone.c

Comments? Should I put this somewhere on the Wiki?

Re: [security][testing] 2 tests failed today

[Alexey Varlamov]

Yes, I also reproduced on 469773. More interesting, this is
J9-specific failure, tests passed on DRLVM.

2006/11/1, Vladimir Ivanov [EMAIL PROTECTED]:

Sorry, this bug is reproduced for me on the r469703 with the same log.
 thanks, Vladimir


On 10/31/06, Tim Ellison [EMAIL PROTECTED] wrote:

 Fixed (for me) in r469517 -- please check to see if that works for you
 too.

 Regards,
 Tim

 Evgueni Brevnov wrote:
  Boris,
 
  Could you explain the problem in greater details? From the above I
  don't understand how Runtime.exec() deals with class loading.
 
  Thank in advance
  Evgueni
 
 
  On 10/31/06, Boris Kuznetsov [EMAIL PROTECTED] wrote:
  Looks like the tests failed because of Linux implementation of
  Runtime.exec() - it can't load class file.
 
  On 10/31/06, Tim Ellison [EMAIL PROTECTED] wrote:
   I see failures too, and it may be my check-in
  http://svn.apache.org/viewvc?view=revrevision=469230
  
   (though I did run stand-alone LUNI  SECURITY tests).  I'll
 investigate
   and roll back if necessary.
  
   Regards,
   Tim
  
   Vladimir Ivanov wrote:
Today me CC failed to run 2 tests on linux box:
   
   
  [EMAIL PROTECTED]
 _checkPermissionLjava_security_Permission
 http://www.harmonytest.org/testapp.do?method=showresultid=1037189
 
   
   
 
 [EMAIL PROTECTED]
 _doPrivilegedLjava_security_PrivilegedAction
 
   
   
The results were upload to:
   
 
 
http://www.harmonytest.org/testapp.do?method=showrunid=88name=result=2jira=0
 
   
:
   
Could somebody reproduce/ fix these failures?
 Thanks, Vladimir
   
  
   --
  
   Tim Ellison ([EMAIL PROTECTED])
  
  
 
 
  --
  Best regards,
  Boris Kuznetsov
  Intel Middleware Products Division
 
 

 --

 Tim Ellison ([EMAIL PROTECTED])

Re: 235 tests are missed at DRLVM test run for Windows

[Alexey Varlamov]

Anton,

Nice feature indeed, many thanks.
Please also consider the following:
1) allow to compare by exact id - e.g. I failed to compare #90 and #91
due to missing tags.
2) add filtering by tags on the main page - e.g. to see only drl or
only linux results.


2006/10/31, Anton Luht [EMAIL PROTECTED]:

Hello, Alexei, Vladimir and others:

Please enjoy the new runs comparing functionality:

http://harmonytest.org/diff.do?method=viewid=72id2=80

:)

The support for tags that was discussed few weeks ago has been
implemented. Now every run has a set of tags associated with it.
Registered users can edit list of tags. When you view a run result,
you can search for run to compare this run with using tags . For
example, when you view run with tags

drl, msvc, windows, xp

it is possible to search for run with tags

ibm, msvc, windows, xp

and see the difference between two VMs.

Please excuse the mess in the order of the results - I've noticed the
effect only after deploy :)

It is possible to specify the list of tags when uploading new results.

I've tagged ~20-30 runs to experiment with.

I've also implemented a request to save user name between results upload.

Please report bugs and send feature requests.

--
Regards,
Anton Luht,
Intel Java  XML Engineering

Re: [classlib][IBMVME]the return value of java.exe

[Alexey Varlamov]

2006/10/30, Evgueni Brevnov [EMAIL PROTECTED]:

Hi,

https://issues.apache.org/jira/browse/HARMONY-2006 is created with
patches :-). I created two separate patches one for DRLVM another one
for Classlib. I don't know if IBMVME requires additional changes. Even
though DestroyJavaVM will not terminate the whole process now it still
doesn't clean up resources properly. I'm going to focus on that
problem...but it seems to take much more than one day :-)

Thanks
Evgueni.

On 10/30/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
 Tim,

 I agree, we shouldn't kill entire process. Unfortunately, it is how
 current implementation does. Actually, shutdown process is a weak
 place of DRLVM and needs deep refactoring. I will try to figure out
 what we can do as a short term solution.

 Evgueni

 On 10/30/06, Tim Ellison [EMAIL PROTECTED] wrote:
  Evgueni Brevnov wrote:
   BTW, here is two more interesting cases
  
   1) Throw uncaught exception in a new thread. Both RI and DRLVM give 0
   in that case.

Interesting, I guess it does not depend on which Java thread
terminates last, only main is counted? Looks a bit inconsistent...


   2) Call System.exit(123) in a new thread. Both RI and DRLVM give 123.
  
   Currently, DRLVM calls system _exit() at the end of System.exit().
   That's why DestroyJavaVM never returns. So the changes I proposed for
   the launcher do not help until DRLVM forcibly terminates the process.
   :-(
  
   Does IBMVME uses system calls to stop the proccess? Does DestroyJavaVM
   returns?
 

Seems that explicit call to System.exit() and natural termination
(even by uncaught throwable) are different use cases and need separate
handling.


  You cannot kill the entire process when destroying the VM.  Apps that
  embed the VM will have a nasty surprise.


Is it the case for System.exit()/halt() ? Given the test result above,
I suspect RI and J9 just kill the process.


 
  Regards,
  Tim
 
   On 10/30/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
   It seems we need to fix the launcher... which is common part for both
   DRLVM and IBVME. I see the problem in the following code sequence...
  
   snip
(*jvm)-DetachCurrentThread(jvm);
(*jvm)-DestroyJavaVM (jvm);
   /snip
  
   The current thread has an uncaught exception raised before it calls
   DetachCurrentThread. This exception is printed out by default uncaught
   exception handler which is called upon thread detaching. So after
   DetachCurrentThread completes we have no exception anymore... Moreover
   we can not play with DetachCurrentThread and DestroyJavaVM return code
   since it should not depend on uncaught exceptions. So I think the fix
   should look like the following:
  
   snip
 if (env-ExceptionOccured) {
  rc = 1;
 }
(*jvm)-DetachCurrentThread(jvm);
(*jvm)-DestroyJavaVM (jvm);
return rc;
   /snip
  
   If there are no objections I'll come up with the patch soon...
  
   Thanks
   Evgueni
   On 10/30/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
I'll try to see how to fix it for DRLVM
   
Evgueni
   
On 10/30/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
 hmmm I got 0 for DRLVM on Win2003

 Evgueni

 On 10/30/06, Spark Shen [EMAIL PROTECTED] wrote:
  Then we may need to follow RI, since different error code fails
   application
 
  Best regards
  Tony Wu ??:
   Consider this class,
   public class TestExeReturn {
   public static void main(String[] args) throws Exception {
   throw new Exception();
   }
   }
  
   when we run java TestExeReturn and echo %errorlevel%, we
   got 1 of
   RI, -1 of DRLVM and 0 for IBMVM.
  
   a testcase of apache ant failed for this issue.
  
 
 
  --
  Spark Shen
  China Software Development Lab, IBM
 
 

   
  
  
 
  --
 
  Tim Ellison ([EMAIL PROTECTED])
 
 

Re: [drlvm][jit] Seems like too many classes loaded

[Alexey Varlamov]

Just to finalize the issue: BEA's runtime also provides compilation
info, and it encountered 1081 methods on HelloWorldApp. Startup is
really costly :(

PS. I'm catching up after a week offline, sorry for resurrecting such
an old thread :$

24 Oct 2006 13:31:16 +0700, Egor Pasko [EMAIL PROTECTED]:

On the 0x20B day of Apache Harmony Armand Navabi wrote:
 I am trying to become more familiar with the jit code.  I ran the
 following to see what all was compiled when running Hello World.
 java -Xtrace:compile Hello.  I was very surprised to see the number of
 methods that seem to be loaded.  I think there are about 1079 methods
 that get compiled for Hello World.

 Does harmony just load all the classes in the classlib and compile every
 method?  If not, then why would there be so many methods compiled for a
 simple hello world program?

my 2c:
first time methods are compiled just before execution. So, you have
to execute a method in your app to see it compiled.

 Right now I am trying to write a simple profiling tool that counts the
 number of certain instructions in a program for a given input (i.e. I
 want to run the program, and for every instruction that ends up running,
 collect information).  So, since it seems that the jit not only compiles
 every instruction in the program (not only the ones that end up
 running), but also a bunch of other classes, I thought perhaps I would
 be more interested in the interpreter.

Do you mean bytecode instructions? or CPU instructions?  For bytecode
you better use the interpreter. For IA-32 we have a special profiling
utility in JIT CG (iprof) that allows to count how many instructions
of a certain kind were executed, what are the hottest basicblocks,
etc. Feel free to ask on iprof in the mailing list. (I think, we
should document this :P, but it is not the first priority)

 Running java -Xint -Xtrace:interpreter Hello then also gave me way
 more output then I expected.  For example

 ...
 interpreter: java/lang/String indexOf(II)I
 interpreter: java/lang/String startsWith(Ljava/lang/String;)Z
 interpreter: java/lang/String startsWith(Ljava/lang/String;I)Z
 interpreter: java/lang/String regionMatches(ILjava/lang/String;II)Z
 interpreter: java/net/URI
 access$1002(Ljava/net/URI;Ljava/lang/String;)Ljava/lang/String;
 interpreter: java/net/URI access$1000(Ljava/net/URI;)Ljava/lang/String;
 interpreter: java/net/URI$Helper
 validatePath(Ljava/lang/String;Ljava/lang/String;I)V
 interpreter: java/net/URIEncoderDecoder
 validate(Ljava/lang/String;Ljava/lang/String;)V
 interpreter: java/lang/String length()I
 interpreter: java/lang/String charAt(I)C
 interpreter: java/lang/String indexOf(I)I
 interpreter: java/lang/String indexOf(II)I
 interpreter: java/lang/String length()I
 ...

 I'm not sure why all of this is being interpreted for a simple hello
 world program.  My understanding was that the interpreter traverses the
 byte code for the given input and then handles the executed byte codes.
 It seems like a lot more is going on here.

 Also, I am trying to become familiar with the jit and interpreter by
 reading the DRL Developer's Guide.  Are there any other resources other
 than the Developer's Guide and this mailing list?


 Thanks
 Armand


--
Egor Pasko, Intel Managed Runtime Division

Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm

[Alexey Varlamov]

2006/10/30, Nathan Beyer [EMAIL PROTECTED]:

I see that one of the ECJ bugs has been fixed [1], but the other was
closed awaiting more information [2], but may be resolved as well.

The fix should be available to test from a nightly build of the
Eclipse 3.3 stream. Would someone like to verify that the discussed
issues are resolved?


Nathan, I've verified [2].

Elena, Evgueni,

The H-1931_ReflectExporter.patch is really the proper fix, thank you.
Regarding the question 3) of Evgueni's earlier post, I believe there
is nothing to fix in getEnclosingClass() impl: if compiler did not
care to provide such info, there is no reliable way to determine it
(using class name etc). And provided [1] is fixed in ECJ, Elena's
tests should pass.

--
Alexey



[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162356





On 10/26/06, Tim Ellison [EMAIL PROTECTED] wrote:
 Elena Semukhina wrote:
  On 10/26/06, Nathan Beyer [EMAIL PROTECTED] wrote:
 
  If this is a bug, have you logged an issue with Eclipse? If not,
  please do so and post the bug URL here, so we can monitor it. You may
  want to try compiling this with the latest ECJ JAR (3.3 nightly) to
  see if it's still generating the same bytecode.
 
 
  Nathan, here is the bug URL:
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=162356
  I tried ecj.jar 3.3 and still was able to reproduce the bug.
 
  Considering that the RI can run this code fine, I'd be surprised if
  this is considered a bug. I've been surprised before though. :)
 
 
  The test I submitted to Eclipse bugzilla fails on RI, IBM VM and DRLVM when
  compiled with ECJ and passes being compiled with javac.
 
  The fix submitted to H-1931 takes this bug into account and relies on the
  private modifier of a local class which is provided by Eclipse compiler
  (but
  not provided by javac). So the accessibility control algorithm takes
  different branches for the classes compiled with javac and ECJ for now.

 See also
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296

 which I have cross-referenced to Bug#162356.

 Regards,
 Tim

 --

 Tim Ellison ([EMAIL PROTECTED])

Re: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription

[Alexey Varlamov]

[snip]



I agree we remove the locale dependent assertions temporarily.

On the other hand, these assertions merely check that file corresponds to File, and folder 
corresponds to Folder or File Folder.
We can check that the return value is not null and is not empty string, at 
least temporarily.


Yes, just perform this check more carefully.



Later we can implement locale switching, if we want to.


If we will want it ever.



What do you think?

Regards,
Alexey.



Best regards,
Richard


 Regards,
 Alexey.

 P.S. See also related issue [2]: j.s.filechooser.FileSystemViewTest
prompts to insert disk into drive A:.


 [1] https://issues.apache.org/jira/browse/HARMONY-1893
 [2] https://issues.apache.org/jira/browse/HARMONY-1892


 --
 Alexey A. Ivanov
 Intel Middleware Product Division


 -Original Message-
 From: Richard Liang [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 11, 2006 12:06 PM
 To: harmony-dev@incubator.apache.org
 Subject: [classlib][swing] test failure:
 javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
 
 Hello,
 
 The test fails on Windows XP when the locale-setting is zh_CN. It's
 because that view.getSystemTypeDescription(file) returns Chinese
 words 文件 instead of File.
 
 Could any one help to verify this issue? Thanks a lot.
 
 --
 Richard Liang
 China Development Lab, IBM
 
 -
 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]




--
Richard Liang
China Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Alexey A. Ivanov
Intel Middleware Product 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]

Re: [classlib][archive]Security policy leads to vm crashes in loading class of JarFile

[Alexey Varlamov]

Can't we use lazy initialization here? I had similar experience with
this class in the past, and think it should not be so fragile to
initialization sequence. And definitely it should not affect whole VM
run.

2006/10/18, Paulex Yang [EMAIL PROTECTED]:

A little further hack shows that, the cause is o.a.h.luni.util.Msg
cannot be initialized so early, which is the exception message i18n
helper class. Its static init codes try to load ResourceBundle but
failed. The new i18n helper o.a.h.l.internal.nls.Messages has same
issue. I modified the java.net.URL ln.296 as below, and the test passed.
-throw new MalformedURLException(
-org.apache.harmony.luni.util.Msg.getString(
-K00d8, spec)); //$NON-NLS-1$
+   throw new MalformedURLException(exception message here);

Leo Li wrote:
 Hi, all:
 During the self-hosting of Derby, I found a security policy  if is
 applied will lead to errors in loading the class of JarFile. IBM vm
 will throw java/lang/UnsatisfiedLinkError: java/util/zip/ZipFile.ntvi
 while
 drlvm will crash with SEH handler: shutdown errorSEH handler: too many
 shutdown errors...

 Here is the testcase:


 import java.util.jar.*;
 public class TestJarFile {

 public static void main(String[] args) throws Exception{
  System.out.println(JarFile.CENATT);
   }

 }

 And the attachment is the derby_tests.policy.

 Then run:

 java -Djava.security.manager
 -Djava.security.policy=derby_tests.policyTestJarFile

 Run passes,

 Harmony on IBM VM fails with java/lang/UnsatisfiedLinkError:
 java/util/zip/ZipFile.ntvi

 Harmony on Drlvm fails with SEH handler: shutdown errorSEH handler:
 too many
 shutdown errors

 If the security manager is not specified, Harmony passes.




--
Paulex Yang
China Software Development Lab
IBM


-
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]

Re: [classlib][archive]Security policy leads to vm crashes in loading class of JarFile

[Alexey Varlamov]

2006/10/19, Leo Li [EMAIL PROTECTED]:

 It is quite a dilemma: VM is free to choose the strategy of loading library
while the sequence is related to classlib.
 In my opinion, it is classlib that has enough information and the
responsibility to decide the library loading sequence.
 Since the launcher is in the control of classlib, is it possible that after
getting the JavaVM, manually load the required library then run the main
method?


Nope, the launcher is not a part of classlib and will not present in
all configurations (e.g. browser plugin or direct use of Invocation
API).
IMHO #3 is too crooked therefore inacceptable, and indeed we have to
state a VMI contract for loading natives needed by classlib: #1, #4 or
some other. I may suggest:
5. Reuse bootclasspath.properties solution. That is, there is always
mandatory hyluni lib, which can set up some property value indicating
a list of required libraries - as it is done now for bootclasspath
jars. After loading hyluni and calling its JNI_OnLoad, VM can read
this list and load other libs.

NB. Currently DRLVM follows #1, that's why it works.




On 10/18/06, Paulex Yang [EMAIL PROTECTED] wrote:

 Alexey Varlamov wrote:
  Can't we use lazy initialization here? I had similar experience with
  this class in the past, and think it should not be so fragile to
  initialization sequence. And definitely it should not affect whole VM
  run.
 Hmm...lazily loading for Msg class is good, but I'm afraid it's not the
 sweet point of this problem, because in this case, the exception is
 *really* thrown by j.n.URL, so that you cannot avoid loading resource
 bundle(btw, I just found that the full stacktrace hasn't been pasted
 yet[1]).  lI suspect the issue is that the hyarchive.dll/so has not been
 loaded yet when this exception happens, so I added this line to the
 static initialization part of ZipFile

static {
 +System.loadLibrary(hyarchive); //$NON-NLS-1$
ntvinit();
}

 The test codes pass happily. I want to commit this as work around if no
 one objects, but I still think a general solution for this kind of issue
 is necessary. There are several classes in archive module need native
 library, Adler32, CRC32, Deflater, Inflater and ZipFile, only explicitly
 load hyarchive here cannot guarantee bug free, and some other modules
 (nio, text etc) have same risk. I have some proposals:

 1. Load classlib native libraries as early as possible in VM, as what we
 do for hyluni, this is safe but the concern is all the Harmony
 compatible VM needs to do this, unacceptable.
 2. Load them early enough, like what we do now in IBM VME, the hyarchive
 is loaded during j.l.System static init, it was considered early enough,
 but sadly this case shows that we cannot image all cases, even for a
 relative general case
 3. Create an init class like below, and all classes needs native library
 must load this init class at first, this works but works in ugly way...
   public class Init{
  static{
 System.loadLibrary(blabla);
  }
   }
   public class SomeClassNeedsNative{
  static{
 Class.forName(Init); // the class loading should only
 happen once so that the native library is loaded only once.
  }
   }
 4. Produce some contract like Jar_OnLoad() which is described in
 MANIFEST.MF, so that any class loader loading the jar at first time will
 execute that method, like JNI_OnLoad or so. This solution seems general
 and elegant, but needs yet another agreement between Harmony VM and
 classlib, further it may make the jar not compatible with other VM.

 Comments? More ideas?

 [1] java.lang.UnsatisfiedLinkError: java/util/zip/ZipFile.ntvinit()V
at java.util.zip.ZipFile.clinit(ZipFile.java:50)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:144)
at
 com.ibm.oti.vm.AbstractClassLoader.fillCache(AbstractClassLoader.java:95)
at
 com.ibm.oti.vm.AbstractClassLoader.getResourceAsStream(
 AbstractClassLoader.java:134)
at java.util.ResourceBundle$1.run(ResourceBundle.java:282)
at java.util.ResourceBundle$1.run(ResourceBundle.java:1)
at
 java.security.AccessController.doPrivileged(AccessController.java:179)
at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java:277)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:134)
at org.apache.harmony.luni.util.MsgHelp$1.run(MsgHelp.java:114)
at
 java.security.AccessController.doPrivileged(AccessController.java:179)
at org.apache.harmony.luni.util.MsgHelp.setLocale(MsgHelp.java:112)
at org.apache.harmony.luni.util.Msg.clinit(Msg.java:49)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
at java.net.URL.init(URL.java:296)
at java.net.URL.init(URL.java:156

Re: [classlib][archive]Security policy leads to vm crashes in loading class of JarFile

[Alexey Varlamov]

2006/10/19, Leo Li [EMAIL PROTECTED]:

But there really contains code about launcher in Harmony/luni, and this
part is maintained by Harmony classlib but not VM. :)

Um, I thought all Harmony code is maintained by us community ;)
As discussed in an older thread, launcher will be moved to tools some day.



On 10/19/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 2006/10/19, Leo Li [EMAIL PROTECTED]:
   It is quite a dilemma: VM is free to choose the strategy of loading
 library
  while the sequence is related to classlib.
   In my opinion, it is classlib that has enough information and the
  responsibility to decide the library loading sequence.
   Since the launcher is in the control of classlib, is it possible that
 after
  getting the JavaVM, manually load the required library then run the main
  method?

 Nope, the launcher is not a part of classlib and will not present in
 all configurations (e.g. browser plugin or direct use of Invocation
 API).
 IMHO #3 is too crooked therefore inacceptable, and indeed we have to
 state a VMI contract for loading natives needed by classlib: #1, #4 or
 some other. I may suggest:
 5. Reuse bootclasspath.properties solution. That is, there is always
 mandatory hyluni lib, which can set up some property value indicating
 a list of required libraries - as it is done now for bootclasspath
 jars. After loading hyluni and calling its JNI_OnLoad, VM can read
 this list and load other libs.

 NB. Currently DRLVM follows #1, that's why it works.

 
 
  On 10/18/06, Paulex Yang [EMAIL PROTECTED] wrote:
  
   Alexey Varlamov wrote:
Can't we use lazy initialization here? I had similar experience with
this class in the past, and think it should not be so fragile to
initialization sequence. And definitely it should not affect whole
 VM
run.
   Hmm...lazily loading for Msg class is good, but I'm afraid it's not
 the
   sweet point of this problem, because in this case, the exception is
   *really* thrown by j.n.URL, so that you cannot avoid loading resource
   bundle(btw, I just found that the full stacktrace hasn't been pasted
   yet[1]).  lI suspect the issue is that the hyarchive.dll/so has not
 been
   loaded yet when this exception happens, so I added this line to the
   static initialization part of ZipFile
  
  static {
   +System.loadLibrary(hyarchive); //$NON-NLS-1$
  ntvinit();
  }
  
   The test codes pass happily. I want to commit this as work around if
 no
   one objects, but I still think a general solution for this kind of
 issue
   is necessary. There are several classes in archive module need native
   library, Adler32, CRC32, Deflater, Inflater and ZipFile, only
 explicitly
   load hyarchive here cannot guarantee bug free, and some other modules
   (nio, text etc) have same risk. I have some proposals:
  
   1. Load classlib native libraries as early as possible in VM, as what
 we
   do for hyluni, this is safe but the concern is all the Harmony
   compatible VM needs to do this, unacceptable.
   2. Load them early enough, like what we do now in IBM VME, the
 hyarchive
   is loaded during j.l.System static init, it was considered early
 enough,
   but sadly this case shows that we cannot image all cases, even for a
   relative general case
   3. Create an init class like below, and all classes needs native
 library
   must load this init class at first, this works but works in ugly
 way...
 public class Init{
static{
   System.loadLibrary(blabla);
}
 }
 public class SomeClassNeedsNative{
static{
   Class.forName(Init); // the class loading should only
   happen once so that the native library is loaded only once.
}
 }
   4. Produce some contract like Jar_OnLoad() which is described in
   MANIFEST.MF, so that any class loader loading the jar at first time
 will
   execute that method, like JNI_OnLoad or so. This solution seems
 general
   and elegant, but needs yet another agreement between Harmony VM and
   classlib, further it may make the jar not compatible with other VM.
  
   Comments? More ideas?
  
   [1] java.lang.UnsatisfiedLinkError: java/util/zip/ZipFile.ntvinit()V
  at java.util.zip.ZipFile.clinit(ZipFile.java:50)
  at java.lang.J9VMInternals.initializeImpl(Native Method)
  at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
  at java.lang.J9VMInternals.initialize(J9VMInternals.java:144)
  at
   com.ibm.oti.vm.AbstractClassLoader.fillCache(AbstractClassLoader.java
 :95)
  at
   com.ibm.oti.vm.AbstractClassLoader.getResourceAsStream(
   AbstractClassLoader.java:134)
  at java.util.ResourceBundle$1.run(ResourceBundle.java:282)
  at java.util.ResourceBundle$1.run(ResourceBundle.java:1)
  at
   java.security.AccessController.doPrivileged(AccessController.java:179)
  at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java
 :277

Re: [drlvm] “java.compiler” property

[Alexey Varlamov]

2006/10/17, Mikhail Fursov [EMAIL PROTECTED]:

On 10/17/06, Pavel Pervov [EMAIL PROTECTED] wrote:

 Mikhail,

 EM, as I see it, is interchangeable component. Should we require defining
 
 java.compiler for interpreted mode from all EMs?


EM does not know the semantic of options it adds to the system properties.
See client.emconf file to see how options are passed to JIT and EM knows
nothing about their meaning.
EM configuration is very convenient place to put all options that affect the
current execution mode. And if you want to have meaningful java.compiler
option a EM configuration file is the only place.

My idea is to initialize java.compiler to some default value (none?) in
 VM, and then overwrite it with actual value wherever actual information is
 available (in EM in our case).


EM does not override system options that are already set. Such a behaviour
allows to  make cmd-line option to have higher priority then those in EM
configuration file. I would vote to keep the behaviour.


This behaviour is fairly reasonable and I agree we should keep it. To
solve Pavel's concerns, VM could set this property after EM init if
needed. Though this might feel like a hack, this is a matter of when
and how VM initializes Java properties (aka public in a recent
thread) with default values. Seemingly default Java properties are not
significant for components loading and should be set after all
components init, no overriding.




And one question follows: what if we have three different JITs defined in EM

 configuration file? :) What value java.compiler will contain in this
 case?


client.emconf already has 3 JITS configured inside. The common name for the
configuration is 'client mode'

--
Mikhail Fursov




-
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] [testing] Excluding commit tests until the problem is fixed

[Alexey Varlamov]

2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]:



Rana Dasgupta wrote:
 On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 So since I don't have Win 2003, I gotta just commit and let someone else
 test?

 Any committer have win 2003?


 I think that it may be hard to find a test at this point that fails on
 Windows Server 2003, but passes on XP. But perf etc. characteristics
 will be
 different. At some point, gc_v5 etc. is likely to have server specific
 variations, eg., parallel gc may be on server only.

 Are we talking of tests in general? I am sorry, but I may not have
 understood the comment.

There is a test that demonstrates a Win 2003 bug...  I can just commit
it and let someone confirm since I don't have a win 2003 machine


It would be nice if Gregory confirmed that Win XP and Win 2003
machines which he compared have identical HW - this might be multicore
vs single-CPU (HT does not count) specific rather than OS?
Gregory?



geir


 Thanks,
 Rana


-
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]

Re: [classlib][luni]Runtime.exec fails on Linux

[Alexey Varlamov]

This is due to incorrect classlib location specified. Please ensure
you provide correct (better absolute) path in build\drlvm.properties
(if you use it) or external.dep.CLASSLIB.loc property value in
cmdline:
sh build.sh -Dexternal.dep.CLASSLIB.loc=$classlib
This should point to the root of (pre-)built classlib WS.

2006/10/17, Leo Li [EMAIL PROTECTED]:

Hi, all:
I tried to build drlvm on linux, but when build update, it reports such
error:

[echo] downloading XALAN from no_settings_in_config_or_environment
[echo] no_settings_in_config_or_environment

BUILD FAILED
/root/workspaces/workspace/drlvm/build/make/build.xml:240: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:273: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:275: The following
error occurred while executing this line:
/root/workspaces/workspace/drlvm/build/make/setup.xml:442: Warning: Could
not find file
/root/workspaces/workspace/drlvm/build/make/no_settings_in_config_or_environment
to copy.

How can I do with it?
Thanks.



On 10/17/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 2006/10/16, Leo Li [EMAIL PROTECTED]:
  It seems not quite related to actual memory stress although the reported
  error is ENOMEM.
  I have run it both in eclipse and console. And there are enough memory
  available.
 
  Furthermore, the case can be repeated even though in the same time a C
  program runs well when using fork().
 
  I suspect that it is related with VM since it can be only reproduced by
 VM
  calling it. I am not sure whether vm does something behind me, but I
 have
  not thought out of a way that a user-space program have such effect.:)
 
 Actually drlvm provides own impl of j.l.Process. Interesting, would it
 work if switched to classlib's impl - then this should be process impl
 issue. Could you please try the following patch with DRLVM and see if
 it works?

 Index: vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
 ===
 --- vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java
 (revision 464817)
 +++ vm/vmcore/src/kernel_classes/javasrc/java/lang/Runtime.java (working
 copy)
 @@ -743,14 +743,15 @@
  //#IN004# Should we check: envp != null ?
  //#IN004# Should we check envp's direction values: envp[i] !=
 null ?

 -String dirPathName = (dir != null ? dir.getPath() : null);
 +//String dirPathName = (dir != null ? dir.getPath() : null);

 -SubProcess sp = new SubProcess();
 +//SubProcess sp = new SubProcess();

 -sp.execVM(cmdarray, envp, dirPathName);
 +//sp.execVM(cmdarray, envp, dirPathName);

 -return sp;
 -
 +//return sp;
 +return org.apache.harmony.luni.internal.process.SystemProcess.
 + create(cmdarray, envp == null ? new String[0] : envp, dir);
  }


 --
 Alexey

 
  On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
  
   I'm confused.  Didn't you just report this on Ubuntu?
  
   I have had similar forking problems on Ubuntu 6 (I once found a bug in
   classlib related to forking...).
  
   I never figured out why Unbuntu does this, but it seemed that under
   memory stress, Ubuntu's fork() fails.  Try this - close Eclipse and
 run
   the test again...
  
   geir
  
  
   Leo Li wrote:
Thank you.
I have just run it on drlvm of unbuntu, it works.
What a qurious problem!
   
   
On 10/16/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
   
Both DRLVM and J9 works for me (SUSE9).
   
--
Alexey
   
2006/10/16, Leo Li [EMAIL PROTECTED]:
 Hi, all:
 The harmony Runtime.exec fails on Linux with ENOMEM.
 Here is the testcase:

 public class Exec {
public static void main(String[] args) throws Exception {

   Runtime.getRuntime().exec(ls);}
 }

I have tried it on RedHat Enterprise 4 and Unbuntu, both get
   ENOMEM
in
 native code.

After digging into it, I found it fails in procimpl.c, line
 135:

grdpid = fork ();

If the call to fork is changed to vfork, the testcase will
 pass
   but
 still get exitcode = 1 which indicates that some error has
 happened.
The
 difference between fork and vfork is just whether page tables is
   copied
to
 child process or not. But I do not think it is the main cause.
   Besides,
 vfork has become outdated since it main usage is supplied by fork
   with
 copy-on-write function implemented in modern linux kernel.
   Furthermore,
 vfork is also not so safe as fork. So I do not think it is the
   accepted
way
 to solve the problem.

   I will try whether it can be reproduced on drlvm of linux since
 I
   am
not
 sure whether it is relevent to VM or classlib. If any drlvm man
 can
tell
me

Re: [drlvm][kernel] Should we be compatible with RI ThreadGroup bug?

[Alexey Varlamov]

BTW, bug evaluation suggests that implementation may be fixed at
beginning of the Java SE 7 cycle - one more argument to follow spec.
So I vote for applying the H-1625 patch, all the more it fixes several
other issues in the test.

2006/10/17, Tony Wu [EMAIL PROTECTED]:

Joshua Bloch said, thread groups are largely obsolete.,Avoid thread groups!
I think it is not necessary to fullly comply with RI here ;-)

On 10/17/06, Elena Semukhina [EMAIL PROTECTED] wrote:
 As everyone keeps silence, I'd suggest to change implementation to be bug
 compatible with RI.

 On 10/15/06, Elena Semukhina [EMAIL PROTECTED] wrote:
 
 
 
  On 10/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
 
   Elena Semukhina wrote:
Classlib test ThreadGroupTest.test_setMaxPriorityI() fails on DRLVM
   because
it expects behaviour that conflicts with specification.
The test passes on IBM VME and RI. The issue is reported at
https://issues.apache.org/jira/browse/HARMONY-1625 .
   
Actually there is a bug report in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4708197 which
   agreed
that
this is a bug in RI and it should be fixed.
   
Should we follow RI's behaviour and change drlvm ThreadGroup.java or
   should
we fix the test?
  
   I'm off-line at the moment so cannot look at the bug details.  The
   question is whether fixing the 'bug' will likely break any applications?
 
 
  This question was discussed in Sun's bug report as well. A JCK test
  detected this bug. The first evaluation stated that This is relatively
  obscure functionality and it's theoretically possible at that changing the
  behavior will break running apps. The second evaluation suggested to
  fix the implementation rather than change the spec. The bug is in progress
  since 2002...
 
 
 
   Regards,
   Tim
  
   --
  
   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]
  
  
 
 
  --
  Thanks,
  Elena




 --
 Thanks,
 Elena




--
Tony Wu
China Software Development Lab, IBM

-
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]

Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov

[Alexey Varlamov]

Thank you all for support and warmhearted words!

--
Regards,
Alexey

2006/10/17, Alexei Zakharov [EMAIL PROTECTED]:

Congratulations! I believe in us. :)

Regards,

2006/10/17, Geir Magnusson Jr [EMAIL PROTECTED]:
 Please join the Apache Harmony PPMC in welcoming the project's newest
 committers, in alphabetical order  :

 Oliver Deakin
 Richard Liang
 Alexey Petrenko
 Gregory Shimansky
 Alexey Varlamov
 Alexei Zakharov

 These six individuals have shown sustained dedication to the project, an
 ability to work well with others, and share the common vision we have
 for Harmony. We all continue to expect great things from them.

 Gentlemen, you don't have accounts yet.  When you finally receive your
 new committer account information, as a first step to test your almighty
 powers of committitude, please update the committers page on the
 website.  That should be a good  (and harmless) exercise to test if
 everything is working.

 Things to do :

 1) test ssh-ing to the server people.apache.org.
 2) Change your login password on the machine
 3) Add a public key to .ssh so you can stop using the password
 4) Set your SVN password  : just type 'svnpasswd'

 At this point, you should be good to go.  Checkout the website from svn
 and update it.  See if you can figure out how.

 Also, anything checked out of SVN, be sure that you have checked out via
 'https' and not 'http' or you can't check in. You can switch using svn
 switch. (See the manual)

 Finally, although you now have the ability to commit, please remember :

 1) continue being as transparent and communicative as possible.  You
 earned committer status in part because of your engagement with others.
  While it was a  have to situation because you had to submit patches
 and defend them, but we believe it is a want to.  Community is the key
 to any Apache project.

 2)We don't want anyone going off and doing lots of work locally, and
 then committing.  Committing is like voting in Chicago - do it early and
 often.  Of course, you don't want to break the build, but keep the
 commit bombs to an absolute minimum, and warn the community if you are
 going to do it - we may suggest it goes into a branch at first.  Use
 branches if you need to.

 3) Always remember that you can **never** commit code that comes from
 someone else, even a co-worker.  All code from someone else must be
 submitted by the copyright holder (either the author or author's
 employer, depending) as a JIRA, and then follow up with the required
 ACQs and BCC.

 Again, thanks for your hard work so far, and welcome.

 The Apache Harmony PPMC



--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

-
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]

Re: [classlib][awt] An awt bug? (was Re: [application] [feedback] VM crashed when running Poleposition on Harmony)

[Alexey Varlamov]

The generated report looks fine, though has a little problem about text
position.

So how are we scored?

-
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][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:

[Alexey Varlamov]

2006/10/17, Ivanov, Alexey A [EMAIL PROTECTED]:

Hello everyone,

When running tests on Windows,
FileSystemViewTest.testGetSystemDisplayName() pops up a dialog prompting
to insert disk into drive A:. This dialog prevents normal running of
other tests.



LOL


IMO, the problem assertion could be deleted without loss of coverage.
Any other comments/opinions?

See the JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1892


Regards,
Alexey.


P.S. The problem code is at lines 85-86 in FileSystemViewTest.java:
   file = File.listRoots()[0];
   assertNotSame(file.getName(), view.getSystemDisplayName(file));


The assertion doesn't look foolproof anyway. Accordingly to spec
getSystemDisplayName() should return *some* name, max what we may
assert that it is not null and not empty.



--
Alexey A. Ivanov
Intel Middleware Product 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]

Re: [general] JIRA - port-platform categories for JIRA?

[Alexey Varlamov]

Both ways make sense to me, tagging for ease of primary filtering
emails/JIRAs etc, and explicit component for advanced search in JIRA.
As for the name, I don't care - port-XXX or platform-XXX...

2006/10/16, Geir Magnusson Jr. [EMAIL PROTECTED]:



Mikhail Fursov wrote:
 It looks like I really do not understand your proposal about JIRA naming.
 I do not know what category is. I see the list of independent components
 here: http://issues.apache.org/jira/browse/HARMONY

yes, that's it.

 and when I create a new issue I can choose only one of the components.

No, you can choose more than one. Try using shift-click or something.

 Do you mean that IPF could be a subcomponent of DRLVM?  The first
 subcomponent in the our JIRA? If yes I think it's a good solution and it is
 not mutually exclusive with the subject prefixes approach.

I didn't know JIRA could deal with subcomponents.  I still don't think
that would work, as we want really to be able to tag things, as both
DRLVM issues and classlib issues can be port specific...

geir


 On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 You missed my point, which was about the naming.

 Being able to use the category tags is much more foolproof than subject
 lines, since you can use more than one at a time, and it's cleanly
 organized...  you can look  at different combinations.

 Do you see what I mean?  In JIRA, we can then choose DRLVM and IPF
 at the same time, so you can look at all DRLVM issues, or just a subset,
 those for IPF, or all IPF issues, or just classlib issues for IPF, etc...

 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]




-
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][jit][Jitrino.OPT] Jitrino.OPT stability improvements

[Alexey Varlamov]

[snip]

  + HARMONY-1802 (no more crash in HARMONY-1688, but a hang:)

 Applied. 1688 still crashes for me

I have no crash, only ... printed and a CPU-eating infinite loop


This is expected behaviour for now, waiting for classloading fix +
the test should be fixed, patch is available.

[snip]

--
Alexey

-
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] IPF functionality

[Alexey Varlamov]

2006/10/16, Mikhail Loenko [EMAIL PROTECTED]:

2006/10/14, Tim Ellison [EMAIL PROTECTED]:
 Just to add my 2p -- I also agree with doing the work in the trunk.  Of
 course the minimum cost of working there is that you do no harm to the
 other platforms.  That is the zeroth level of integration.

 The first level of integration would then be to modify the build system
 to build the IPF code, and of course it has to compile, know it's
 dependencies, etc. etc.

 Until the code can run some useful tests it is probably worth going on
 to run only a restricted set of the tests we have and then take on more.

 We can be bringing a number of new platforms on line simultaneously this
 way, with each potentially being at a different level of
 integration/maturity within the project.

When we bring new platforms how will we make sure that a patch for some
rare platform would not break another one?


Supposed we can charge CC on all supported platforms:

while (!passed.on.available platforms) {
  defer patch  discuss;
}
do commit;
if (some.platform.CC.failed) {
  rollback or fix ASAP;
}




Thanks,
Mikhail


 Regards,
 Tim

 Rana Dasgupta wrote:
  On 10/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 
 
  
This is just one more argument for doing IPF porting in a separate
   branch,
at least since some point.
   
I admit that maintaining quality and checking for regressions on new
platforms is a separate big problem but I believe we could try to
   avoid it
during incubation of new platforms.
   
Overall I agree we could wait with branch creation until real
  problems
appear.
   
  
   Great
 
 
  OK, we can then continue as is until the IPF port matures and is ready for
  running non trivial applications or performance tests. At that point we can
  decide whether to treat it as a primary platform, in which case, we will
  need to test on it before committing submissions to the main branch. Or
  secondary, in which case we branch it and let the IPF submitters control
  their own destiny.
 
  Thanks for the good comments.
 
  Rana
 
 
 
 
 
  -
  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]



-
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]

Re: [classlib][luni]Runtime.exec fails on Linux

[Alexey Varlamov]

Both DRLVM and J9 works for me (SUSE9).

--
Alexey

2006/10/16, Leo Li [EMAIL PROTECTED]:

Hi, all:
The harmony Runtime.exec fails on Linux with ENOMEM.
Here is the testcase:

public class Exec {
   public static void main(String[] args) throws Exception {

  Runtime.getRuntime().exec(ls);}
}

   I have tried it on RedHat Enterprise 4 and Unbuntu, both get ENOMEM in
native code.

   After digging into it, I found it fails in procimpl.c, line 135:

   grdpid = fork ();

   If the call to fork is changed to vfork, the testcase will pass but
still get exitcode = 1 which indicates that some error has happened. The
difference between fork and vfork is just whether page tables is copied to
child process or not. But I do not think it is the main cause. Besides,
vfork has become outdated since it main usage is supplied by fork with
copy-on-write function implemented in modern linux kernel. Furthermore,
vfork is also not so safe as fork. So I do not think it is the accepted way
to solve the problem.

  I will try whether it can be reproduced on drlvm of linux since I am not
sure whether it is relevent to VM or classlib. If any drlvm man can tell me
the result, it can avoid my trouble to build it on linux. :)







--
Leo Li
China Software Development Lab, IBM




-
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] Non-bug difference HARMONY-1688?

[Alexey Varlamov]

2006/10/13, Eugene Ostrovsky [EMAIL PROTECTED]:

Actually situation with initiating loaders is a little bit more complicated.
in VM Spec there are two distinct terms:
1. 'Initiating' class loader - defined in
($5.3http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#72007)
:
When one class loader delegates to another class loader, the loader that
initiates the loading is not necessarily the same loader that completes the
loading and defines the class. If L creates C, either by defining it
directly or by delegation, we say that L *initiates* loading of C or,
equivalently, that L is an *initiating loader* of C.
2. Class loader 'recorded as initiating' by VM.

According to spec (and experimenting with RI VM) VM should record loader as
initiating only in cases when loading is initiated from VM itself. I.e. VM
shold not record when loading is performed from java (e.g. invocation of
Class.forName(), ClassLoader.loadClass(). etc..).


All the more, we finally have confidence that this issue has nothing
to do on the Java side :). Thanks for investigation!



Patch for Vm to support recording class loaders as initiating will be
provided soon. But I'm afraid it won't fix the H-1688 problem, since VM
can't control delegation mechanism in user defined class loaders.


It will for sure: what happens there is usual resolution of a constant
pool reference within default delegation model. And accordingly to
your conclusion above, RI  just does not care about alternative
delegation models, so neither do we (now).



On 10/9/06, Alexey Varlamov  [EMAIL PROTECTED] wrote:

 2006/10/9, Alexey Varlamov  [EMAIL PROTECTED]:
  2006/10/9, Alexey Varlamov [EMAIL PROTECTED] :
   2006/10/9, Pavel Pervov  [EMAIL PROTECTED]:
Commenting on (1) I should note, that VM generally can't determine
 the fact
of initiating class loading; it can only be done in Java (except
 bootstrap
class loader, of course).
   I presume you mean cases of direct calls to loadClass() from executed
   Java code. Well, the same way VM loads array classes on its own, not
   resorting to Java loader instance. So AFAIU, neither VM nor Java have
   100% chance to register initiating loading singly on their own.
  
  Hey, I found the clear specification on (1)! Look at JVMS 2nd ed, Para
  5.3.2 - 5.3.3, it reads:
  First, the Java virtual machine determines whether L has already been
  recorded as an initiating loader of a class or interface denoted by N.
  If so, this class or interface is C, and no class creation is
  necessary.
  Otherwise the Java virtual machine invokes loadClass(N ) on L.

 [0] 
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79441


  So this is definitely bug of DRLVM, which should be fixed mainly on VM
  side. And we may want to think how to avoid data duplication in VM and
  kernel classes on this matter...
 
AFAIK, there is the bug: DRLVM does not record initiating class
 loader of a
class. (1) is just the consequence.
   Not really. After H-1363 (aka BBC), j.l.ClassLoader records initiated
   classes. There may be some holes in impl (e.g. for array classes), but

   kernel classes fulfill API contract in general.
  
   
   
On 10/9/06, Alexey Varlamov  [EMAIL PROTECTED]  wrote:

 Folks,

 Would you mind to spend some time looking at HARMONY-1688? Good
 knowledge of classloading and security machinery is an advantage
 :)

 In short, we face 2 issues in DRLVM:
 1) DRLVM itself is not aware of classes initiated (in contrast to
 defined ones) by a loader, and always delegates to Java classes
 for
 lookup (except bootstrap loader, of course). This is not really
 queer
 behaviour, but seems incompartible with most VMs. BTW, currently
 this
 affects implementation of jvmtiGetClassLoaderClasses(), which I
 believe has a bug - it returns defined classes only.
 2) j.s.AccessController of DRLVM treats system classes (i.e.
 loaded by
 bootstrap loader) equally with application classes while examining

 execution stack, while RI seems to be simply skipping them. In
 other
 words, DRLVM would always perform ProtectionDomain.checkPermission
 ()
 with AllPermission for bootstrap classes, and RI will omit such
 check
 if no user classes on stack. This potentially may produce subtle
 effects in security-exigent areas.

 Also, both can be considered from performance perspective,
 probably
 having somewhat negative impact.
 What do you think, how will we resolve this?

 [0] http://issues.apache.org/jira/browse/HARMONY-1688


 -
 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

Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest

[Alexey Varlamov]

Too many Alexe[i|y]s on the list %).

[snip]

BTW, what is the reason to remove a part of the test? Are the checks invalid
or VM-specific?


OK, let me answer this particular question:
Yes, the removed check is invalid but passes on some JREs (VMs). In
short, top level class permitted to access any members of a nested
class, including private ones, while the check expects
IllegalAccessException to be thrown.
There is a comment in JIRA's description:
1) the check is invalid, see HARMONY-1309 for details; 
Indeed, the HARMONY-1309 contains exhaustive information, including
reference to JLS and Sun's bug database.

If there are other misunderstandings, I hope we can resolve them privately.
--
Regards,
Alexey


Thanks,
Mikhail

2006/10/12, Fedotov, Alexei A [EMAIL PROTECTED]:
 Mikhail,

 I don't understand either: This is a low risk test fix.

 Here should be the following text:

 This is a fix of the test. Test fixes rarely affect more than one test,
 they are local. Hence, they wouldn't produce painful errors which took
 many geek/weeks to locate.

 With best regards,
 Alexei Fedotov,
 Intel Middleware Products Division

 -Original Message-
 From: Mikhail Loenko [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, October 11, 2006 5:57 PM
 To: harmony-dev@incubator.apache.org
 Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni] invalid
 testcase in ClassTest
 
 I don't understand either: This is a low risk test fix.
 
 2006/10/11, Fedotov, Alexei A [EMAIL PROTECTED]:
  Mikhail,
 
  I already got several personal feedbacks about these comments. I
 accept
  that they are not good.
 
  I tried to express an idea that JIRAs marked with this comment
 prevent
  getting 100% pass rate on DRLVM. When I search for
  Unit_Tests_Pass_on_DRLVM in comments I will get a list of bugs to
 fix.
 
  Any suggestions how the comment should like? My only requirement is
 to
  keep Unit_Tests_Pass_on_DRLVM lexem in this comment.
 
 IMHO It makes sense to discuss it on a separate thread with different
 subject,
 so that other people could notice that discussion and participate
 
 Thanks,
 Mikhail
 
 
  With best regards,
  Alexei Fedotov,
  Intel Middleware Products Division
 
  -Original Message-
  From: Mikhail Loenko [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, October 11, 2006 2:37 PM
  To: harmony-dev@incubator.apache.org
  Subject: Re: [jira] Commented: (HARMONY-1670) [classlib][luni]
 invalid
  testcase in ClassTest
  
  Hi Alexei
  
  I'm sorry I comlpetely don't understand your comment (as well as a
  number of similar comments in other JIRAs)
  
  Thanks,
  Mikhail
  
  2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]:
  [ http://issues.apache.org/jira/browse/HARMONY-
  1670?page=comments#action_12440591 ]
  
   Alexei Fedotov commented on HARMONY-1670:
   -
  
   [drlvm][unit] Blocks
  http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
  
   This is a low risk test fix.
  
[classlib][luni] invalid testcase in ClassTest
--
   
Key: HARMONY-1670
URL:
  http://issues.apache.org/jira/browse/HARMONY-1670
Project: Harmony
 Issue Type: Bug
 Components: Classlib
   Reporter: Alexey Varlamov
   Priority: Trivial
Attachments: H-1670.patch
   
   
The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of
 
 modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/Clas
  sTes
  t.java
checks if IllegalAccessException is thrown during invokation of
  private
  method of inner class. This is bad due to:
1) the check is invalid, see HARMONY-1309 for details;
2) The ClassTest is not appropriate for testing reflection, and
  this is
  already covered in j.l.reflect.* tests.
  
   --
   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
  
  
  
  
 
 -
  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]
 
 
 
 -
 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

Re: [drlvm] VM throws NullPointerException in case java.class.path is not set

[Alexey Varlamov]

2006/10/11, Geir Magnusson Jr. [EMAIL PROTECTED]:

Well, that's actually an interesting question...  should the VM do it if
not set, or should the launcher do it?  I think that based on the
principle of least surprise, it should be launcher.

The user uses the launcher, so the launcher should be nice to the user,
and current directory really is somewhat of a user-oriented concept,
and is what the human expects.

Programs use the VM, and I think the VM should be more strict for safety.


Yes, very nice summary. Thanks Geir, for expressing so close to my own
thoughts! :)

--
Alexey



geir

Oliver Deakin wrote:
 Geir Magnusson Jr. wrote:
 Absolutely.  And if not, even the principle of be kind to your users
 dictates that we do something nice for them.

 Agreed - being nice to the user where we can is a good thing! Having the
 current directory on the classpath is pretty common - giving it to the
 user by default costs nothing and saves them having to explicitly set it
 in every launcher they write.

 Regards,
 Oliver


 geir

 Evgueni Brevnov wrote:
 Oliver,

 You have provided strong arguments that RI uses current directory by
 default. I think it makes sense to be compatible with RI in this
 particular case.

 Thanks
 Evgueni

 On 10/10/06, Oliver Deakin [EMAIL PROTECTED] wrote:
 I have just tried launching the RI with a simple launcher (very basic -
 CreateJavaVM(),
 finds and launches a class, then calls DestroyJavaVM()). The launcher
 does not
 set java.class.path, and executes the main method of the following
 class:

   public class SysInfo {
   public static void main(String[] args) {
   System.getProperties().list(System.out);
   }
   }

 The java.class.path value is printed as:

  java.class.path=

 So it appears that java.class.path property is left empty by default.
 However,
 to have found the SysInfo class, the RI must have searched in the
 current
 directory. I can also instantiate other classes that are located in the
 current
 directory. So although the java.class.path is set to an empty string,
 internally
 there is a default inclusion of the current directory.

 IMHO we follow the RI behaviour here, and have an implicit inclusion of
 the current directory unless the classpath is explicitly set.

 Regards,
 Oliver


 Evgueni Brevnov wrote:
  It seems for me like pretty specified VM behavior to treat classpath
  absence as take classes from current directory. At least RI does like
  that when you don't specify classpath on command line.
 
  Evgueni
 
  On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
  Another solution could be a simple shutdown with the valid error
  message.
  Sometimes the error message is better than hidden behaviour.
  So the alternative is to check all properties VM needs before
 running
  real
  startup and fail if some of the properties are not found.
 
 
  On 10/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
  
   Hi All,
  
   Currently DRLVM starts with help of the launcher. The launcher
 does a
   lot of stuff required to create VM instatnce. As a part of its
 job it
   sets up java.class.path property. And this is good. What is not
 good
   that DRLVM crashes (actually throws NullPointerException in
   initalization stage) if java.class.path is not set. I believe
 it makes
   sense to point java.class.path to current directory inside VM if
   launcher doesn't set it.
  
   What do u think?
  
   Thanks
   Evgueni
  
  
 -
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail:
 [EMAIL PROTECTED]
   For additional commands, e-mail:
 [EMAIL PROTECTED]
  
  
 
 
  --
  Mikhail Fursov
 
 
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 

 --
 Oliver Deakin
 IBM United Kingdom Limited


 -
 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]


 -
 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]

Re: [classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?

[Alexey Varlamov]

[snip]

  What are you concerned about wasting?  It will take longer for sure, but
   'java -version' doesn't need to be super fast (it prints to the console
  and quits).  In addition, we should consider gathering version
  information from the class library code too, i.e. to show each module
  version.  I don't think it warrants extending the VMI.

I suppose modules={vm, classlib} here? That is quite reasonable; there
are specific properties documented in API docs:
java.version Java Runtime Environment version
java.vm.versionJava Virtual Machine implementation version
RI additionally provides undocumented java.runtime.version, with
value usually equal to java.vm.version

[snip]

  If we have decided not to transfer version as an option into vm, we can
make some change in launcher:
  1.When create vm, -version is not included as part of vm argument, thus
our vm will not report error.
  2.When vm created, we uses a JNI call to System.getProperty(java.version)
or VMI funciton GetSystemProperty(java.version)to show it to user. I am
not sure which way is better.


VMI is preferable - with the same functionality, it is still faster :)

--
Alexey

-
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][build] Failed to build classlib on r454714

[Alexey Varlamov]

Just to assure that the fix Mark did is good - lcms1.0.12 works fine
for me, all unit tests pass on J9.

2006/10/10, Mark Hindess [EMAIL PROTECTED]:


On 10 October 2006 at 12:23, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 Muahaha... didn't you just say this was something that never changed,
 was geological in stability, etc, etc? :)

:-) Well, yeah, and I was worried until I saw that:

a) the change to introduce this variable happened over two years ago,
and

b) my lucky guess was enough to fix it

-Mark.

 Mark Hindess wrote:
  On 10 October 2006 at 16:22, Oleg Khaschansky [EMAIL PROTECTED]
 om wrote:
  It looks like you don't have lcms.h and, probably, other lcms stuff in
  Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\.
 
  I think the problem is more likely that they do have lcms but that they
  don't have the same version as everyone else.
 
  At a guess, I'd say that the version they are using doesn't have the
  cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and
  that:
 
  #ifndef cmsFLAGS_NOTCACHE
  #define cmsFLAGS_NOTCACHE (0)
  #endif
 
  after the #include for lcms.h would solve the problem.
 
  But this is a complete guess.
 
  -Mark.
 
  Recently awt/swing build was enabled by default and it requires this
  dependency as well as png and jpeg.
 
  Read the instructions in
  Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt.
 
  Or check the recent posts about this. E.g. the following recent thread:
  [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and
  recommend to add them to fetch-depends target
 
  On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
  I'm seeing the same problem.
 
  Thanks,
  Pavel
 
  On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
  Got the following compilation error (SLES 9 gcc 3.3.3):
 
   build-native:
  [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT
  -DIPv6_FUNCTION_SUPPORT -DHYX86  -I/e
  xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include
  -I/export/users2/avarlamo/l
  inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic
  -Icommon -I../shared//i nclude
  -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends
 /
  libs/build/lc
  ms   -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c
  [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTran
 s
  form':
  [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE'
  undeclared (first use in th is function)
  [exec] ../shared/cmmxforms.c:150: error: (Each undeclared
  identifier is reported only on ce
  [exec] ../shared/cmmxforms.c:150: error: for each function it appear
 s
   in.)
  [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of
  `cmsSample3DGrid' from incom patible pointer type
  [exec] make: *** [../shared//cmmxforms.o] Error 1
 
  BUILD FAILED
 
  -
  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]
 
 
  -
  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]
 

 -
 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]




-
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] Commented: (HARMONY-1670) [classlib][luni] invalid testcase in ClassTest

[Alexey Varlamov]

2006/10/11, Mikhail Loenko [EMAIL PROTECTED]:

Hi Alexei

I'm sorry I comlpetely don't understand your comment (as well as a
number of similar comments in other JIRAs)


Hi Mikhail,
I'll be happy to clarify. Please tell me which part is not clear? Is
it my English or smth else?

--
Regards, Alexey



Thanks,
Mikhail

2006/10/7, Alexei Fedotov (JIRA) [EMAIL PROTECTED]:
[ 
http://issues.apache.org/jira/browse/HARMONY-1670?page=comments#action_12440591 ]

 Alexei Fedotov commented on HARMONY-1670:
 -

 [drlvm][unit] Blocks http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM

 This is a low risk test fix.

  [classlib][luni] invalid testcase in ClassTest
  --
 
  Key: HARMONY-1670
  URL: http://issues.apache.org/jira/browse/HARMONY-1670
  Project: Harmony
   Issue Type: Bug
   Components: Classlib
 Reporter: Alexey Varlamov
 Priority: Trivial
  Attachments: H-1670.patch
 
 
  The test_getDeclaredMethodLjava_lang_String$Ljava_lang_Class of 
modules/luni/src/test/java/org/apache/harmony/luni/tests/java/lang/ClassTest.java
  checks if IllegalAccessException is thrown during invokation of private 
method of inner class. This is bad due to:
  1) the check is invalid, see HARMONY-1309 for details;
  2) The ClassTest is not appropriate for testing reflection, and this is 
already covered in j.l.reflect.* tests.

 --
 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




-
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]

Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)

[Alexey Varlamov]

Guys,

I've found another deadlock scenario recently, see HARMONY-1833 [1]:

deadlocks happening between main thread (MT) and finalizer thread (FT):
1) MT performs classloading, it grabs ClassLoader::_lock;
2) GC happens, FinalizerThread.startFinalization() is called, FT activates;
3) FT invokes some finalize() method, compilation starts and grabs
g_compileLock;
4) FT waits for ClassLoader::_lock to allocate code_chunk_info;
5) MT proceeds to compilation of FinalizerThread.spawnBalanceThreads()
and waits for g_compileLock;

I believe this scenario can be fixed via separating locks for
classloading and loader-pool allocations.

[1] http://issues.apache.org/jira/browse/HARMONY-1833

--
Alexey

12.10.06, Gregory Shimansky[EMAIL PROTECTED] написал(а):

On Wednesday 11 October 2006 16:15 Pavel Pervov wrote:
 (Branching from original thread as this is different problem than in the
 root message.)

Wasn't it the same problem, just happening on classlib initialization? I think
the scenario is the same.

 The following scenario will fail:

 1) JIT compiles some method and resolves some class A through user
 defined class loader
 2) user define class loader loads class A and triggers compilation of
 some of its methods
 3) this method happens to depend on class A, and, thus, JIT resolves the
 class A through the same class loader

 Voila! We have the described situation.

A synthetic test for drlvm could really help to emphasize the problem. Then we
can run this test on all other VMs with possible modifications. BTW sun's
hotspot should compile a method if it is called several times, so user
defined class loader could do something like calling this method many times
to trigger its compilation.

--
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]

Re: [drlvm] the big soup of VM properties (HARMONY-1626)

[Alexey Varlamov]

2006/10/10, Dmitry Yershov [EMAIL PROTECTED]:

[snip]
  Requirements
  
 
  1) The key and value are represented as string (i.e. char*).

 and I propose that on each operation, a copy is made, so that the caller
   frees the  string that they got or gave.


Agree.

..

[snip]
 1) if this is a C++ class, lets drop the word 'property'

We can not drop this word because these interfaces are exported from VM core.
To my mind external interfaces should have useful names.

 2) Don't hardcode 'hidden' into the API, as we may have other types down
 the road.  Make it an argument

Ok. So, the latest list of interface functions should be:

   void set_property(const char * key, const char * value, bool type)
   const char * get_property(const char * key, bool type)
   bool is_property_set(const char * key, bool type)
   void unset_property(const char * key, bool type)
   char * * get_properties_keys(bool type)
   char * * get_properties_keys_staring_with(const char * prefix, bool type)


Why bool type? Indeed we may want more types in future. And, AFAIU
VM-exported interfaces are in C. Let it be int ?





If there are no other objections i'll file a jira, start redeveloping
property module, and then do source code refactoring.

Dmitry

-
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]

Re: [drlvm] the big soup of VM properties (HARMONY-1626)

[Alexey Varlamov]

2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:

Dmitry,
I support your idea to clean up VM properties code. I do not like the
current state of the implementation too.

But I have a couple of questions:

1) Who is responsible to deallocate memory for hidden properties? E.g. the
same const char*  value could be allocated with malloc or new or could be
the static value.

2) By adding hidden properties you introduce a new style of communication
between components. Why limit hidden properties with const char* values?
Are there any problems with void* ?


I think there is correlation between these 2 questions :). If we use
const char*, we simply copy key and value when setting a property.
And this is impossible with void*.

BTW, there is alternative functionality named VMLocalStorage - so why
make properties competing with VMLS? Do we really need hidden
properties?





On 10/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

 Inline

 Dmitry Yershov wrote:

 [snip]
 
 VM properties proposal
 ==
 
  The general purpose of VM Properties subcomponent is to provide
  centralized access to a common properties table. A property is meant
  as a pair of key and value. The properties stored in VM Properties
  table represent configuration settings for a separate component (such
  as VMCore, GC, JIT etc) or for the whole system. Another use case for
  the properties is communication between different components.
 
  Requirements
  
 
  1) The key and value are represented as string (i.e. char*).

 and I propose that on each operation, a copy is made, so that the caller
frees the  string that they got or gave.

  2) NULL values are allowed.
  3) VM Properties subcomponent exports its interface as part of VM
 Core.
  4) There are two kind of properties
* Public properties are properties visible both to all VM
  components and to Java applications (by means of
  java.lang.System.getProperties() method).
* Hidden properties are used for VM components communication
  only, not accessible from Java side.
  5) There is a way to set hidden properties through non standard
 command line option (   -XDefinekey=value).
  6) There is a way to get a list of defined properties which keys
 begin with a particular prefix.
  7) Properties table should be thread safe.
 
VM Properties usage scenario

 
  Components can define properties and lookup them by name. When
  setting the property it can be marked either public or hidden. A
  property should be marked as hidden if it is intended internal usage
  only. Public properties are supposed to be visible from Java side also.
  In the same time it is possible to obtain a list of all public
 properties
  to pass them to Java side.
 
 Defined Interface functions
 ===
 
  void set_property(const char * key, const char * value) - Sets the
  public property. NULL values are supported.
 
  void set_hidden_property(const char * key, const char * value) -
 Sets
  the hidden property. NULL values are supported.
 
  const char * get_property(const char * key) - Returns the value of
 the
  property if it has been set by set_property function. Otherwise
 returns
  NULL.
 
  const char * get_hidden_property(const char * key) - Returns the
 value
  of the property if it has been set by set_hidden_property function.
  Otherwise returns NULL.
 
  bool is_property_set(const char * key, bool hidden) - Checks if the
  property is set.
 
  void unset_property(const char * key, bool hidden) - Unsets the
 property.
 
  char * * get_public_property_keys() - Returns an array of keys for
 all
  public properties set.
 
  char * * get_properties_staring_with(const char * prefix, bool
 hidden) -
  Returns an array of keys for all properties set whose keys start
 with
  the prefix specified.

 1) if this is a C++ class, lets drop the word 'property'
 2) Don't hardcode 'hidden' into the API, as we may have other types down
 the road.  Make it an argument

set( key, val, type )
get( key, type )
is_set(key)
unset(key)
get_keys(type)


 
 
  
 
  -
  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]
 

Re: [drlvm] VM throws NullPointerException in case java.class.path is not set

[Alexey Varlamov]

2006/10/10, Evgueni Brevnov [EMAIL PROTECTED]:

It seems for me like pretty specified VM behavior to treat classpath
absence as take classes from current directory. At least RI does like
that when you don't specify classpath on command line.


Please note, you said command line - this is prerogative of the launcher.
I agree with Mikhail, the VM itself should do minimal number of
assumptions about environment where it is being invoked.



Evgueni

On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
 Another solution could be a simple shutdown with the valid error message.
 Sometimes the error message is better than hidden behaviour.
 So the alternative is to check all properties VM needs before running real
 startup and fail if some of the properties are not found.


 On 10/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
 
  Hi All,
 
  Currently DRLVM starts with help of the launcher. The launcher does a
  lot of stuff required to create VM instatnce. As a part of its job it
  sets up java.class.path property. And this is good. What is not good
  that DRLVM crashes (actually throws NullPointerException in
  initalization stage) if java.class.path is not set. I believe it makes
  sense to point java.class.path to current directory inside VM if
  launcher doesn't set it.
 
  What do u think?
 
  Thanks
  Evgueni
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Mikhail Fursov



-
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]

Re: [drlvm] the big soup of VM properties (HARMONY-1626)

[Alexey Varlamov]

2006/10/10, Evgueni Brevnov [EMAIL PROTECTED]:

I don't think it is good idea to use -Dvm.dlls for setting up DRLVM
specific properties. It should be much safer to use somthing like
-Xvm.dlls. In that case it is really user's responisbility.


I tend to agree - we have freedom to extend command line options and
satisfy both ordinary user and VM configurator convenience. Then
indeed we need to separate storage...
Maybe use -XDkey=value syntax for VM-specific properties?

Mikhail,
BTW, what would you say if all JIT-specific properties were kept
separately? E.g. if there were JAVA, VM, JIT types of properties
storage, would it be of some convenience to JIT side? Just curious :)


Evgueni

On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
 Dmitry,
 Why do we need to hide the properties like vm.dlls? Once user overrides it
 - he becomes responsible for a probable application failure.

 For example all of JIT properties are passed like system properties and it's
 very convenient to override the default ones as command line parameters.

 On 10/10/06, Dmitry Yershov [EMAIL PROTECTED] wrote:
 
  2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:
   On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
   
I think there is correlation between these 2 questions :). If we use
const char*, we simply copy key and value when setting a property.
And this is impossible with void*.
  
  
   Ok, this way it does works!
  
   BTW, there is alternative functionality named VMLocalStorage - so why
make properties competing with VMLS? Do we really need hidden
properties?
  
  
   +1. Want to know the answer.
 
  Seems, that we need hidden properties.
  Users can define any properties through command line -Dkey=value.
  Our VM has a set of dangerous properties (vm.dlls, vm.ee_dlls,
  vm.other_natives_dlls ...). We should hide their from users because
  redefining of their may lead to a crush. On the other hand users can
  define such properties and they should be visible for java applications.
 
  If You know other solution, lets discuss it.
 
  Dmitry
 
  
   --
   Mikhail Fursov
  
  
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Mikhail Fursov



-
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]

[classlib][build] Failed to build classlib on r454714

[Alexey Varlamov]

Got the following compilation error (SLES 9 gcc 3.3.3):

build-native:
[exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT
-DIPv6_FUNCTION_SUPPORT -DHYX86  -I/e
xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include
-I/export/users2/avarlamo/l
inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic
-Icommon -I../shared//i nclude
-I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends/libs/build/lc
ms   -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c
[exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTransform':
[exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE'
undeclared (first use in th is function)
[exec] ../shared/cmmxforms.c:150: error: (Each undeclared
identifier is reported only on ce
[exec] ../shared/cmmxforms.c:150: error: for each function it appears in.)
[exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of
`cmsSample3DGrid' from incom patible pointer type
[exec] make: *** [../shared//cmmxforms.o] Error 1

BUILD FAILED

-
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] the big soup of VM properties (HARMONY-1626)

[Alexey Varlamov]

2006/10/10, Mikhail Fursov [EMAIL PROTECTED]:

BTW what if we will have Java component in future (E.g. MMTk's GC)? Will the
hidden properties accessible from Java?


AFAIU the point is to separate namespaces completely, so that user
could utilize any property name and it would not affect JVM in any
way. Probably it is possible to map hidden properties to Java
properties with some prefixes like o.a.h.drlvm. or o.a.h.gc etc.




On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote:

 On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
 
  Mikhail,
  BTW, what would you say if all JIT-specific properties were kept
  separately? E.g. if there were JAVA, VM, JIT types of properties
  storage, would it be of some convenience to JIT side? Just curious :)
 

 I think it would be convenient if we can assign them from the command
 line.
 Right now we have -Dvm. -Xem. -Djit. -Dgc. set of properties.
 You propose to emphasize them with -X prefix, so we have -XDvm. -XDem. and
 -XDgc. as the result.
 Your approach is better because the namespaces are separated. It's safer
 and we remove potential problems when a property with the same name appears
 in user's code.
 The old approach is better because it's do the same using less entities.


 --
 Mikhail Fursov




--
Mikhail Fursov




-
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][build] Failed to build classlib on r454714

[Alexey Varlamov]

2006/10/10, Mark Hindess [EMAIL PROTECTED]:


On 10 October 2006 at 16:22, Oleg Khaschansky [EMAIL PROTECTED] wrote:
 It looks like you don't have lcms.h and, probably, other lcms stuff in
 Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\.

I think the problem is more likely that they do have lcms but that they
don't have the same version as everyone else.


I have lcms 1.0.12 and it worked fine this morning %)


At a guess, I'd say that the version they are using doesn't have the
cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and
that:

#ifndef cmsFLAGS_NOTCACHE
#define cmsFLAGS_NOTCACHE (0)
#endif

after the #include for lcms.h would solve the problem.

But this is a complete guess.

-Mark.

 Recently awt/swing build was enabled by default and it requires this
 dependency as well as png and jpeg.

 Read the instructions in
 Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt.

 Or check the recent posts about this. E.g. the following recent thread:
 [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and
 recommend to add them to fetch-depends target

 On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
  I'm seeing the same problem.
 
  Thanks,
  Pavel
 
  On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
   Got the following compilation error (SLES 9 gcc 3.3.3):
  
build-native:
   [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT
   -DIPv6_FUNCTION_SUPPORT -DHYX86  -I/e
   xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include
   -I/export/users2/avarlamo/l
   inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic
   -Icommon -I../shared//i nclude
   -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends/
 libs/build/lc
   ms   -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c
   [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTrans
 form':
   [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE'
   undeclared (first use in th is function)
   [exec] ../shared/cmmxforms.c:150: error: (Each undeclared
   identifier is reported only on ce
   [exec] ../shared/cmmxforms.c:150: error: for each function it appears
  in.)
   [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of
   `cmsSample3DGrid' from incom patible pointer type
   [exec] make: *** [../shared//cmmxforms.o] Error 1
  
   BUILD FAILED
  
   -
   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]
 
 

 -
 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]




-
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][build] Failed to build classlib on r454714

[Alexey Varlamov]

Got 1 error of 17940 tests:
javax.swing.text.GapContent_PositionTest.testShiftGapLeft():
java.lang.IndexOutOfBoundsException at
java.util.ArrayList.get(ArrayList.java:335) at
javax.swing.text.GapContent_PositionTest.checkPositions(GapContent_PositionTest.java:83)
at 
javax.swing.text.GapContent_PositionTest.testShiftGapLeft(GapContent_PositionTest.java:59)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:120)
at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133)
at java.lang.Thread.run(Thread.java:872)

2006/10/10, Mark Hindess [EMAIL PROTECTED]:


On 10 October 2006 at 19:46, Alexey Varlamov [EMAIL PROTECTED] wrote:
 2006/10/10, Alexey Varlamov [EMAIL PROTECTED]:
  2006/10/10, Mark Hindess [EMAIL PROTECTED]:
  
   On 10 October 2006 at 16:22, Oleg Khaschansky [EMAIL PROTECTED]
 .com wrote:
It looks like you don't have lcms.h and, probably, other lcms stuff in
Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\.
  
   I think the problem is more likely that they do have lcms but that they
   don't have the same version as everyone else.
 
  I have lcms 1.0.12 and it worked fine this morning %)
  
   At a guess, I'd say that the version they are using doesn't have the
   cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and
   that:
  
   #ifndef cmsFLAGS_NOTCACHE
   #define cmsFLAGS_NOTCACHE (0)
   #endif
  
   after the #include for lcms.h would solve the problem.

 It hepls, thanks Mark!

Can you let me know if the tests pass too?

Regards,
 Mark.



-
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]

Re: [classlib][build] Failed to build classlib on r454714

[Alexey Varlamov]

2006/10/10, Oleg Khaschansky [EMAIL PROTECTED]:

Hmm, when I was writing the initial version of that
Harmony\enhanced\classlib\trunk\depends\libs\build\readme.txt, it
was stated there that the only suitable version is lcms 1.14. But it
changed alot since then.


Oleg,
You probably mean Windows version of lcms. README has 2 notes for Windows:
  NOTE: Use the file lcms114d.lib for the debug configuration.
  NOTE : v1.15 of lcms seems to only create lcms.lib
No statements on required version for Linux.


On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
 The fix works for me, thanks! Patching cmmapi.h helped to build classlib.

 I also use liblcms 1.0.12. We should either state the minimal
 supported version of lib in the docs or patch the sources (what I
 think is better in this case).

 -Pavel

 On 10/10/06, Mark Hindess [EMAIL PROTECTED] wrote:
 
  On 10 October 2006 at 19:36, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
   I have a symlink
   trunk/working_classlib/depends/libs/build/lcms/liblcms.ia32 -
   /usr/lib/liblcms.a and a good symlink to lcms.h in the same directory.
   png and jpeg dirs also contain valid symlinks. Do you think I still
   need to compile the libraries?
 
  I suspect you have an old version of lcms - that is, one that dates from
  before 2004(!) when the cmsFLAGS_NOTCACHE flags was added.  Can you
  check what version you have installed?
 
  Regards,
   Mark.
 
   Thanks,
   Pavel
  
   On 10/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It looks like you don't have lcms.h and, probably, other lcms stuff in
Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\.
   
Recently awt/swing build was enabled by default and it requires this
dependency as well as png and jpeg.
   
Read the instructions in
Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt.
   
Or check the recent posts about this. E.g. the following recent thread:
[classlib][build]Lacks liblcms.a libpng.a and etc on Linux and
recommend to add them to fetch-depends target
   
On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote:
 I'm seeing the same problem.

 Thanks,
 Pavel

 On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
  Got the following compilation error (SLES 9 gcc 3.3.3):
 
   build-native:
  [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT
  -DIPv6_FUNCTION_SUPPORT -DHYX86  -I/e
  xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include
  -I/export/users2/avarlamo/l
  inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ 
-fpic
  -Icommon -I../shared//i nclude
  
-I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depend
   s/libs/build/lc
  ms   -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c
  [exec] ../shared/cmmxforms.c: In function 
`cmmCreateMultiprofileTra
   nsform':
  [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE'
  undeclared (first use in th is function)
  [exec] ../shared/cmmxforms.c:150: error: (Each undeclared
  identifier is reported only on ce
  [exec] ../shared/cmmxforms.c:150: error: for each function it 
appea
   rs in.)
  [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of
  `cmsSample3DGrid' from incom patible pointer type
  [exec] make: *** [../shared//cmmxforms.o] Error 1
 
  BUILD FAILED
 
  
-
  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]


   
-
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]
  
 
 
 
  -
  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

Re: [drlvm] the big soup of VM properties (HARMONY-1626)

[Alexey Varlamov]

2006/10/11, Evgueni Brevnov [EMAIL PROTECTED]:

Gregory,

My 2cents:

1cent) I think we should not integrate property module so tight (by
using StringPool) with VM internals. Let it be independent enough.
2cent) I also don't think we should pollute StringPool any further.
Instead I would like to see if we can get it smaller say by
splitting into two pools whatever...


Agreed. Besides properties are used in VM almost solely during init,
no performance gain here. So -1 to using Strings for properties.




Evgueni

On 10/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
 On Tuesday 10 October 2006 11:36 Geir Magnusson Jr. wrote:
  Inline
 
  Dmitry Yershov wrote:
 
  [snip]
 
  VM properties proposal
  ==
  
   The general purpose of VM Properties subcomponent is to provide
   centralized access to a common properties table. A property is meant
   as a pair of key and value. The properties stored in VM Properties
   table represent configuration settings for a separate component (such
   as VMCore, GC, JIT etc) or for the whole system. Another use case for
   the properties is communication between different components.
  
   Requirements
   
  
   1) The key and value are represented as string (i.e. char*).
 
  and I propose that on each operation, a copy is made, so that the caller
 frees the  string that they got or gave.

 Hmm... I thought of another type. VM has a String class which represents an
 internal strings implementation. String pointers all refer to the same
 interned const char * memory location so comparing them is faster, you just
 compare pointers.

 Would it be better to have key and value be String * instead of const char *?
 It would save memory allocation, copying and comparing and lookup in
 properties hash table could be done using a pointer.

 I don't think it is a very performance critical place, properties aren't
 accessed very often, but at least it may reduce memory footprint and will
 cause less memory leaks when someone forgets to free a returned copy.

 On the other hand, String storage is global to the whole VM, so there are tons
 of strings kept inside of it. Lookup inside of a small hash table like
 properties may be much faster than lookup through all the strings that VM
 keeps... Hmm now I am not sure I want to suggest this way, just want it to be
 considered.

 --
 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]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't get binary to work

[Alexey Varlamov]

2006/10/9, Armand Navabi [EMAIL PROTECTED]:

Yes, I am still having problems.

Like I said, I am just trying to run the executable currently.  I see the
same problem I was seeing when I built the DRLVM.

I downloaded the Latest Linux JRE snapshot build, set the JAVA_HOME, PATH
and LD_LIBRARY_PATH environment variables and then tried to run helloworld.
Sometimes the executable will print hello world! and then hang, and
sometimes it will just hang.  Same thing happens when I download and try to
run the Latest Linux HDK with helloworld.


Armand,

The symptoms you are describing similar to investigation results of
HARMONY-1816. It is interesting to see if the patch helps you.

[0] http://issues.apache.org/jira/browse/HARMONY-1816



My platform is Linux Gentoo 2.6.17.8.

Thanks,
Armand

-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 08, 2006 6:57 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Can't get binary to work

Are you still having problems Armand?

Tim

Armand Navabi wrote:
 I have been unable to figure out why I can't get the drlvm to run
 helloworld.  The classlib with Intel's VM works fine.



 So now I thought I'd just see if I could download the binary and execute
it
 (JRE), but it is behaving the same way (I guess this is to be expected,
but
 I just wanted to make sure it wasn't something in the build process that
was
 causing the trouble).



 When I run java by itself it executes without problem, when I run java
 helloworld it just hangs, and java -showversion will print version info
 and then hang right after that:



 [EMAIL PROTECTED] /scratch/anavabi/Harmony/harmony-jre-r450941/bin $ ./java
 -showversion

 Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
 Foundation or its licensors, as applicable.

 java version 1.5.0

 pre-alpha : not complete or compatible

 svn = r450941, (Sep 28 2006), Linux/ia32/gcc 3.4.6, release build

 http://incubator.apache.org/harmony

 (hangs here)



 Here are the environment variables that I think are relevant:



 LD_LIBRARY_PATH


/scratch/anavabi/Harmony/harmony-jre-r450941/bin:/scratch/anavabi/Harmony/ha
 rmony-jre-r450941/bin/default/

 PATH


.:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/i686-pc-linux-gnu/gcc-bi

n/3.4.6:/opt/ICAClient:/opt/sun-jdk-1.5.0.06/bin:/opt/sun-jdk-1.5.0.06/jre/b
 in:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/opt/eclipse-sdk-3.2.1

 JAVA_HOME

 /scratch/anavabi/Harmony/harmony-jre-r450941/bin



 I'm on Gentoo 2.6.17.8.

 Any ideas what may be going on?



 Thanks,

 Armand



--

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]



-
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]

[drlvm] Non-bug difference HARMONY-1688?

[Alexey Varlamov]

Folks,

Would you mind to spend some time looking at HARMONY-1688? Good
knowledge of classloading and security machinery is an advantage :)

In short, we face 2 issues in DRLVM:
1) DRLVM itself is not aware of classes initiated (in contrast to
defined ones) by a loader, and always delegates to Java classes for
lookup (except bootstrap loader, of course). This is not really queer
behaviour, but seems incompartible with most VMs. BTW, currently this
affects implementation of jvmtiGetClassLoaderClasses(), which I
believe has a bug - it returns defined classes only.
2) j.s.AccessController of DRLVM treats system classes (i.e. loaded by
bootstrap loader) equally with application classes while examining
execution stack, while RI seems to be simply skipping them. In other
words, DRLVM would always perform ProtectionDomain.checkPermission()
with AllPermission for bootstrap classes, and RI will omit such check
if no user classes on stack. This potentially may produce subtle
effects in security-exigent areas.

Also, both can be considered from performance perspective, probably
having somewhat negative impact.
What do you think, how will we resolve this?

[0] http://issues.apache.org/jira/browse/HARMONY-1688

-
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] Non-bug difference HARMONY-1688?

[Alexey Varlamov]

2006/10/9, Pavel Pervov [EMAIL PROTECTED]:

Commenting on (1) I should note, that VM generally can't determine the fact
of initiating class loading; it can only be done in Java (except bootstrap
class loader, of course).

I presume you mean cases of direct calls to loadClass() from executed
Java code. Well, the same way VM loads array classes on its own, not
resorting to Java loader instance. So AFAIU, neither VM nor Java have
100% chance to register initiating loading singly on their own.


AFAIK, there is the bug: DRLVM does not record initiating class loader of a
class. (1) is just the consequence.

Not really. After H-1363 (aka BBC), j.l.ClassLoader records initiated
classes. There may be some holes in impl (e.g. for array classes), but
kernel classes fulfill API contract in general.




On 10/9/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 Folks,

 Would you mind to spend some time looking at HARMONY-1688? Good
 knowledge of classloading and security machinery is an advantage :)

 In short, we face 2 issues in DRLVM:
 1) DRLVM itself is not aware of classes initiated (in contrast to
 defined ones) by a loader, and always delegates to Java classes for
 lookup (except bootstrap loader, of course). This is not really queer
 behaviour, but seems incompartible with most VMs. BTW, currently this
 affects implementation of jvmtiGetClassLoaderClasses(), which I
 believe has a bug - it returns defined classes only.
 2) j.s.AccessController of DRLVM treats system classes (i.e. loaded by
 bootstrap loader) equally with application classes while examining
 execution stack, while RI seems to be simply skipping them. In other
 words, DRLVM would always perform ProtectionDomain.checkPermission()
 with AllPermission for bootstrap classes, and RI will omit such check
 if no user classes on stack. This potentially may produce subtle
 effects in security-exigent areas.

 Also, both can be considered from performance perspective, probably
 having somewhat negative impact.
 What do you think, how will we resolve this?

 [0] http://issues.apache.org/jira/browse/HARMONY-1688

 -
 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]

Re: [drlvm] Non-bug difference HARMONY-1688?

[Alexey Varlamov]

2006/10/9, Alexey Varlamov [EMAIL PROTECTED]:

2006/10/9, Pavel Pervov [EMAIL PROTECTED]:
 Commenting on (1) I should note, that VM generally can't determine the fact
 of initiating class loading; it can only be done in Java (except bootstrap
 class loader, of course).
I presume you mean cases of direct calls to loadClass() from executed
Java code. Well, the same way VM loads array classes on its own, not
resorting to Java loader instance. So AFAIU, neither VM nor Java have
100% chance to register initiating loading singly on their own.


Hey, I found the clear specification on (1)! Look at JVMS 2nd ed, Para
5.3.2 - 5.3.3, it reads:
First, the Java virtual machine determines whether L has already been
recorded as an initiating loader of a class or interface denoted by N.
If so, this class or interface is C, and no class creation is
necessary.
Otherwise the Java virtual machine invokes loadClass(N ) on L.

So this is definitely bug of DRLVM, which should be fixed mainly on VM
side. And we may want to think how to avoid data duplication in VM and
kernel classes on this matter...


 AFAIK, there is the bug: DRLVM does not record initiating class loader of a
 class. (1) is just the consequence.
Not really. After H-1363 (aka BBC), j.l.ClassLoader records initiated
classes. There may be some holes in impl (e.g. for array classes), but
kernel classes fulfill API contract in general.



 On 10/9/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
 
  Folks,
 
  Would you mind to spend some time looking at HARMONY-1688? Good
  knowledge of classloading and security machinery is an advantage :)
 
  In short, we face 2 issues in DRLVM:
  1) DRLVM itself is not aware of classes initiated (in contrast to
  defined ones) by a loader, and always delegates to Java classes for
  lookup (except bootstrap loader, of course). This is not really queer
  behaviour, but seems incompartible with most VMs. BTW, currently this
  affects implementation of jvmtiGetClassLoaderClasses(), which I
  believe has a bug - it returns defined classes only.
  2) j.s.AccessController of DRLVM treats system classes (i.e. loaded by
  bootstrap loader) equally with application classes while examining
  execution stack, while RI seems to be simply skipping them. In other
  words, DRLVM would always perform ProtectionDomain.checkPermission()
  with AllPermission for bootstrap classes, and RI will omit such check
  if no user classes on stack. This potentially may produce subtle
  effects in security-exigent areas.
 
  Also, both can be considered from performance perspective, probably
  having somewhat negative impact.
  What do you think, how will we resolve this?
 
  [0] http://issues.apache.org/jira/browse/HARMONY-1688
 
  -
  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]

Re: [drlvm] Non-bug difference HARMONY-1688?

[Alexey Varlamov]

2006/10/9, Alexey Varlamov [EMAIL PROTECTED]:

2006/10/9, Alexey Varlamov [EMAIL PROTECTED]:
 2006/10/9, Pavel Pervov [EMAIL PROTECTED]:
  Commenting on (1) I should note, that VM generally can't determine the fact
  of initiating class loading; it can only be done in Java (except bootstrap
  class loader, of course).
 I presume you mean cases of direct calls to loadClass() from executed
 Java code. Well, the same way VM loads array classes on its own, not
 resorting to Java loader instance. So AFAIU, neither VM nor Java have
 100% chance to register initiating loading singly on their own.

Hey, I found the clear specification on (1)! Look at JVMS 2nd ed, Para
5.3.2 - 5.3.3, it reads:
First, the Java virtual machine determines whether L has already been
recorded as an initiating loader of a class or interface denoted by N.
If so, this class or interface is C, and no class creation is
necessary.
Otherwise the Java virtual machine invokes loadClass(N ) on L.


[0] 
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79441


So this is definitely bug of DRLVM, which should be fixed mainly on VM
side. And we may want to think how to avoid data duplication in VM and
kernel classes on this matter...

  AFAIK, there is the bug: DRLVM does not record initiating class loader of a
  class. (1) is just the consequence.
 Not really. After H-1363 (aka BBC), j.l.ClassLoader records initiated
 classes. There may be some holes in impl (e.g. for array classes), but
 kernel classes fulfill API contract in general.

 
 
  On 10/9/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
  
   Folks,
  
   Would you mind to spend some time looking at HARMONY-1688? Good
   knowledge of classloading and security machinery is an advantage :)
  
   In short, we face 2 issues in DRLVM:
   1) DRLVM itself is not aware of classes initiated (in contrast to
   defined ones) by a loader, and always delegates to Java classes for
   lookup (except bootstrap loader, of course). This is not really queer
   behaviour, but seems incompartible with most VMs. BTW, currently this
   affects implementation of jvmtiGetClassLoaderClasses(), which I
   believe has a bug - it returns defined classes only.
   2) j.s.AccessController of DRLVM treats system classes (i.e. loaded by
   bootstrap loader) equally with application classes while examining
   execution stack, while RI seems to be simply skipping them. In other
   words, DRLVM would always perform ProtectionDomain.checkPermission()
   with AllPermission for bootstrap classes, and RI will omit such check
   if no user classes on stack. This potentially may produce subtle
   effects in security-exigent areas.
  
   Also, both can be considered from performance perspective, probably
   having somewhat negative impact.
   What do you think, how will we resolve this?
  
   [0] http://issues.apache.org/jira/browse/HARMONY-1688
  
   -
   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]

Re: [classlib][lang] AbstractStringBuilder, abstract class?

[Alexey Varlamov]

2006/10/7, Geir Magnusson Jr. [EMAIL PROTECTED]:

sounds reasonable, but don't go based on my word, of course.

Interesting question is why AbstractStringBuilder isn't abstract...


It does not really matters from implementation POV, and the name was
just chosen after the RI - sorta be deeply compatible.  But indeed we
missed abstract modifier, which is also quite reasonable as a
precaution for undocumented exploitation.
Let's fix this.




Andrew Zhang wrote:
 On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:


 An interesting side note: The Serialized Form documentation gives away
 an
 implementation detail of StringBuffer and StringBuilder, in that they
 both
 extend from an AbstractStringBuilder. This might be an interesting
 approach
 to consolidate those code paths.


 Spec lies sometimes? The spec of StringBuilder and StringBuffer claim the
 superclass of them is java.lang.Object, but the serialized form tells the
 truth - they extend from java.lang.AbstractStringBuilder, which is not
 public.

 I picked up this thread again because I found an existing application
 failed
 against Harmony because of this problem. The scenario is:
 1. application runs on jdk1.1
 2. new instances of some classes. If a class has superclass, then new an
 instance of superclass too if it's not abstract or an interface. The
 pseudo-code looks like:
 newAllInstances(Class clazz) {
 if(clazz == null) return;
 if (clazz is abstract or an interface) return;
 new an instance of clazz;
 newAllInstances(clazz.getSuperClass());
 }

 The test data includes some instances of StringBuffer. The application
 fails
 against Harmony because AbstractStringBuilder is a concrete class but not
 public. The application runs well against sun jdk 1.5 (Although all code
 are
 based on jdk1.1) because the superclass is abstract.

 So is it a reason to change the signature of class AbstractStringBuilder?
 Make it as abstract really as the name suggests?

 Thanks!



 [1]

 http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin

 gBuilder
 [2]

 http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin

 gBuffer


 -Original Message-
 From: Tim Ellison [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, February 22, 2006 3:09 PM
 To: harmony-dev@incubator.apache.org
 Subject: Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder
 Implementation for LUNI

 Nathan,

 First, let me say a big thank you for the code and tests you submitted.
 I've had a chance to read through it and (beyond the comments below) it
 looks good.

 I've committed a modified version of your patch to SVN.  However, ;-)

 1.  I've removed the javadoc comments as these appear to be direct
 copies of the Sun documentation.  We cannot copy Sun's property.  For
 now the comments have been replaced with TODO tags.

 2.  I've removed the .intern() from the string literals, since these
 will be interned by the VM anyway.

 3.  Why have you got transient char[] and int fields, and then serialize
 them (as int, char[])?  Wouldn't it be easier to reorder the fields and
 remove the readObject/writeObject methods?

 Thanks again for your work,
 Tim


 Tim Ellison (JIRA) wrote:
   [ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
 
  Tim Ellison resolved HARMONY-103:
  -
 
  Resolution: Fixed
 
  Nathan,
 
  Thanks for the patch, it has been applied (minus javadoc) at repo
 revision
 379882.
 
  Please check that it has been applied as you expected.
 
 
  java.lang.StringBuilder Implementation for LUNI
  ---
 
   Key: HARMONY-103
   URL: http://issues.apache.org/jira/browse/HARMONY-103
   Project: Harmony
  Type: New Feature
Components: Classlib
  Reporter: Nathan Beyer
  Assignee: Tim Ellison
   Attachments: StringBuilder.java, StringBuilderTest.java
 
  This bug is for submitting an implementation of the
 java.lang.StringBuilder to the LUNI module of classlib. The
 implementation
 and class definition is based on the specification at
 http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
  The implementation is not complete, there are a few method that are
 either incomplete or not implemented. All of these are related to the
 Unicode Code Point support, as defined by Java 5. As for the rest of the
 implementation, there are probably a number of optimization points, but
 the
 focus was to complete the functionality and make it compatible with
 various
 Java 5 runtimes.
  Additionally, I had a problem with compiling this class in Eclipse
 3.1.2.
 When I set the compiler to Java 1.4 compliance level, the methods which
 implement the Appendable interface cause compilation errors. When I set
 the
 compiler to Java 5.0 compliance with Java 1.4 .class file compatability
 and
 Java 1.4 source compatibility, the class compiled fine. I'm not sure if
 this
 is quirk of the JDT compiler or what, but 

Re: [classlib][test] Site to collect classlib test statistics

[Alexey Varlamov]

Anton,

Many thanks for exploring this area, it looks quite promising.
An idea: this service would become more valuable if presented
transparent search/comparison of results for particular tests over all
uploaded runs.
Let user enter name of a test and show in one table all known results
for this test, or even better, provide a table of all ever failed
tests with links to individual consolidated tables.
This would help analyzing failures very much.

--
Regards,
Alexey

2006/10/4, Anton Luht [EMAIL PROTECTED]:

Hello,

 Could you tell about it in more detail?
 1) Who can upload test results?

Everyone - no authorization is needed, you can include file upload to
your regular builds if you want - authorized users can remove them
later if something goes wrong :) If you want to modify uploaded tests'
data - add JIRA issues to failures, add comments, etc - please send me
login/password and I'll create an account.

 2) How are you going to develop this site, structure, data base and
 etc.?

I'll try to implement all feature requests that community members will
express. One of possible directions I see is support for new test
suites  - currently it  recognises only Harmony  classlib JUnit tests
output. If you have another test suite you want to upload to that site
- just send me an archive and I'll  try to add support for this kind
of tests.

Sources of that app are not in SVN now - if you want to
review/fix/improve something - I can send you an archive.
--
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]




-
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] too tired, need help

[Alexey Varlamov]

2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:

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.


Geir,
To avoid possible duplication - there is HARMONY-1626 about smth very
similar, and I'm ready to submit a patch, just waiting for H-1582.



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]

Re: [drlvm] too tired, need help

[Alexey Varlamov]

Oh, I'd had not such happy lunch time knowing about your torments ;(
I thought I indicated my intentions about this on the list and did'n
bother to state this in the JIRA.

2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:

I have this almost done so that it uses the boot classpath generated by
luni. Only remaining peace is to add kernel.jar to it, and I'll do that
so it comes from the VMDIR - we wanted to move kernel.jar there anyway
for cleaner deployment.

I just couldn't stop... no mental peace. :)


Geir Magnusson Jr. wrote:


 Alexey Varlamov wrote:
 2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
 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.

 Geir,
 To avoid possible duplication - there is HARMONY-1626 about smth very
 similar, and I'm ready to submit a patch, just waiting for H-1582.

 Ah - I was looking at this very JIRA.  I didn't realize you were working
 on it.  PLease submit the patch now just so i can see it so i can to to
 bed w/ a peaceful mind.

 You can submit another after 1582 - also, please link to 1582

 geir



 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]


 -
 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]




-
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][test] Site to collect classlib test statistics

[Alexey Varlamov]

Thanks for prompt response!
Those 554 errors on interpreter are due to fork mode=once, it is a
single error affecting the whole run. Is there a way to delete an
uploaded run?

Better yet, to be able select a range of runs to include to analysis.
The appetite comes with eating :)
Criteria to select can vary, one of many possible is execution engine
- it would be nice to have such characteristic of a run ...


2006/10/6, Anton Luht [EMAIL PROTECTED]:

Alexey,

I've added both options - search by test name and list of tests that
ever failed. The second one is very big because of results you've
uploaded for DRLVM/Linux with 554 errors. Please tell me if you want
to change anything in the interface.

On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
 Anton,

 Many thanks for exploring this area, it looks quite promising.
 An idea: this service would become more valuable if presented
 transparent search/comparison of results for particular tests over all
 uploaded runs.
 Let user enter name of a test and show in one table all known results
 for this test, or even better, provide a table of all ever failed
 tests with links to individual consolidated tables.
 This would help analyzing failures very much.

 --
 Regards,
 Alexey

 2006/10/4, Anton Luht [EMAIL PROTECTED]:
  Hello,
 
   Could you tell about it in more detail?
   1) Who can upload test results?
 
  Everyone - no authorization is needed, you can include file upload to
  your regular builds if you want - authorized users can remove them
  later if something goes wrong :) If you want to modify uploaded tests'
  data - add JIRA issues to failures, add comments, etc - please send me
  login/password and I'll create an account.
 
   2) How are you going to develop this site, structure, data base and
   etc.?
 
  I'll try to implement all feature requests that community members will
  express. One of possible directions I see is support for new test
  suites  - currently it  recognises only Harmony  classlib JUnit tests
  output. If you have another test suite you want to upload to that site
  - just send me an archive and I'll  try to add support for this kind
  of tests.
 
  Sources of that app are not in SVN now - if you want to
  review/fix/improve something - I can send you an archive.
  --
  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]
 
 

 -
 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]




-
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] passing extra options to vm fails on Widows XP

[Alexey Varlamov]

2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:

I was hoping you'd take the hint and limit the patch to just solving the
stated problem.  Extra refactoring just makes it harder - it can always
be done as a followup.


Yeah, this was miscommunicated - I thought I provided enugh
justification for all the changes...


Anyway, looking at it now.

geir


Alexey Varlamov wrote:
 I observed such problem too. The HARMONY-1376 patch fixes this for me;
 but Geir still holds it...

 2006/10/6, Elena Semukhina [EMAIL PROTECTED]:
 I failed to run any application with -Xem:jet (and -Xem:opt as well)
 set in
 harmonyvm.properties on my Windows XP while I succeeded on Windows
 2003. I
 even copied that file from Windows 2003 machine to XP machine but this
 did
 not help.

 java Test gives me the following:

 An unhandled error (4) has occurred.
 HyGeneric_Signal_Number=0004
 ExceptionCode=c005
 ExceptionAddress=004020DF
 ContextFlags=0001003f
 Handler1=00401010
 Handler2=11105CE0
 InaccessibleAddress=0550
 EDI=
 ESI=001531F0
 EAX=
 EBX=
 ECX=004044F4
 EDX=4C25
 EIP=004020DF
 ESP=0013F970
 EBP=0550
 Module=C:\users\esemukhi\svn1\drlvm\trunk\build\deploy\jre\bin\java.exe
 Module_base_address=0040
 Offset_in_DLL=20df

 This application has requested the Runtime to terminate it in an unusual
 way.
 Please contact the application's support team for more information.


 --
 Thanks,
 Elena



 -
 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]




-
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] too tired, need help

[Alexey Varlamov]

Actually you'd only need 2 changes over my patch:
1) change the path to kernel.jar in classloader.cpp (and in build
scripts accordingly :);
2) add smth like
-Dorg.apache.harmony.vm.path=%JAVA_HOME%/bin/%VM_DIR% to
harmonyvm.properties

2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:

Ok - I'll grab your -Xbootclasspath stuff...


Alexey Varlamov wrote:
 (Cross-posted from JIRA):
 OK, we should combine both patches. The
 -Dorg.apache.harmony.vm.vmdir= of yours is logical continuation
 towards multiVM-WS feature. And my patch more correctly handles
 -Xbootclasspath[/ap]: options.
 Will refresh patch after 1582 if your mind is easy now :)

 2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
 not a worry - I learned a lot

 Take a look at what I did and see if it's right :)

 geir


 Alexey Varlamov wrote:
  Oh, I'd had not such happy lunch time knowing about your torments ;(
  I thought I indicated my intentions about this on the list and did'n
  bother to state this in the JIRA.
 
  2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
  I have this almost done so that it uses the boot classpath
 generated by
  luni. Only remaining peace is to add kernel.jar to it, and I'll do
 that
  so it comes from the VMDIR - we wanted to move kernel.jar there anyway
  for cleaner deployment.
 
  I just couldn't stop... no mental peace. :)
 
 
  Geir Magnusson Jr. wrote:
  
  
   Alexey Varlamov wrote:
   2006/10/6, Geir Magnusson Jr. [EMAIL PROTECTED]:
   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.
  
   Geir,
   To avoid possible duplication - there is HARMONY-1626 about smth
 very
   similar, and I'm ready to submit a patch, just waiting for H-1582.
  
   Ah - I was looking at this very JIRA.  I didn't realize you were
  working
   on it.  PLease submit the patch now just so i can see it so i can
 to to
   bed w/ a peaceful mind.
  
   You can submit another after 1582 - also, please link to 1582
  
   geir
  
  
  
   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]
  
  
  
 -
   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]
 
 
 
  -
  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]



 -
 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]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail

Re: [classlib][test] Site to collect classlib test statistics

[Alexey Varlamov]

2006/10/6, Anton Luht [EMAIL PROTECTED]:

Hello,

 Those 554 errors on interpreter are due to fork mode=once, it is a
 single error affecting the whole run. Is there a way to delete an
 uploaded run?

I've added a possibility to delete run for a registered user. Please
send me login/password if you want to have such possibility.

 Better yet, to be able select a range of runs to include to analysis.
 The appetite comes with eating :)
 Criteria to select can vary, one of many possible is execution engine
 - it would be nice to have such characteristic of a run ...

The latest Web 2.0 fashion trend is to use tags for this (same as
keywords in Bugzilla) :) Will it do for you if tags support is
implemented? Examples of tags I can can think of are: msvc, gcc,
Linux, Windows, SP2, RedHat, Single_Core, Multi_Core, etc. We can have
an editable list to avoid typos but to be able to add new tags easily.


Yes, I think this would do the job. Let's try and see how to make it
convenient.
The filter settings better be persistent, to ease browsing. BTW, it
would be nice to remember previous values on upload page too - e.g. my
name don't change that often to retype it each time :)



  Alexey,
 
  I've added both options - search by test name and list of tests that
  ever failed. The second one is very big because of results you've
  uploaded for DRLVM/Linux with 554 errors. Please tell me if you want
  to change anything in the interface.
 
  On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
   Anton,
  
   Many thanks for exploring this area, it looks quite promising.
   An idea: this service would become more valuable if presented
   transparent search/comparison of results for particular tests over all
   uploaded runs.
   Let user enter name of a test and show in one table all known results
   for this test, or even better, provide a table of all ever failed
   tests with links to individual consolidated tables.
   This would help analyzing failures very much.
  
   --
   Regards,
   Alexey
  
   2006/10/4, Anton Luht [EMAIL PROTECTED]:
Hello,
   
 Could you tell about it in more detail?
 1) Who can upload test results?
   
Everyone - no authorization is needed, you can include file upload to
your regular builds if you want - authorized users can remove them
later if something goes wrong :) If you want to modify uploaded tests'
data - add JIRA issues to failures, add comments, etc - please send me
login/password and I'll create an account.
   
 2) How are you going to develop this site, structure, data base and
 etc.?
   
I'll try to implement all feature requests that community members will
express. One of possible directions I see is support for new test
suites  - currently it  recognises only Harmony  classlib JUnit tests
output. If you have another test suite you want to upload to that site
- just send me an archive and I'll  try to add support for this kind
of tests.
   
Sources of that app are not in SVN now - if you want to
review/fix/improve something - I can send you an archive.
--
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]
   
   
  
   -
   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]
 
 

 -
 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]




-
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][test] Site to collect classlib test statistics

[Alexey Varlamov]

Vera,

I'm not sure I understood your intention. Do you want to monitor
regressions routinely a la CruiseControl? Or you need an automated
failure analyzer which bisects commits and finds flawed commit?

2006/10/6, Volynets, Vera [EMAIL PROTECTED]:

Alexey,
Thank you for your response.
As I understood I'm working on the same problem,
I write scripts to run different tests(cunit, classlib, smoke, kernel,
specjvm98) and collect statistics.
I do it to track patch which was reason of failure of any test. So bug
propagation would be stopped.
The final result is presented like table with name and state
(passed/failed).
My next step was to use mysql database, php and Apache server to make my
system user-friendly. Also I need to think out algorithm to find
guilty revision. Now I run tests only on Windows and only on my
machine.
I think it's a good idea to keep in touch and collaborate!
It's useful to have this system on Harmony,
because each contributor can see how his patch effect the virtual
machine!!!

With best regards, Vera!

-Original Message-
From: Alexey Varlamov [mailto:[EMAIL PROTECTED]
Sent: Friday, October 06, 2006 4:14 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][test] Site to collect classlib test statistics

Thanks for prompt response!
Those 554 errors on interpreter are due to fork mode=once, it is a
single error affecting the whole run. Is there a way to delete an
uploaded run?

Better yet, to be able select a range of runs to include to analysis.
The appetite comes with eating :)
Criteria to select can vary, one of many possible is execution engine
- it would be nice to have such characteristic of a run ...


2006/10/6, Anton Luht [EMAIL PROTECTED]:
 Alexey,

 I've added both options - search by test name and list of tests that
 ever failed. The second one is very big because of results you've
 uploaded for DRLVM/Linux with 554 errors. Please tell me if you want
 to change anything in the interface.

 On 10/6/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
  Anton,
 
  Many thanks for exploring this area, it looks quite promising.
  An idea: this service would become more valuable if presented
  transparent search/comparison of results for particular tests over
all
  uploaded runs.
  Let user enter name of a test and show in one table all known
results
  for this test, or even better, provide a table of all ever failed
  tests with links to individual consolidated tables.
  This would help analyzing failures very much.
 
  --
  Regards,
  Alexey
 
  2006/10/4, Anton Luht [EMAIL PROTECTED]:
   Hello,
  
Could you tell about it in more detail?
1) Who can upload test results?
  
   Everyone - no authorization is needed, you can include file upload
to
   your regular builds if you want - authorized users can remove them
   later if something goes wrong :) If you want to modify uploaded
tests'
   data - add JIRA issues to failures, add comments, etc - please
send me
   login/password and I'll create an account.
  
2) How are you going to develop this site, structure, data base
and
etc.?
  
   I'll try to implement all feature requests that community members
will
   express. One of possible directions I see is support for new test
   suites  - currently it  recognises only Harmony  classlib JUnit
tests
   output. If you have another test suite you want to upload to that
site
   - just send me an archive and I'll  try to add support for this
kind
   of tests.
  
   Sources of that app are not in SVN now - if you want to
   review/fix/improve something - I can send you an archive.
   --
   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]
  
  
 
 
-
  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]



-
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]




-
Terms of use : http

Re: [general] creation of jdktools

[Alexey Varlamov]

2006/10/4, Salikh Zakirov [EMAIL PROTECTED]:

Tim Ellison wrote:
 +1 for creating a jdktools directory.  The dependency on the classlib
 launcher should be relatively light if we go with a simple tools
 launcher that rewrites the tool invocation into a generic launcher
 invocation.  You may recall the idea was discussed a while ago.

Could anyone shed the light why launcher is considered part of classlib?

As far as I understand, it depends on standard JNI Invocation API,
and some Harmony-wide conventions about property names and files.
I would suggest that we move launcher from classlib/ to jdktools/ as well.


+1 to move launcher out of classlib. I was going to suggest this too.



Sorry if I am missing something.

P.S. +1 for original idea to create jdktools/







-
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]

Re: [r451637] - Code cleanup - ... - Remove unnecessary comments

[Alexey Varlamov]

2006/10/4, Nathan Beyer [EMAIL PROTECTED]:

If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.


Logging and printing to console essentially differ in flexible
customization offered by the first approach. An application can have
no console after all.
We develop the common class library here, not an ordinary application
- so let's not assume it will be used in some particular way.

In this concrete case, stack trace is printed every time invalid input
data is supplied - and it is normal for a unit test to cover some
negative cases.
But seeing console jammed with that rubbish is quite confusing (for me
at least). OTOH, such info would be valuable for app developer - so
why not satisfy both?



As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.

Because we have more priority tasks to be done. We just haven't
reached that stage of completeness, when we can afford minor refining
and polishing. Never say never, you know :)

Please, announce ahead if you do such things in future.

--
Regards,
Alexey



-Nathan

On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
 Nathan,

 I've seen you dropped many TODOs in - Code cleanup - series of commits;
 I'd like to know what reasoning was behind this? I think it's a bit
 early to erase TODOs without appropriate consideration...

 In particular, could you please undo the following change, it produces
 garbage messages during AUTH testing:

 
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
 ===
 @@ -216,12 +206,12 @@ public class DefaultConfigurationParser
 try {
 val = PolicyUtils.expand(st.sval, system);
 } catch (Exception e) {
 - //TODO: warning log
 - }
 + e.printStackTrace();
 + }
 }

 --
 WBR,
 Alexey

 -
 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]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[r451637] - Code cleanup - ... - Remove unnecessary comments

[Alexey Varlamov]

Nathan,

I've seen you dropped many TODOs in - Code cleanup - series of commits;
I'd like to know what reasoning was behind this? I think it's a bit
early to erase TODOs without appropriate consideration...

In particular, could you please undo the following change, it produces
garbage messages during AUTH testing:

modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
===
@@ -216,12 +206,12 @@ public class DefaultConfigurationParser
try {
val = PolicyUtils.expand(st.sval, system);
} catch (Exception e) {
- //TODO: warning log
- }
+ e.printStackTrace();
+ }
}

--
WBR,
Alexey

-
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][kernel exception handling] several issues

[Alexey Varlamov]

2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]:

Dear committers,



I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
suggested patches.

So, to avoid redoubling efforts or superposition of commits because of delay

could somebody take them under a control to estimate and apply if it is
necessary?

All the more, the 1650 and 1573 issues seem to be able to upset somehow the
execution stability of a big application.


Serguei,

the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud
consider reusing
org\apache\harmony\luni\internal\process\SystemProcess.java available
in luni rather than fixing alternative impl in DRLVM.
What do you think?

--
Regards,
Alexey



Great thanks in advance,

Serguei




-
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][kernel exception handling] several issues

[Alexey Varlamov]

Sure, this can wait - say, until classlib tests 100% pass on DRLVM, -
just to let current pace of major changes slow down.
Other than that, I see no compelling reasons to maintain duplicate
impl in DRLVM.
And you bet the reference impl in classlib is mature enough to not
affect VM stability ;)

--
Alexey

2006/10/3, Geir Magnusson Jr. [EMAIL PROTECTED]:

I tend to agree. I think that it's a good idea to consider for the
future, but right now, if the fixes help stabilize, great.  I think that
 stabilization is key right now.

geir


Serguei Zapreyev wrote:
 On 10/3/06, Alexey Varlamov [EMAIL PROTECTED] wrote:

 2006/10/3, Serguei Zapreyev [EMAIL PROTECTED]:
  Dear committers,
 
 
 
  I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
  suggested patches.
 
  So, to avoid redoubling efforts or superposition of commits because of
 delay
 
  could somebody take them under a control to estimate and apply if it is
  necessary?
 
  All the more, the 1650 and 1573 issues seem to be able to upset somehow
 the
  execution stability of a big application.

 Serguei,

 the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud
 consider reusing
 org\apache\harmony\luni\internal\process\SystemProcess.java available
 in luni rather than fixing alternative impl in DRLVM.
 What do you think?


 Alexey,

 I guess few items should be took into consideration before doing some
 conclusions here.

 First, DRLVM's implementation of Runtime has been checked during a lot of
 testing milestones.
 Second, its code is well known for DRLVM developers, so it's easy to
 maintain it in this hot time.
 Third, we have no good test set (like TCK) to compare the discussed impls.
 Forth, we have no methods to estimate performance of impls.
 ...

 So, I think your suggestion isn't too actual just now and may be considered
 some later.
 There is no need to upset the current stability just now.
 I think the attached patches should be applayed in the nearest time to
 improve the
 used code. All the more, this patch combines some issues apart from the
 Process.

 Thanks,
 Serguei

 --
 Regards,
 Alexey

 
  Great thanks in advance,
 
  Serguei
 
 

 -
 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]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [patch][drlvm] fix junit.jar download

[Alexey Varlamov]

Can't we just take junit.jar from classlib's depends (as we do with XALAN)?

2006/10/3, Salikh Zakirov [EMAIL PROTECTED]:

Geir,

it looks like the commit
[r452245] HARMONY-698  This should be equivalent to what HARMONY-698
broken the downloading of junit.jar (which we used to take from Eclipse 
distribution).

The below patch adds junit.jar as a separate download from ibiblio jar 
repository.

--- 8 ---

added downloading of junit.jar

diff --git build/make/lnx.properties build/make/lnx.properties
index c4f6c56..1404b5b 100644
--- build/make/lnx.properties
+++ build/make/lnx.properties
@@ -57,6 +57,10 @@ # APR-iconv, version 1.1.1 or above
 # http://apr.apache.org/download.cgi
 
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1.tar.gz

+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
 # LOG4CXX, svn revision 416779
 # http://logging.apache.org/site/cvs-repositories.html
 remote.LOG4CXX.archive=-r 416779 
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
diff --git build/make/setup.xml build/make/setup.xml
index e570ae0..be28782 100644
--- build/make/setup.xml
+++ build/make/setup.xml
@@ -105,6 +105,7 @@ Version: $Revision: 1.5.2.33 $
property name=CLASSLIB.check.file value=native-src/README.txt /
property name=XALAN.check.file value=xalan.jar /
property name=VM.check.file value=vmcore/src/init/vm_main.cpp /
+   property name=JUNIT.check.file value=junit-3.8.1.jar /
   property name=ANTLR.check.file value=antlr-2.7.5.jar /
property name=PATCHES.check.file value=README.txt /
/target
@@ -148,6 +149,12 @@ Version: $Revision: 1.5.2.33 $

target name=copy.nessessary.jars

+copy tofile=tmp/junit.jar
+fileset dir=${build.precopied.dir}/common/JUNIT
+include name=junit*.jar /
+/fileset
+/copy
+
propertyregex property=build.XALAN.path input=${if.XALAN.exist} 
regexp=(.*)/${XALAN.check.f
ile} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /

@@ -176,7 +183,7 @@ Version: $Revision: 1.5.2.33 $


target name=setup.resources depends=plugin.antcontrib
-property name=common.resources 
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES /
+property name=common.resources 
value=LOG4CXX,CPPTASKS,XALAN,VM,ANTLR,PATCHES,JUNIT /
property name=build.resources value=CPPTASKS /
if
isset property=if.lnx /
diff --git build/make/win.properties build/make/win.properties
index 51274f1..6753d2b 100644
--- build/make/win.properties
+++ build/make/win.properties
@@ -60,6 +60,10 @@ # APR-iconv, version 1.1.1 or above
 # http://apr.apache.org/download.cgi
 
remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1-win32-src.zip

+# JUnit, version 3.8.1 or above
+remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar
+remote.JUNIT.archive.type=asis
+
 # LOG4CXX, svn revision 416779
 remote.LOG4CXX.archive=-r 416779 
http://svn.apache.org/repos/asf/logging/log4cxx/trunk
 remote.LOG4CXX.archive.type=svn


-
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]

Re: [drlvm] HARMONY-1559 patch causes SIGABRT in VM code

[Alexey Varlamov]

2006/9/28, Elena Semukhina [EMAIL PROTECTED]:

The issue has gone away for me too, false alarm possibly...


Unfortunately the alarm was not false. Today I got the same failure:
   ...
   [junit] SIGABRT in VM code.
   [junit] java:
/nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:212:
StackIterator* si_create_from_native(): Assertion
`!interpreter_enabled()' failed.
   [junit] SIGABRT in VM code.
   [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/lin
   [junit] Test java.lang.RuntimeTest FAILED (timeout)

Therefore we face intermittent crash on interpreter...



Elena

On 9/28/06, Pavel Rebriy [EMAIL PROTECTED] wrote:

 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




--
Thanks,
Elena




-
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] HARMONY-1559 patch causes SIGABRT in VM code

[Alexey Varlamov]

Today this crash is reproduced quite stably during build.sh
kernel.test. But it always passes if run standalone :(

Regarding 1559 patch, I looked through it and found nothing
suspicious. The only change to interpreter itself was actually
preliminary fix for Harmony-1561. This is not good (1559 has no word
about this and now better patch is available), but not critical.


2006/10/2, Alexey Varlamov [EMAIL PROTECTED]:

2006/9/28, Elena Semukhina [EMAIL PROTECTED]:
 The issue has gone away for me too, false alarm possibly...

Unfortunately the alarm was not false. Today I got the same failure:
   ...
   [junit] SIGABRT in VM code.
   [junit] java:
/nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:212:
StackIterator* si_create_from_native(): Assertion
`!interpreter_enabled()' failed.
   [junit] SIGABRT in VM code.
   [junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/lin
   [junit] Test java.lang.RuntimeTest FAILED (timeout)

Therefore we face intermittent crash on interpreter...


 Elena

 On 9/28/06, Pavel Rebriy [EMAIL PROTECTED] wrote:
 
  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
 
 


 --
 Thanks,
 Elena





-
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] HARMONY-1559 patch causes SIGABRT in VM code

[Alexey Varlamov]

Trace logging gives some more details:

GC enumeration in interpreter stack:

0x0x413ee828 referenced from root = 0x0x52721d4c info = 0
0x0x413ee828 info = 0
0x0x413ee828 is java/lang/Class
move 0x0x413ee828 to 0x0x41253d24 info = 1
0x(nil) referenced from object = 0x0x41253d24
0x(nil) referenced from object = 0x0x41253d24
0x(nil) referenced from object = 0x0x41253d24
 [THIS]: java/lang/Class
[METHOD native]: java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I
0x0x414e9530 referenced from root = 0x0x52721f3c info = -2147480576
0x0x414e9530 info = -2147480576
0x0x414e9530 is java/lang/FinalizerThread$FinalizerWorkLock
move 0x0x414e9530 to 0x0x41253d44 info = -2147480575
 [THIS]: java/lang/FinalizerThread$FinalizerWorkLock
[METHOD 4 2]: java/lang/Object.wait()V
 Stack[0]
NPE or SOE detected at 0x4114fe18
---


2006/10/2, Alexey Varlamov [EMAIL PROTECTED]:

Today this crash is reproduced quite stably during build.sh
kernel.test. But it always passes if run standalone :(

Regarding 1559 patch, I looked through it and found nothing
suspicious. The only change to interpreter itself was actually
preliminary fix for Harmony-1561. This is not good (1559 has no word
about this and now better patch is available), but not critical.


2006/10/2, Alexey Varlamov [EMAIL PROTECTED]:
 2006/9/28, Elena Semukhina [EMAIL PROTECTED]:
  The issue has gone away for me too, false alarm possibly...

 Unfortunately the alarm was not false. Today I got the same failure:
...
[junit] SIGABRT in VM code.
[junit] java:
 
/nfs/ins/proj/drl/coreapi/avarlamo/harmony/linux.ia32/svn-repo/drlvm/vm/port/src/lil/ia32/pim/stack_iterator_ia32.cpp:212:
 StackIterator* si_create_from_native(): Assertion
 `!interpreter_enabled()' failed.
[junit] SIGABRT in VM code.
[junit] java: /nfs/ins/proj/drl/coreapi/avarlamo/harmony/lin
[junit] Test java.lang.RuntimeTest FAILED (timeout)

 Therefore we face intermittent crash on interpreter...

 
  Elena
 
  On 9/28/06, Pavel Rebriy [EMAIL PROTECTED] wrote:
  
   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
  
  
 
 
  --
  Thanks,
  Elena
 
 




-
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] HARMONY-1559 patch causes SIGABRT in VM code

[Alexey Varlamov]

2006/10/2, Alexey Varlamov [EMAIL PROTECTED]:

Trace logging gives some more details:

GC enumeration in interpreter stack:

0x0x413ee828 referenced from root = 0x0x52721d4c info = 0
0x0x413ee828 info = 0
0x0x413ee828 is java/lang/Class
move 0x0x413ee828 to 0x0x41253d24 info = 1
0x(nil) referenced from object = 0x0x41253d24
0x(nil) referenced from object = 0x0x41253d24
0x(nil) referenced from object = 0x0x41253d24
 [THIS]: java/lang/Class
[METHOD native]: java/lang/VMThreadManager.wait(Ljava/lang/Object;JI)I
0x0x414e9530 referenced from root = 0x0x52721f3c info = -2147480576
0x0x414e9530 info = -2147480576
0x0x414e9530 is java/lang/FinalizerThread$FinalizerWorkLock
move 0x0x414e9530 to 0x0x41253d44 info = -2147480575
 [THIS]: java/lang/FinalizerThread$FinalizerWorkLock
[METHOD 4 2]: java/lang/Object.wait()V
 Stack[0]
NPE or SOE detected at 0x4114fe18
---


I fixed endless looping in HARMONY-1653. And now we need to understand
why the SIGSEGV occurs. Is it corrupted stack or smth else?
Ivan, could you please look into this?

--
Alexey

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]