Re: [classlib][luni] signalis interruptus in hysock
Ivan Volosyuk wrote: On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Well, I think that the solution is what Geir suggests. One think which bothers me is following. EINTR can happen in different places and the situations can be quite rare in some circumstances. It can lead to hard to reproduce stability bugs (race conditions). Can you give an example? Half a year ago, I was working on the problem. Socket operations get sometimes interrupted. We have found out that it occurs sometime after GC. It was not quite easy as the application was quite big and situation - quite rare. I believe it is rare, but if the code deals with EINTR correctly, where can the race conditions come from? Given the fact, that current implementation of monitor reservation code can stop other thread in quite random fashion we should have rock solid support of EINTR handling everywhere the select(), poll() calls is used. Well... yeah. Not bury it. geir
Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best number
would
be. Given that 1904 patch is not the final solution, at least a diagnostic
that hints at where the system hangs would be useful. It might make sense
to even print a stack trace. Also, I agree with Ivan below. Signals bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places and the
situations can be quite rare in some circumstances. It can lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have rock
solid support of EINTR handling everywhere the select(), poll() calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and hdk
LOL. Soon. Maybe tomorrow :) Until then, use javac from Sun. Or IBM. Or BEA. :) geir Matthias Wessendorf wrote: ok, so when will there be an executable javac ? :) On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Matthias Wessendorf wrote: hey, I think I read somewhere something about javac now in tools or so. I am currently not able to download the HDK, but is there (or in next snap) a javac executable? There will be in an upcoming snapshot, but not in the HDK. The HDK is not a JDK, but rather a full build of the modules of the classlibrary to assist developers in developing modules in the classlibrary. It allows you to develop one at a time (rather than checking out the whole thing). geir Thx, Matt
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Mikhail, I guess there is miscommunication. I didn't suggest to put GC TLS data to VM_Thread, I think it should have its own TLS key. My suggestion is to use single key for GC TLS data block pointer, then use an additional dereference for a GC TLS data field. Thanks, xiaofeng On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Xiao-Feng, On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Mikhail, we want to seperate the GC module from TM so that only limited VM APIs are accessed from GC. That means, we want a simpler API to get GC thread info than accessing GC TLS data individually. Using info.get_tls_current_free() to access a field info of GC TLS data looks like not very elegant. Can't we deference once to get the field info from (GC TLS data pointer + offset_of_free_in_GC_tls)? The current hythread API we have allows to allocate keys for void* sized values only. Let's ask TM developers why can't we allocate N*(void*) sized values with a single key? The situation we have is rather simple: VM_thread does not allow you to have static offsets (so your helper could not be efficiently inlined) and to access to a data in VM_thread you have to perform +1 memory access in comparison with access to HyThread fields. This can keep the GC_Thread_Info of GC (or Allocator structure in GCv5). I think this is important for modularity. Thanks. Here we have different vision what modularity is. Thread Manager is responsible to work with threads, so I do not understand why VM should delegate all of the API of TM that is needed by different components? In this case VM must do it for every component, not only for TM, isn't it? The same is with VM_thread: the way it keeps gc_private_data is a hack that brokes the design. What if GC needs more TLS slots than available in VM_thread? What if a component XYZ needs TLS data? Will we add it to VM_thread xyz_private_data[N] field? -- Mikhail Fursov
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
On 10/24/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Yes, the lock is global. I used try_enter() to prevent possible deadlock scenario, when the finalization happens at precisely the moment finalization thread is holding the finalization lock. If this happens, and vm_hint_finalize() cannot grab the finalization monitor, no harm is taken, because locked finalization monitor means that the finalization thread is active, and does not need to be waked up. +1 to Salikh's solution. Why should we call Java from vm-helpers to run finalization threads when all we need could be done in native code safely: just check monitor and call notify if needed. -- Mikhail Fursov
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
On 10/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: Your fix just switch off Finalization Work Balance Subsystem Pavel, could Work Balance Subsystem be implemented in finilizers threads directly. That is we will not have Java code executed from helpers? -- Mikhail Fursov
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
No. It couldn't. I don't now any solution which can do it. Pavel Afremov. On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: Your fix just switch off Finalization Work Balance Subsystem Pavel, could Work Balance Subsystem be implemented in finilizers threads directly. That is we will not have Java code executed from helpers? -- Mikhail Fursov
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
The Work Balance Subsystem task is to start new finalizing threads when all active threads are busy, isn't it? The solution could be: 1) Add +1 thread: finalizers manager 2) notify this thread (as Salikh proposed) to start finalization and do the Work Balance Subsystem job. Does it work or am I missing something? On 10/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: No. It couldn't. I don't now any solution which can do it. Pavel Afremov. On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: Your fix just switch off Finalization Work Balance Subsystem Pavel, could Work Balance Subsystem be implemented in finilizers threads directly. That is we will not have Java code executed from helpers? -- Mikhail Fursov -- Mikhail Fursov
Re: [drlvm][smoke_test] running kernel classes tests on DRLVM compiled with Intel Compiler (linux/ia32)
On 10/24/06, Gregory Shimansky [EMAIL PROTECTED] wrote: BTW to test how things work with Intel compiler I've installed it on Gentoo (version 9.1.042, it is marked as unstable, but the most recent stable is very old - 7.1.006... which version do you use?) and failed to compile drlvm with it. Something is wrong with thread manager linking build.native.link: [cc] 0 total files to be compiled. [cc] Starting link [cc] ld: tm_self_tls: TLS definition in ../_obj/thread_native_basic.o section .tbss mismatches non-TLS reference in ../_obj/thread_native_condvar.o [cc] ../_obj/thread_native_condvar.o: could not read symbols: Bad value BUILD FAILED Does anyone know what's wrong and how to fix it? I tried to understand how tm_self_tls is defined and couldn't, because its definition and usage in different files is quite complicated. Maybe I need newer binutils (current version is 2.16.1-r3 - latest stable), the Bad value seems to hint on this. My binutils version is 2.15.91.0.2. Yours are newer.. -- Nataly Naumova, Intel Middleware Products Division
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Is this a fix or a workaround? Is there a bug in ECJ? geir Me and Evgueni consider this a fix. We should adapt the algorithm of accessibility control to working with classes compiled with both compilers. The difference berween compilers is that javac does not provide any modifiers to local classes while ECJ makes them private. On the other hand, javac provides some data for local classes while ECJ does not (and here is a bug in ECJ). The algorithm of checking accessibility has been modified so that it does not fully rely on the data provided by compiler for local classes but makes an additional check of local class modifiers to ensure proper accessibility control for local classes. Elena Semukhina wrote: I attached the patch to H-1931 which fixes algorithm of checking accessibility. Please review! On 10/24/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: I think getEnclosingClass returns null not because of the strange name but because it doesn't generate the enclosing method attribute for local classes. Evgueni On 10/24/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 24 October 2006 05:12 Nathan Beyer wrote: By inner class you mean an automatic/local class in this case; a class declared inside a method. It would seem appropriate that a local class is declared private. Only the method that contains the class declaration can see it. Do you disagree with what ECJ is generating? After reading this thread I think you are right and it is ok to generate private attribute for inner classes. There is another difference between compilers output. Sun compiler and ECJ generate different class names for Test1931_2.java inner class. Sun compiler creates Test1931_2$1LocalClass.class while ECJ creates Test1931_2$1$LocalClass.class. It might be not the cause of the bug in this case, but I wonder whether naming of inner classes is specified somewhere. Shouldn't names be the same for all compilers? On 10/23/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Sunday 22 October 2006 01:08 Nathan Beyer wrote: I haven't had a chance to look at the issue (JIRAs down right now, probably part of the infrastructure move), but have you tried comparing the actual class files of the problematic class or classes. I'd suggest compiling the files using ECJ, save them off, compile with Sun/BEA/etc, save them off and then run javap from a single JDK on each of the class files and compare them for differences. Yes, it is quite interesting how different compilers produce different class attributes, it looks like this is the main problem with the code. ECJ insists on marking inner classes private. Elena was kind to send me another test which she wrote while JIRA was down and it shows even a bigger difference between the compilers - it produces different output on RI. In the 2nd test ECJ creates an inner in anonymous class Test1931_2$1$LocalClass while Sun creates Test1931_2$1LocalClass. This gives different output from cc.getEnclosingClass and cc.isLocalClass where cc is the used inner class. Nevertheless RI allows the access to the inner private class it seems. It doesn't throw the exception which drlvm does. The exception source is drlvm's kernel class ReflectExporter and the method in question is allowAccess which calls allowClassAccess at line 113. This check is the one and the only chance to return true in this case. I've debugged the code with recently implemented debugging support of drlvm using eclipse (jdwp agent has to be build for this from HARMONY-1410, also kernel classes for drlvm aren't compiled with debug support, build script has to be hacked) but I just don't know all of the access checks specification statements to make a decision which one is not correct. P.S. I used ecj 3.2 which we use for current classlib compilation. -- Gregory Shimansky, Intel Middleware Products Division -- Thanks, Elena
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Good idea Mikhail! I think I will base on it in my future solution. I see only one negative side for it. Quantity of the treads increased by one in normal situation. Any ideas? Thanks. Pavel Afremov. On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: The Work Balance Subsystem task is to start new finalizing threads when all active threads are busy, isn't it? The solution could be: 1) Add +1 thread: finalizers manager 2) notify this thread (as Salikh proposed) to start finalization and do the Work Balance Subsystem job. Does it work or am I missing something? On 10/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: No. It couldn't. I don't now any solution which can do it. Pavel Afremov. On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: Your fix just switch off Finalization Work Balance Subsystem Pavel, could Work Balance Subsystem be implemented in finilizers threads directly. That is we will not have Java code executed from helpers? -- Mikhail Fursov -- Mikhail Fursov
Re: [general] POLL : supported platforms
On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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: RE: [classlib][test] Configuration dependent test of InetAddress.getHostName
Not sure if this is covered in a test elsewhere, but we could check that the getLocalName() returns a non-null, non-empty string? After all, both localhost and 127.0.0.1 should return valid lookups. The other possibiltiy is to fork an 'nslookup' or 'host' command (depending on platform) to find out what the platform thinks is the local host name, and then comparing it to Java's result. Alex. On 25/10/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Denis wrote, It's possible but it will be another test Agreed +1 exclude this test (not whole test but localhost check) +1 With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Denis Kishenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 3:31 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][test] Configuration dependent test of InetAddress.getHostName 2006/10/24, Fedotov, Alexei A [EMAIL PROTECTED]: I wonder about the first option. Is there any way to check that symbolic name corresponds to the local computer? I can imagine the following condition to check this. InetAddress.getByName(InetAddress.getByName(127.0.0.1).getHostName()). isLoopbackAddress() This test failed because isLoopbackAddress() expected 127.X.X.X 2006/10/24, Fedotov, Alexei A [EMAIL PROTECTED]: Andrew, I agree that test should be fixed. I suggested using one of the following checks to validate that the host is localhost. InetAddress.getByName(host).isLoopbackAddress() InetAddress.getByName(host).isSiteLocalAddress() It's possible but it will be another test IMHO +1 exclude this test (not whole test but localhost check)
Re: [drlvm] Class unloading support
On 10/25/06, Aleksey Ignatenko [EMAIL PROTECTED] wrote: Egor, But it has 1 more cons -- JIT should change it's devirtualizer accordingly to the VTable change. Doable, of course. There is no need to change struct VTable structure - it could be simply inlined in pinned VTable object + 1 additional reference field to j.l.Class. So there won't be too much work to do on JIT side. +1 for Automatic class unloading approach. But, please, keep vtables pinned in the first version. If you make vtable objects unpinned JIT have to track if the object is moved and patch all devirtualized calls (not a simple task..). -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, Mikhail, how about this: In GC thread init: gc_tls_data_ptr = malloc_gc_tls_data(sizeof(GC_Thread_Info) ); gc_tls_key = thread_create_tls_key(); thread_set_tls_data( gc_tls_key, gc_tls_data_ptr); To fast alloc: gc_tls_data_ptr = thread_get_tls_data( gc_tls_key); free = *(gc_tls_data_ptr + offset_of_free_in_gc_tls); Can't this work? Sounds like I missed something? Xiao-Feng, Yes we talking about the same functionality. The problem with your example is that TM has no such an API :) The only method we have is 'hythread_tls_alloc (hythread_tls_key_t* handle);' and it allocates sizeof(void*) bytes in TLS struct. And the method we need is: 'hythread_tls_alloc (hythread_tls_key_t* handle, size_t bytes);' or 'hythread_tls_alloc (hythread_tls_key_t* handle, size_t numSlots);' where numSlots for GC is ~ sizeof(GC_Thread_Info)/sizeof (void*) -- Mikhail Fursov
RE: [general] POLL : supported platforms
Stepan, I support you idea, but IMHO the page you pointed out to is out-of-date. I suggest using http://wiki.apache.org/harmony/Platforms_to_Run_Harmony_Development_Kit_ on as it seems to be much more suitable. I tried to support it adding up-to-date info and posting the discussion issues. I'll be glad if you find the aforementioned page useful :) Cheers, Sveta -Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 11:46 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [general] POLL : supported platforms On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
On 10/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: Good idea Mikhail! I think I will base on it in my future solution. I see only one negative side for it. Quantity of the treads increased by one in normal situation. Any ideas? the only idea I have is to spawn N threads at once if finalization queue is too long.. ? -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, Mikhail, how about this: In GC thread init: gc_tls_data_ptr = malloc_gc_tls_data(sizeof(GC_Thread_Info) ); gc_tls_key = thread_create_tls_key(); thread_set_tls_data( gc_tls_key, gc_tls_data_ptr); To fast alloc: gc_tls_data_ptr = thread_get_tls_data( gc_tls_key); free = *(gc_tls_data_ptr + offset_of_free_in_gc_tls); Can't this work? Sounds like I missed something? Xiao-Feng, Yes we talking about the same functionality. The problem with your example is that TM has no such an API :) The only method we have is 'hythread_tls_alloc (hythread_tls_key_t* handle);' and it allocates sizeof(void*) bytes in TLS struct. And the method we need is: 'hythread_tls_alloc (hythread_tls_key_t* handle, size_t bytes);' or 'hythread_tls_alloc (hythread_tls_key_t* handle, size_t numSlots);' where numSlots for GC is ~ sizeof(GC_Thread_Info)/sizeof (void*) Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Thanks, xiaofeng -- Mikhail Fursov
Re: [general] POLL : supported platforms
On 10/25/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Comments? Objections? Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? What is works OK? Builds and runs classlib/drlvm tests only? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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] -- Mikhail Fursov
Re: RE: [classlib][test] Configuration dependent test of InetAddress.getHostName
2006/10/25, Alex Blewitt [EMAIL PROTECTED]: The other possibiltiy is to fork an 'nslookup' or 'host' command (depending on platform) to find out what the platform thinks is the local host name, and then comparing it to Java's result. On this WinServer2003 nslookup localhost and nslookup 127.0.0.1 return skip server info Name:localhost Address: 127.0.0.1 So it will not help =(
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Xiao-Feng, Even if you do not need to have constant offsets, it's better to use TM directly to allocate TLS slots. In this case we can remove extra code from VM: the computation of the third parameter in the next method: extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size, Allocation_Handle type, void *thread_pointer); On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Yes you can store a pointer. But in this case you can't tell that you have constant offset from fs[14] to your data for all threads. So you can't inline your helper in JIT. -- Mikhail Fursov -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Yes you can store a pointer. But in this case you can't tell that you have constant offset from fs[14] to your data for all threads. So you can't inline your helper in JIT. Why? As long as we keep the offset_of_free to the pointer be constant and known to JIT helper, we only need an additional dereference to get the free value. We have two constant offsets, one is the pointer (to gc_tls_data) offset in fs[14], the other is the free offset in gc_tls_data. Thanks, xiaofeng -- Mikhail Fursov
Re: [general] POLL : supported platforms
does it make sense to put it on the site? Thanks, Mikhail 2006/10/25, Stepan Mishura [EMAIL PROTECTED]: On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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][gc] TLS access from GC: a proposal to refactor the code
+1 -- Ivan Intel Enterprise Solutions Software Division On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Mikhail, I guess there is miscommunication. I didn't suggest to put GC TLS data to VM_Thread, I think it should have its own TLS key. My suggestion is to use single key for GC TLS data block pointer, then use an additional dereference for a GC TLS data field. Thanks, xiaofeng On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Xiao-Feng, On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Mikhail, we want to seperate the GC module from TM so that only limited VM APIs are accessed from GC. That means, we want a simpler API to get GC thread info than accessing GC TLS data individually. Using info.get_tls_current_free() to access a field info of GC TLS data looks like not very elegant. Can't we deference once to get the field info from (GC TLS data pointer + offset_of_free_in_GC_tls)? The current hythread API we have allows to allocate keys for void* sized values only. Let's ask TM developers why can't we allocate N*(void*) sized values with a single key? The situation we have is rather simple: VM_thread does not allow you to have static offsets (so your helper could not be efficiently inlined) and to access to a data in VM_thread you have to perform +1 memory access in comparison with access to HyThread fields. This can keep the GC_Thread_Info of GC (or Allocator structure in GCv5). I think this is important for modularity. Thanks. Here we have different vision what modularity is. Thread Manager is responsible to work with threads, so I do not understand why VM should delegate all of the API of TM that is needed by different components? In this case VM must do it for every component, not only for TM, isn't it? The same is with VM_thread: the way it keeps gc_private_data is a hack that brokes the design. What if GC needs more TLS slots than available in VM_thread? What if a component XYZ needs TLS data? Will we add it to VM_thread xyz_private_data[N] field? -- Mikhail Fursov
Re: [drlvm][smoke_test] running kernel classes tests on DRLVM compiled with Intel Compiler (linux/ia32)
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Hello Nataly It looks like a workaround to me to run the tests for VM. To run other user applications we need a general solution about what to do with non standard libraries which Intel compiler links with. On Gentoo if you install icc, the system adds an entry to autogenerated /etc/ld.so.conf with path to Intel compiler installation to automatically include these libraries to linking path, but it seems not to be the case for other distributions like yours. How useful is this if you want to give the binary to someone else? It looks like it is either necessary to distribute these libraries with the binaries (I am not sure license allows it) or link statically with them if it is possible. -- Gregory Shimansky, Intel Middleware Products Division
RE: [general] POLL : supported platforms
Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) Well... are you sure? Or do you make this supposition judging by the Platforms to Run Harmony Development Kit on page? The point is that I didn't have enough info to fill in the empty table cells. My aim was to create a field for developers' comments and the table there is right for their convenience. :) I'd like to ask developers using different platforms to leave their comments there to get the clear picture of what we have for now. Does it make sense? I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Cheers, Sveta -Original Message- From: Mikhail Fursov [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 12:11 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] POLL : supported platforms On 10/25/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Comments? Objections? Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? What is works OK? Builds and runs classlib/drlvm tests only? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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] -- Mikhail Fursov
Re: [drlvm][smoke_test] running kernel classes tests on DRLVM compiled with Intel Compiler (linux/ia32)
Nataly Naumova wrote: On 10/24/06, Gregory Shimansky [EMAIL PROTECTED] wrote: BTW to test how things work with Intel compiler I've installed it on Gentoo (version 9.1.042, it is marked as unstable, but the most recent stable is very old - 7.1.006... which version do you use?) and failed to compile drlvm with it. Something is wrong with thread manager linking build.native.link: [cc] 0 total files to be compiled. [cc] Starting link [cc] ld: tm_self_tls: TLS definition in ../_obj/thread_native_basic.o section .tbss mismatches non-TLS reference in ../_obj/thread_native_condvar.o [cc] ../_obj/thread_native_condvar.o: could not read symbols: Bad value BUILD FAILED Does anyone know what's wrong and how to fix it? I tried to understand how tm_self_tls is defined and couldn't, because its definition and usage in different files is quite complicated. Maybe I need newer binutils (current version is 2.16.1-r3 - latest stable), the Bad value seems to hint on this. My binutils version is 2.15.91.0.2. Yours are newer.. Could you also tell me which version of icc you are using? -- Gregory Shimansky, Intel Middleware Products Division
RE: [general] POLL : supported platforms
My two cents... I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Do you think we can add a note with the revision number? This way, you at least know that the code of revision worked ok/failed on this platform. Because such tests are done systematically, changing revisions would not take much time to update. -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 12:59 PM To: harmony-dev@incubator.apache.org Subject: RE: [general] POLL : supported platforms Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) Well... are you sure? Or do you make this supposition judging by the Platforms to Run Harmony Development Kit on page? The point is that I didn't have enough info to fill in the empty table cells. My aim was to create a field for developers' comments and the table there is right for their convenience. :) I'd like to ask developers using different platforms to leave their comments there to get the clear picture of what we have for now. Does it make sense? I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Cheers, Sveta -Original Message- From: Mikhail Fursov [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 12:11 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] POLL : supported platforms On 10/25/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Comments? Objections? Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? What is works OK? Builds and runs classlib/drlvm tests only? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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] -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Xiao-Feng, I think there should be no problem to get this to work. But, I also agree with Mikhail that it could be benefitial to have data directly available in TLS without additional pointer dereference. If we will have corresponding interface function to allocate more then one void pointer at once in TLS it can be used as optimization. -- Ivan On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Yes you can store a pointer. But in this case you can't tell that you have constant offset from fs[14] to your data for all threads. So you can't inline your helper in JIT. Why? As long as we keep the offset_of_free to the pointer be constant and known to JIT helper, we only need an additional dereference to get the free value. We have two constant offsets, one is the pointer (to gc_tls_data) offset in fs[14], the other is the free offset in gc_tls_data. Thanks, xiaofeng -- Mikhail Fursov
RE: [general] POLL : supported platforms
Do you think we can add a note with the revision number? This way, you at least know that the code of revision worked ok/failed on this platform. Because such tests are done systematically, changing revisions would not take much time to update. +1 Good idea! :) Cheers, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 1:04 PM To: harmony-dev@incubator.apache.org Subject: RE: [general] POLL : supported platforms My two cents... I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Do you think we can add a note with the revision number? This way, you at least know that the code of revision worked ok/failed on this platform. Because such tests are done systematically, changing revisions would not take much time to update. -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 12:59 PM To: harmony-dev@incubator.apache.org Subject: RE: [general] POLL : supported platforms Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) Well... are you sure? Or do you make this supposition judging by the Platforms to Run Harmony Development Kit on page? The point is that I didn't have enough info to fill in the empty table cells. My aim was to create a field for developers' comments and the table there is right for their convenience. :) I'd like to ask developers using different platforms to leave their comments there to get the clear picture of what we have for now. Does it make sense? I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Cheers, Sveta -Original Message- From: Mikhail Fursov [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 12:11 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] POLL : supported platforms On 10/25/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Comments? Objections? Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? What is works OK? Builds and runs classlib/drlvm tests only? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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] -- Mikhail Fursov
Re: [drlvm][smoke_test] running kernel classes tests on DRLVM compiled with Intel Compiler (linux/ia32)
Could you also tell me which version of icc you are using? Sorry - icc -V Intel(R) C Compiler for 32-bit applications, Version 9.0Build 20051020Z Package ID: l_cc_c_9.0.027 -- Nataly Naumova, Intel Middleware Products Division
Re: [general] POLL : supported platforms
On 10/25/06, Mikhail Loenko wrote: does it make sense to put it on the site? To put what? The definition of supported platform or/and the list of supported platforms? I think it makes sense to put at least the definition. Thanks, Stepan. Thanks, Mikhail 2006/10/25, Stepan Mishura On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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: [classlib][awt] Revision #465514 broke image decoders.
Since the ImageConsumer accepts Hashtable?,? my thought is that the the GifDecoder should declare the field based on what it actually uses. If the other decoders only use String keys and String values, then I would suggest we change the field declaration to match. Yes, it sounds reasonable. On 10/25/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Nathan, could you, please tell why you changed the field properties in these classes to HashtableObject,Object in two of them and to HashtableString,String in one of them (GifDecoder)? Look at the declaration in the ImageConsumer class: void setProperties(Hashtable?,? props) It'd be better to have Hashtable?,? as a type in all 3 classes and HashtableObject,Object as an initial value for this field. A field type of Hashtable?,? would be painful, as you can't perform any sets when a type variable is ?. You'd have to cast it to HashtableObject,Object before performing any sets. Since the ImageConsumer accepts Hashtable?,? my thought is that the the GifDecoder should declare the field based on what it actually uses. If the other decoders only use String keys and String values, then I would suggest we change the field declaration to match. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? Unfortunately, these classes are not covered with the unit tests. I was running a simple test application that did something like this: Toolkit.getDefaultToolkit().getImage(image.jpg); and if failed with a NPE. I removed the final modifiers At the first glance it seems like the problem doesn't appear any more. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? Only final fields. No other issues. But 3-4 in 3 classes - it is alot for me :) On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: I removed the final modifiers; this only affected PngDecoder, GifDecoder and JpegDecoder. I missed the comments in the fields of JpegDecoder, that was my mistake. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? -Nathan On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? I'll remove the final modifiers. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hi, Rev. 465514 introduced a lot of invalid modifications to the GifDecoder, PngDecoder and JpegDecoder. There were a number of fields modified or initialized from the native code only, but they were redeclared as final, so the decoders doesn't work properly any more. This revision has the following comment: Cleanup code * Add if/else braces * Add missing annotations * Add type variables * Use foreach loops * etc I'd suggest to roll back this revision and redo the cleanup in the more accurate way. Thanks, Oleg
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Yes, this can be an optimization. I am not very sure if we can get obvious performance improvement with this. I am usually conservative with interface change. :-) Since neither Windows nor Linux provides this kind of native support, I am guessing they have their rationality. We probably want to delay this optimization in TM until we have evidance for it, since what Mikhail wants is just to inline GC tls data access easily. Thanks, xiaofeng On 10/25/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Xiao-Feng, I think there should be no problem to get this to work. But, I also agree with Mikhail that it could be benefitial to have data directly available in TLS without additional pointer dereference. If we will have corresponding interface function to allocate more then one void pointer at once in TLS it can be used as optimization. -- Ivan On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Yes you can store a pointer. But in this case you can't tell that you have constant offset from fs[14] to your data for all threads. So you can't inline your helper in JIT. Why? As long as we keep the offset_of_free to the pointer be constant and known to JIT helper, we only need an additional dereference to get the free value. We have two constant offsets, one is the pointer (to gc_tls_data) offset in fs[14], the other is the free offset in gc_tls_data. Thanks, xiaofeng -- Mikhail Fursov
[drlvm][crash] Cannot run anything on Linux
Guys, Last two days I cannot run the simplest things on DRLVM on Linux: drlvm/build/lnx_ia32_gcc_debug/deploy/jre/bin/java -cp . NoSuchClass free(): invalid pointer 0x808d800 [launcher crash dump follows] Is it my local problem? Or someone have faced this as well? With best regards, Alexei Fedotov, Intel Java XML Engineering
Re: [general] POLL : supported platforms
yes, I mean the current definitions Then we could discuss the lists Thanks, Mikhail 2006/10/25, Stepan Mishura [EMAIL PROTECTED]: On 10/25/06, Mikhail Loenko wrote: does it make sense to put it on the site? To put what? The definition of supported platform or/and the list of supported platforms? I think it makes sense to put at least the definition. Thanks, Stepan. Thanks, Mikhail 2006/10/25, Stepan Mishura On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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: [general] POLL : supported platforms
On 10/25/06, Mikhail Fursov wrote: On 10/25/06, Konovalova, Svetlana [EMAIL PROTECTED] wrote: Comments? Objections? Wow! the only platform with bugs we have is Windows XP with VS.NET 2005 Community Edition ! :) I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? I guess - you'll update :-) What is works OK? Builds and runs classlib/drlvm tests only? I meant running Harmony's build-and-test infra. (IIUC it includes classlib/vm tests but it can include other testing scenarios). You set up it on platform of your interest and report to the mailing list regularly about build/test status. Also you may wish to suggest a fix for the platform. Then it will be clear for all that your platform is supported. Thanks, Stepan. Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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] -- Mikhail Fursov -- Stepan Mishura 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: [general] POLL : supported platforms
I suggest just to provide just the definition and to add a link from the site to the corresponding wiki page. Cheers, Sveta -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] POLL : supported platforms yes, I mean the current definitions Then we could discuss the lists Thanks, Mikhail 2006/10/25, Stepan Mishura [EMAIL PROTECTED]: On 10/25/06, Mikhail Loenko wrote: does it make sense to put it on the site? To put what? The definition of supported platform or/and the list of supported platforms? I think it makes sense to put at least the definition. Thanks, Stepan. Thanks, Mikhail 2006/10/25, Stepan Mishura On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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][gc] TLS access from GC: a proposal to refactor the code
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: We probably want to delay this optimization in TM until we have evidance for it, since what Mikhail wants is just to inline GC tls data access easily. Ok, I understand it and agree. Today I'm going do the measurements/changes only for gc_cc. Another part of the question is interface. Xiao-Feng, could you make GCv5 to access TLS with TM but not VM? In other words make the third parameter of the method unused, so I can remove it at all: extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size, Allocation_Handle type, void *thread_pointer); ? -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Hello All, in general we do not have any objections to implement such functionality, but as far as I understand this will be quite unique TM feature (no other threading library have this, or give me a link) which is intended to improve performance. And if we going to extend TM interface for this, I would like to have any performance data beforehand, do we any data? Thank you. Nik. On 10/25/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Xiao-Feng, I think there should be no problem to get this to work. But, I also agree with Mikhail that it could be benefitial to have data directly available in TLS without additional pointer dereference. If we will have corresponding interface function to allocate more then one void pointer at once in TLS it can be used as optimization. -- Ivan On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Yes you can store a pointer. But in this case you can't tell that you have constant offset from fs[14] to your data for all threads. So you can't inline your helper in JIT. Why? As long as we keep the offset_of_free to the pointer be constant and known to JIT helper, we only need an additional dereference to get the free value. We have two constant offsets, one is the pointer (to gc_tls_data) offset in fs[14], the other is the free offset in gc_tls_data. Thanks, xiaofeng -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
No problem, I can modify GCv5 for this. Thanks, -xiaofeng On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: We probably want to delay this optimization in TM until we have evidance for it, since what Mikhail wants is just to inline GC tls data access easily. Ok, I understand it and agree. Today I'm going do the measurements/changes only for gc_cc. Another part of the question is interface. Xiao-Feng, could you make GCv5 to access TLS with TM but not VM? In other words make the third parameter of the method unused, so I can remove it at all: extern Managed_Object_Handle (*gc_alloc_fast)(unsigned size, Allocation_Handle type, void *thread_pointer); ? -- Mikhail Fursov
Re: [general] Announcing newest members of the Harmony PPMC
Congratulations! Geir Magnusson Jr. wrote: As progress towards our goal of having all committers on the PPMC, the Harmony PPMC is proud to announce it's newest members : Nathan Beyer Paulex Yang Weldon Washburn Please join us in congratulating them (and then tell them to get back to work...) :) The Harmony PPMC -- Oliver Deakin IBM United Kingdom Limited
Re: [general] Announcing newest members of the Harmony PPMC
My congratulations! 2006/10/25, Geir Magnusson Jr. [EMAIL PROTECTED]: As progress towards our goal of having all committers on the PPMC, the Harmony PPMC is proud to announce it's newest members : Nathan Beyer Paulex Yang Weldon Washburn Please join us in congratulating them (and then tell them to get back to work...) :) The Harmony PPMC -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [classlib][test] Configuration dependent test of InetAddress.getHostName
On 10/24/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Andrew,
I agree that test should be fixed. I suggested using one of the
following checks to validate that the host is localhost.
InetAddress.getByName(host).isLoopbackAddress()
InetAddress.getByName(host).isSiteLocalAddress()
I have checked this on RI. Windows system reports true for
isLoopbackAddress and false for isSiteLocalAddress. Linux report is
completely opposite. Reading the spec doesn't help me much as well.
Do you have any ideas how the test should be revised? Should we use
these checks, or try something else?
Actually I don't have any idea too. I asked the same question before on
mailing list, bug got no solution. Therefore, I suggest simply comment this
test or comment the assert statement. yes, It's not good, but better than
build system failure on some platforms. :)
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 24, 2006 5:45 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][test] Configuration dependent test of
InetAddress.getHostName
On 10/20/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Denis,
Can we consider a patch from
http://issues.apache.org/jira/browse/HARMONY-73 as a fourth option?
Simply speaking, the patch adds a conditional operator which forces
API
to returning localhost in this case.
No. I think Harmony does the right thing. We can't force harmony to
return
localhost, which should depend on host file.
The evil is the test. I think we'd better revise the test.
Paulex,
This is your patch. What do you think?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 3:44 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][test] Configuration dependent test of
InetAddress.getHostName
I have researched issue H-1664 and found one more difference with
RI.
I run simple test on Windows Server 2003 SP1
=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;
public class Test {
public static void main(String[] args) throws
UnknownHostException
{
System.out.println(by name (127.0.0.1) - +
InetAddress.getByName(127.0.0.1).getHostName());
System.out.println(by name (localhost) - +
InetAddress.getByName(localhost).getHostName());
System.out.println(by address - +
InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println(localhost - +
InetAddress.getLocalHost());
}
}
Windows Server 2003 SP1
=== RI ==
by name (127.0.0.1) - 127.0.0.1
by name (localhost) - localhost
by address - 127.0.0.1
localhost - nstdrlew21/10.125.122.60
= Harmony ==
by name (127.0.0.1) - nstdrlew21.ins.intel.com
by name (localhost) - localhost
by address - nstdrlew21.ins.intel.com
localhost - nstdrlew21/10.125.122.60
WinXP
= Both ===
by name (127.0.0.1) - localhost
by name (localhost) - localhost
by address - localhost
localhost - pbwdmkishen/10.125.132.226
Actually Harmony use native call of getnameinfo() to get host name
(which is reasonable IMHO). MSDN says The getnameinfo function
provides name resolution from an address to the host name.
InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName(127.0.0.1).getHostName() returned
nstdrlew21.ins.intel.com while localhost expected. So this test
looks like configuration dependent.
I see three possible options
1. Stay test as is. Just keep in mind that on specific
configurations
this one fails.
2. Rewrite test to be configuration dependent. Test has to do the
same
native call.
3. Exclude localhost checking from test_getHostName.
What do you think about this situation?
--
Denis M. Kishenko
Enterprise Solutions Software 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,
Andrew Zhang
--
Best regards,
Andrew Zhang
Re: [general] POLL : supported platforms
On 10/25/06, Stepan Mishura [EMAIL PROTECTED] wrote: I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? I guess - you'll update :-) This is optimistic behaviour:). Let's try and see if it works. I meant running Harmony's build-and-test infra. (IIUC it includes classlib/vm tests but it can include other testing scenarios). You set up it on platform of your interest and report to the mailing list regularly about build/test status. Your definition of Works OK could be interpreted in different ways for different platforms. This is the only thing I do not like in it. -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Thank you. Just tell me when GCv5 is ready and I'll clean VM part. + This is not the first priority task today. On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: No problem, I can modify GCv5 for this. Thanks, -xiaofeng -- Mikhail Fursov
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
On 10/25/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Hello All,
in general we do not have any objections to implement such
functionality, but as far as I understand this will be quite unique TM
feature (no other threading library have this, or give me a link)
which is intended to improve performance. And if we going to extend TM
interface for this, I would like to have any performance data
beforehand, do we any data?
Thank you.
Nik.
The patch 1949 emulates this behaviour without the support. The only
negative impact is the syntax. Instead of mapping the whole structure to
memory we have to operate with fields by offsets:
void set_tls_current_free(unsigned char* v) {*(unsigned char**)(tls_base
+ tls_offset_current) = v;}
void set_tls_current_cleaned(unsigned char* v) {*(unsigned
char**)(tls_base + tls_offset_clean) = v;}
void set_tls_current_ceiling(unsigned char* v) {*(unsigned
char**)(tls_base + tls_offset_ceiling) = v;}
As for your request for additional performance data: I do not have any
today. But I put this in my TODO list.
--
Mikhail Fursov
Re: [general] POLL : supported platforms
Stepan Mishura wrote: On 10/16/06, *Geir Magnusson Jr.* wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? That captures my feeling of it, for the most part. I think it's still early - we'll rally around a few now, but as our platform and build becomes more portable, I expect more activity and having to revisit this question again. geir Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: [general] POLL : supported platforms
Konovalova, Svetlana wrote: Stepan, I support you idea, but IMHO the page you pointed out to is out-of-date. I suggest using http://wiki.apache.org/harmony/Platforms_to_Run_Harmony_Development_Kit_ on as it seems to be much more suitable. I tried to support it adding up-to-date info and posting the discussion issues. I'll be glad if you find the aforementioned page useful :) I don't think that's a good page, because I think that what you mention above is developer-focused, and our support platforms is an end-user concept. geir Cheers, Sveta -Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 11:46 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [general] POLL : supported platforms On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86
Re: [general] POLL : supported platforms
Yes - lets just get something up on the wiki, and we can discuss/tune from there. (and yes, we need a link to this from the site) geir Konovalova, Svetlana wrote: I suggest just to provide just the definition and to add a link from the site to the corresponding wiki page. Cheers, Sveta -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] POLL : supported platforms yes, I mean the current definitions Then we could discuss the lists Thanks, Mikhail 2006/10/25, Stepan Mishura [EMAIL PROTECTED]: On 10/25/06, Mikhail Loenko wrote: does it make sense to put it on the site? To put what? The definition of supported platform or/and the list of supported platforms? I think it makes sense to put at least the definition. Thanks, Stepan. Thanks, Mikhail 2006/10/25, Stepan Mishura On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so supported is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define support as - one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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: [general] Announcing newest members of the Harmony PPMC
Congrats! -Mark. On 24 October 2006 at 18:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As progress towards our goal of having all committers on the PPMC, the Harmony PPMC is proud to announce it's newest members : Nathan Beyer Paulex Yang Weldon Washburn Please join us in congratulating them (and then tell them to get back to work...) :) The Harmony PPMC
Re: [drlvm] Class unloading support
Egor Pasko wrote: On the 0x20C day of Apache Harmony Aleksey Ignatenko wrote: Hello all! As you probably know current version of harmony DRLVM has no class unloading support. This leads to the fact that some Java applications accumulate memory leaks leading to memory overflow and crashes. In this message I would like to describe two approaches for class unloading in DRLVM and propose to implement one of them as basic. Pros and cons for both approaches are presented below. Lets name these approaches: 1. Mark and scan based approach. 2. Automatic class unloading approach. I am +1 to (2)=(Automatic class unloading approach). Do not like stop-the-world. But it has 1 more cons -- JIT should change it's devirtualizer accordingly to the VTable change. Doable, of course. BTW, is it reasonable to compress or enumerate references to j.l.Class in each object to reduce the footprint? How many classes are alive in heavy-duty applications? not very much probably. What is your sense of very much? IOW, how many would make you say, yeah, that's a lot geir
Re: [general] Announcing newest members of the Harmony PPMC
Well deserved congratulations. Tim On 24/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As progress towards our goal of having all committers on the PPMC, the Harmony PPMC is proud to announce it's newest members : Nathan Beyer Paulex Yang Weldon Washburn Please join us in congratulating them (and then tell them to get back to work...) :) The Harmony PPMC -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [snapshot] Questions about next snapshot...
3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin
Re: [snapshot] Questions about next snapshot...
As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? Also.. Martin... want to help? :) geir Oleg Khaschansky wrote: 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin
Re: [snapshot] Questions about next snapshot...
As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? Also.. Martin... want to help? :) geir Oleg Khaschansky wrote: 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin
[classlib][tests] Junit best practice
Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments in the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script that I'd thrown together one evening that would handle multi-line asserts but annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefully not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi
Re: Harmony passes 94% on derby tests.
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.
Re: [snapshot] Questions about next snapshot...
I can help testing, since I don't have the skills in C/C++. Usually, what I do on linux boxes is: 1.- Minimal O.S. install, text-only. Include XOrg shared libraries. No need to start any XOrg related service. 2.- Install my IBM JRE v1.4.2 3.- Start my java server process (servlet engine) with this system property: -Djava.awt.headless=true That's it, my servlet can generate graphics in PNG really fast, without a graphics environment. Regards, Martin On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? Also.. Martin... want to help? :) geir Oleg Khaschansky wrote: 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: [classlib][tests] Junit best practice
Cool - but why not just put into SVN somewhere? either in enhanced/tools or classlib/trunk somewhere where it can be invoked as an option by people from ant (so that we can wire it into the CI system...) geir Mark Hindess wrote: Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments in the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script that I'd thrown together one evening that would handle multi-line asserts but annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefully not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Excelent point. Performance data is quite needed to make this change. But how we can obtain it without a prototype? What about making experimental patch to measure performance of this optimization? We can safely drop it if it doesn't make sense. -- Ivan On 10/25/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Hello All, in general we do not have any objections to implement such functionality, but as far as I understand this will be quite unique TM feature (no other threading library have this, or give me a link) which is intended to improve performance. And if we going to extend TM interface for this, I would like to have any performance data beforehand, do we any data? Thank you. Nik. On 10/25/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: Xiao-Feng, I think there should be no problem to get this to work. But, I also agree with Mikhail that it could be benefitial to have data directly available in TLS without additional pointer dereference. If we will have corresponding interface function to allocate more then one void pointer at once in TLS it can be used as optimization. -- Ivan On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: On 10/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Why do we need multiple slots? Can't we use just one slot, which stores a pointer to a user data structure (the GC_Thread_Info in this case)? Yes you can store a pointer. But in this case you can't tell that you have constant offset from fs[14] to your data for all threads. So you can't inline your helper in JIT. Why? As long as we keep the offset_of_free to the pointer be constant and known to JIT helper, we only need an additional dereference to get the free value. We have two constant offsets, one is the pointer (to gc_tls_data) offset in fs[14], the other is the free offset in gc_tls_data. Thanks, xiaofeng -- Mikhail Fursov
Re: [snapshot] Questions about next snapshot...
Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? If so, we are just a step away for supporting headless? Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? Also.. Martin... want to help? :) geir Oleg Khaschansky wrote: 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: [snapshot] Questions about next snapshot...
Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? If so, we are just a step away for supporting headless? No. It is not so. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? If so, we are just a step away for supporting headless? Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? Also.. Martin... want to help? :) geir Oleg Khaschansky wrote: 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: Harmony passes 94% on derby tests.
On 25 October 2006 at 18:36, 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? I think gump will do this? PS. The directory structure may be something like that: builtest - trunk - cc - coverage - japi - application_test - derby - ant - etc - misc (some other scripts) I had assumed we'd make separate, optional cruisecontrol jobs to perform the coverage/japi/etc reporting. These jobs would depend on the build ant test jobs succeeding. Judging by the structure you suggest, it seems to me that you may anticipate doing it differently? Regards, Mark.
Re: [general] POLL : supported platforms
Morozova, Nadezhda wrote: My two cents... I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Do you think we can add a note with the revision number? This way, you at least know that the code of revision worked ok/failed on this platform. Because such tests are done systematically, changing revisions would not take much time to update. -1 I think this is a conceptually incorrect approach to try to keep a relatively slowly changing wiki page up-to-date with fast-paced commits. I believe this approach is doomed, and the status page is going to get out-of-date while it is being edited. I would suggest the following fix to the approach: * Reserve the supported platforms notion for the developer releases or snapshots, and do not use the term with respect to SVN trunk * Relate the list of supported platforms with the release management process, and describe the status of particular snapshots, and not SVN trunk in general.
Re: [classlib][tests] Junit best practice
Mark Hindess wrote: On 25 October 2006 at 7:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Cool - but why not just put into SVN somewhere? Okay. classlib/trunk/support/tools/bin perhaps? Sure. Whatever you feel is best. I have no strong opinion. We do have junit tests in DRLVM too, but we can reach over and use from there for now. geir -Mark. either in enhanced/tools or classlib/trunk somewhere where it can be invoked as an option by people from ant (so that we can wire it into the CI system...) geir Mark Hindess wrote: Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments in the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script that I'd thrown together one evening that would handle multi-line asserts but annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefully not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi
Re: [classlib][test] Configuration dependent test of InetAddress.getHostName
As I understand all of us vote to remove (comment) check which fails
concerned test. So I will prepare a patch.
2006/10/25, Andrew Zhang [EMAIL PROTECTED]:
On 10/24/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Andrew,
I agree that test should be fixed. I suggested using one of the
following checks to validate that the host is localhost.
InetAddress.getByName(host).isLoopbackAddress()
InetAddress.getByName(host).isSiteLocalAddress()
I have checked this on RI. Windows system reports true for
isLoopbackAddress and false for isSiteLocalAddress. Linux report is
completely opposite. Reading the spec doesn't help me much as well.
Do you have any ideas how the test should be revised? Should we use
these checks, or try something else?
Actually I don't have any idea too. I asked the same question before on
mailing list, bug got no solution. Therefore, I suggest simply comment this
test or comment the assert statement. yes, It's not good, but better than
build system failure on some platforms. :)
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 24, 2006 5:45 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][test] Configuration dependent test of
InetAddress.getHostName
On 10/20/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote:
Denis,
Can we consider a patch from
http://issues.apache.org/jira/browse/HARMONY-73 as a fourth option?
Simply speaking, the patch adds a conditional operator which forces
API
to returning localhost in this case.
No. I think Harmony does the right thing. We can't force harmony to
return
localhost, which should depend on host file.
The evil is the test. I think we'd better revise the test.
Paulex,
This is your patch. What do you think?
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 3:44 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][test] Configuration dependent test of
InetAddress.getHostName
I have researched issue H-1664 and found one more difference with
RI.
I run simple test on Windows Server 2003 SP1
=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;
public class Test {
public static void main(String[] args) throws
UnknownHostException
{
System.out.println(by name (127.0.0.1) - +
InetAddress.getByName(127.0.0.1).getHostName());
System.out.println(by name (localhost) - +
InetAddress.getByName(localhost).getHostName());
System.out.println(by address - +
InetAddress.getByAddress(new byte[]{127, 0, 0, 1}).getHostName());
System.out.println(localhost - +
InetAddress.getLocalHost());
}
}
Windows Server 2003 SP1
=== RI ==
by name (127.0.0.1) - 127.0.0.1
by name (localhost) - localhost
by address - 127.0.0.1
localhost - nstdrlew21/10.125.122.60
= Harmony ==
by name (127.0.0.1) - nstdrlew21.ins.intel.com
by name (localhost) - localhost
by address - nstdrlew21.ins.intel.com
localhost - nstdrlew21/10.125.122.60
WinXP
= Both ===
by name (127.0.0.1) - localhost
by name (localhost) - localhost
by address - localhost
localhost - pbwdmkishen/10.125.132.226
Actually Harmony use native call of getnameinfo() to get host name
(which is reasonable IMHO). MSDN says The getnameinfo function
provides name resolution from an address to the host name.
InetAddressTest.test_getHostName (see H-1664) failed on WinServer
because InetAddress.getByName(127.0.0.1).getHostName() returned
nstdrlew21.ins.intel.com while localhost expected. So this test
looks like configuration dependent.
I see three possible options
1. Stay test as is. Just keep in mind that on specific
configurations
this one fails.
2. Rewrite test to be configuration dependent. Test has to do the
same
native call.
3. Exclude localhost checking from test_getHostName.
What do you think about this situation?
--
Denis M. Kishenko
Enterprise Solutions Software 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,
Andrew Zhang
--
Best regards,
Andrew Zhang
--
Denis M. Kishenko
Intel Middleware Products Division
[classlib][awt] dependency cleanup and potential build breakage
Currently there is a quick hack in make/depends.xml because the awt dependencies have extensions that use a different convention for architecture names than the one used in the rest of classlib. I'm going to fix the README, build.xml files, and makefiles to use the standard harmony define for *platform* (rather than just architecture[0]) This means that your build might break. Renaming the libs (*.ia32 = *.linux.x86, *.ipf = *.linux.x86_64) should fix the problem. (Re-running fetch-depends should also fix it if you are using symlinks to system resources although it will leave a few unused symlinks behind.) I'm *not* going to fix the windows .lib file to use windows.x86 since this would involve creating a new tar in geir's people.apache.org web space to work smoothly. But we probably should do this at some point in the not to distant future. Any objections? Regards, Mark. [0] So we don't have to break it all again when we have macosx.x86 which wont work with the linux.x86 library file.
Re: Harmony passes 94% on derby tests.
Mark Hindess wrote: On 25 October 2006 at 18:36, 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? I think gump will do this? I'm sure it will, but given we have the infrastructure that we want people to run anyway, why not use it? PS. The directory structure may be something like that: builtest - trunk - cc - coverage - japi - application_test - derby - ant - etc - misc (some other scripts) I had assumed we'd make separate, optional cruisecontrol jobs to perform the coverage/japi/etc reporting. These jobs would depend on the build ant test jobs succeeding. I agree. Judging by the structure you suggest, it seems to me that you may anticipate doing it differently? Regards, Mark.
Re: [jira] No change notification from JIRA
infrastructure still isn't fully back up yet. Minotaur, the main user machine, didn't make the journey. Ivanov, Alexey A wrote: Hi to everybody, Does anybody know why JIRA stopped sending notifications of a change to issue reporter? Some time ago it didn't work as well. And before the infrastructure move on Monday, it worked fine. Now it doesn't again. Notifications for issues watched are sent as before. Thank you in advance, -- Alexey A. Ivanov Intel Middleware Product Division
Re: [classlib][awt] dependency cleanup and potential build breakage
Mark Hindess wrote: Currently there is a quick hack in make/depends.xml because the awt dependencies have extensions that use a different convention for architecture names than the one used in the rest of classlib. I'm going to fix the README, build.xml files, and makefiles to use the standard harmony define for *platform* (rather than just architecture[0]) This means that your build might break. Renaming the libs (*.ia32 = *.linux.x86, *.ipf = *.linux.x86_64) should fix the problem. (Re-running fetch-depends should also fix it if you are using symlinks to system resources although it will leave a few unused symlinks behind.) I'm *not* going to fix the windows .lib file to use windows.x86 since this would involve creating a new tar in geir's people.apache.org web space to work smoothly. But we probably should do this at some point in the not to distant future. Any objections? None, and once people.apache.org comes back from the dead, I'll post another tarball with a different name and different extensions, and you can integrate as you see fit. Regards, Mark. [0] So we don't have to break it all again when we have macosx.x86 which wont work with the linux.x86 library file. Oh, thank you, thank you, thank you, thank you geir
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Evgueni Brevnov wrote:
Hi Guys,
Just one little note from me... AFAIK Window and Linux have limitation
on the number of TLS slots which can be allocated for any particular
thread. I believe here is strong (probably performance) reasons for
doing so. It can be a problem to implement arbitrary size TLS which
seems to be required in case we want to allocate memory for keeping
whole structures in it.
Currently TM provides this service by using just *1* OS-level TLS slot.
The keys are allocated from a hythread_t structure:
thread/src/thread_private.h
166 typedef struct HyThread {
312 /**
313 * Array representing thread local storage
314 */
315 void *thread_local_storage[10];
So, it seems reasonable to use 3 of them for GC, 1 for VM and 1 for JIT.
RE: [jira] No change notification from JIRA
Geir, Thank you for your quick answer. Regards -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] No change notification from JIRA infrastructure still isn't fully back up yet. Minotaur, the main user machine, didn't make the journey. Ivanov, Alexey A wrote: Hi to everybody, Does anybody know why JIRA stopped sending notifications of a change to issue reporter? Some time ago it didn't work as well. And before the infrastructure move on Monday, it worked fine. Now it doesn't again. Notifications for issues watched are sent as before. Thank you in advance, -- Alexey A. Ivanov Intel Middleware Product Division
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
On 10/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Evgueni Brevnov wrote:
Hi Guys,
Just one little note from me... AFAIK Window and Linux have limitation
on the number of TLS slots which can be allocated for any particular
thread. I believe here is strong (probably performance) reasons for
doing so. It can be a problem to implement arbitrary size TLS which
seems to be required in case we want to allocate memory for keeping
whole structures in it.
Currently TM provides this service by using just *1* OS-level TLS slot.
The keys are allocated from a hythread_t structure:
thread/src/thread_private.h
166 typedef struct HyThread {
312 /**
313 * Array representing thread local storage
314 */
315 void *thread_local_storage[10];
So, it seems reasonable to use 3 of them for GC, 1 for VM and 1 for JIT.
GCv5 may have different demand for the TLS data, but IMHO some of
performance critical data can be made directly available in TLS and
some less signicant may be accessed indirectly.
--
Ivan
Intel Enterprise Solutions Software Division
Re: svn commit: r467552 - in /incubator/harmony/enhanced/drlvm/trunk/vm: tests/smoke/StackTest.java vmcore/src/util/ia32/base/compile_IA32.cpp vmcore/src/util/linux/signals_ia32.cpp vmcore/src/util/wi
Hello Weldon
I've noticed that along with changes from Rana's patch from HARMONY-1786
you've committed some changes compile_IA32.cpp. They don't seem to be
related to the patch, but rather a part of MMTK integration. Could it be
that you had some modifications to compile_IA32.cpp and accidently committed
them along with Rana's patch? Is it code safe to be committed in drlvm right
now?
2006/10/25, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Author: wjwashburn
Date: Tue Oct 24 20:55:30 2006
New Revision: 467552
URL: http://svn.apache.org/viewvc?view=revrev=467552
Log:
HARMONY-1786, a patch to fix Stack Overflow Error detection on Linux
smoke tests pass on both Linux and WindowsXP
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ia32/base/compile_IA32.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/linux/signals_ia32.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diffrev=467552r1=467551r2=467552
==
--- incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
(original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
Tue Oct 24 20:55:30 2006
@@ -15,10 +15,6 @@
* limitations under the License.
*/
-/*
- * $$$ GMJ
- * @keyword XXX_StackOverflowBroken
- */
public class StackTest {
static int depth = 0;
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ia32/base/compile_IA32.cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ia32/base/compile_IA32.cpp?view=diffrev=467552r1=467551r2=467552
==
---
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ia32/base/compile_IA32.cpp
(original)
+++
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/ia32/base/compile_IA32.cpp
Tue Oct 24 20:55:30 2006
@@ -1,4 +1,4 @@
-/*
+/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
@@ -88,6 +88,9 @@
unsigned cur_word = 0;
for(unsigned i=0; inum_args; i++) {
Type_Info_Handle tih = method_args_get_type_info(msh, i);
+bool is_magic = false; //wjw, MMTk support
+const String *str = tih-get_type_name();
+
switch (type_info_get_type(tih)) {
case VM_DATA_TYPE_INT64:
case VM_DATA_TYPE_UINT64:
@@ -110,6 +113,19 @@
break;
case VM_DATA_TYPE_CLASS:
case VM_DATA_TYPE_ARRAY:
+if (str) { //wjw MMTk support
+if (strncmp(str-bytes, org/vmmagic/unboxed/Address,
str-len) == 0 )
+ is_magic = true;
+if (strncmp(str-bytes,
org/vmmagic/unboxed/Extent, str-len) == 0 )
+ is_magic = true;
+if (strncmp(str-bytes,
org/vmmagic/unboxed/Offset, str-len) == 0 )
+ is_magic = true;
+if (strncmp(str-bytes,
org/vmmagic/unboxed/Word,str-len) == 0 )
+ is_magic = true;
+if (strncmp(str-bytes,
org/vmmagic/unboxed/ObjectReference,str-len) == 0 )
+ is_magic = true;
+}
+if (is_magic == false)
gc-add_object((ManagedObject**)get_arg_word(num_arg_words,
cur_word));
cur_word++;
break;
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/linux/signals_ia32.cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/linux/signals_ia32.cpp?view=diffrev=467552r1=467551r2=467552
==
---
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/linux/signals_ia32.cpp
(original)
+++
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/linux/signals_ia32.cpp
Tue Oct 24 20:55:30 2006
@@ -78,6 +78,8 @@
static int sc_nest = -1;
static uint32 exam_point;
+
+
void linux_ucontext_to_regs(Registers* regs, ucontext_t *uc)
{
regs-eax = uc-uc_mcontext.gregs[REG_EAX];
@@ -150,16 +152,13 @@
uint32 exception_esp = regs.esp;
DebugUtilsTI* ti = VM_Global_State::loader_env-TI;
-
exn_athrow_regs(regs, exc_clss);
-
assert(exception_esp = regs.esp);
if
(ti-get_global_capability(DebugUtilsTI::TI_GC_ENABLE_EXCEPTION_EVENT)) {
regs.esp = regs.esp - 4;
*((uint32*) regs.esp) = regs.eip;
regs.eip = ((uint32)asm_jvmti_exception_catch_callback);
}
-
Re: [classlib][luni] signalis interruptus in hysock
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might make
sense
to even print a stack trace. Also, I agree with Ivan below. Signals
bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself. Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig ourselves an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think
which
bothers me is following. EINTR can happen in different places and
the
situations can be quite rare in some circumstances. It can lead to
hard to reproduce stability bugs (race conditions).
Can you give an example?
Half a year ago, I was working on the problem. Socket operations get
sometimes interrupted. We have found out that it occurs sometime after
GC. It was not quite easy as the application was quite big and
situation - quite rare.
Given the fact, that current implementation of monitor reservation
code can stop other thread in quite random fashion we should have rock
solid support of EINTR handling everywhere the select(), poll() calls
is used.
--
Ivan
Intel Enterprise Solutions Software Division
We should find a
way how to test the implementation.
+1!
:)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
Re: [classlib][serialization] Conditional object replacement in ObjectInputStream - bug in RI?
Hi,
I have posted the patch for HARMONY-1920. I will be glad if some
committer take a look at it. I mean the more powerfull one than me :-/
I've also tried to resolve HARMONY-1921, but it seems a good luni
expertice is required for that. So it may be the good task for local
luni exprets floating around.
With best regards,
2006/10/20, Alexei Zakharov [EMAIL PROTECTED]:
Hi Mikhail,
I don't see any problems with the RI behavior here. The spec says
about the ObjectInputStream#resolveClass() method:
This method will be invoked only once for each unique class in the stream.
So your TestObjectInputStream#resolveClass() will be called only once.
And all serialized objects in the stream that have original type
a.TestClass will be deserialized to the type b.TestClass and it is the
correct behavior. This way, ClassCastException at line
try {
a.TestClass to4 = (a.TestClass) ois.readObject();
is expected since you are trying to cast the object of type
b.TestClass to incompatible type a.TestClass. Does it makes sense?
Thanks,
2006/10/19, Mikhail Markov [EMAIL PROTECTED]:
Hi!
I've recently filed 2 JIRAs (HARMONY-1920 and HARMONY 1921) related to the
object replacement in ObjectInputStream by means of resolveObject() method
and during experimenting with the tests, created the test which replaces the
object according to some rule (see the code at the bottom of the message).
Unexpectedly it fails on RI with the output:
TestObjectInputStream.resolveClass() is called.
1-st read passed.
2-nd read failed with exception: java.lang.ClassCastException: b.TestClass
This output indicates that RI performs caching for object replacements and
second read just did not call resolveClass() method from
TestObjectInputStream.
I did not find any info about this case in serialization specification
and not quite sure if this behaviour is correct. Is this a bug in RI?
If not then this case should be also taken into account while fixing
HARMONY-1921 JIRA.
- Test.java -
import java.io.*;
public class Test {
public static void main(String[] args) throws Exception {
a.TestClass to1 = new a.TestClass();
to1.i = 555;
a.TestClass to2 = new a.TestClass();
to2.i = 777;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(to1);
oos.writeObject(to2);
oos.flush();
byte[] bytes = baos.toByteArray();
ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
ObjectInputStream ois = new TestObjectInputStream(bais);
try {
b.TestClass to3 = (b.TestClass) ois.readObject();
if (to3.i != to1.i) {
System.out.println(1-st read failed. Expected: + to1.i +
, got: + to3.i);
} else {
System.out.println(1-st read passed.);
}
} catch (Exception ex) {
System.out.println(1-st read failed with exception: + ex);
}
try {
a.TestClass to4 = (a.TestClass) ois.readObject();
if (to4.i != to2.i) {
System.out.println(2-nd read failed. Expected: + to2.i +
, got: + to4.i);
} else {
System.out.println(2-nd read passed.);
}
} catch (Exception ex) {
System.out.println(2-nd read failed with exception: + ex);
}
}
static class TestObjectInputStream extends ObjectInputStream {
private boolean replaced = false;
public TestObjectInputStream(InputStream in) throws IOException {
super(in);
}
protected Class resolveClass(ObjectStreamClass desc)
throws IOException, ClassNotFoundException {
if (desc.getName().equals(a.TestClass)) {
System.out.println(TestObjectInputStream.resolveClass() is
called.);
if (!replaced) {
replaced = true;
return b.TestClass.class;
} else {
return a.TestClass.class;
}
}
return super.resolveClass(desc);
}
}
}
- a/TestClass.java -
package a;
import java.io.Serializable;
public class TestClass implements Serializable {
private static final long serialVersionUID = 1L;
public int i = 0;
}
- b/TestClass.java -
package b;
import java.io.Serializable;
public class TestClass implements Serializable {
private static final long serialVersionUID = 1L;
public int i = 0;
}
-
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division
[build][federation] building snapshots and releases
Currently, the federation build looks at the revision of the federation tree that you have checked out and checks out the same revision of the classlib and drlvm trees. Since we want releases to be reproducible (i.e. known tags of not only classlib and drlvm but also of the federation code that was used to combine them), then I think it make sense to use a similar mechanism when building from an svn tag. That is, if you check out the federation build from[0]: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/tags/1.0 then the federation build.xml should ensure that it also checks out the 1.0 tag of classlib and drlvm. That is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tags/1.0 and: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/drlvm/tags/1.0 This will need a little tweaking to the federation build.xml and I wanted to be sure this made sense before I started. What do people think? I've started on the source archive for snapshots (though it doesn't work yet[1]). My feeling is that although the federation build.xml in the svn checkout can be used to produce the binary archives - as it was used to produce the current snapshots - that in order to prove the source snapshot works (and to make sure that what we test/release is consistent) we should actually create the binary archives for a release from the source archive. That is, the process should be: 1) check out federation build using https://.../tags/1.0 2) ant bundle_src 3) unpack the resulting source archive (or perhaps just cd target/src) 4) build binary archives using contents of the source archive In short, make the binaries using the source archive that you are planning to release so that you know the source archive is really complete and works. Does this seem reasonable? Regards, Mark. [0] We don't have a tags directory yet and maybe we might make it under harmony/enchanced/federation rather than in harmony/enchanced but we can fix that later. [1] Currently: ant bundle_src; cd target/src; ant fails on check-depends but: ant bundle_src; cd target/src/working_classlib ; ant check-depends works. I can't see why yet. Perhaps someone will take a look? I can't see why it's any different from the svn tree.
Re: [classlib][awt] dependency cleanup and potential build breakage
On 25 October 2006 at 9:04, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Mark Hindess wrote: Currently there is a quick hack in make/depends.xml because the awt dependencies have extensions that use a different convention for architecture names than the one used in the rest of classlib. I'm going to fix the README, build.xml files, and makefiles to use the standard harmony define for *platform* (rather than just architecture[0]) This means that your build might break. Renaming the libs (*.ia32 = *.linux.x86, *.ipf = *.linux.x86_64) should fix the problem. (Re-running fetch-depends should also fix it if you are using symlinks to system resources although it will leave a few unused symlinks behind.) I'm *not* going to fix the windows .lib file to use windows.x86 since this would involve creating a new tar in geir's people.apache.org web space to work smoothly. But we probably should do this at some point in the not to distant future. Any objections? None, and once people.apache.org comes back from the dead, I'll post another tarball with a different name and different extensions, and you can integrate as you see fit. Excellent. Thanks Geir. I'll wait and commit the linux changes in the morning to give others a little time to comment before I break things. Regards, Mark.
Re: svn commit: r467634 - in /incubator/harmony/enhanced/classlib/trunk/doc: build.xml vminterface/natives.cfg
Thanks Paulex. I really should have remembered that when I committed
that the JIRA to move that code.
-Mark.
On 25 October 2006 at 13:21, [EMAIL PROTECTED] wrote:
Author: pyang
Date: Wed Oct 25 06:21:53 2006
New Revision: 467634
URL: http://svn.apache.org/viewvc?view=revrev=467634
Log:
Update the portlib document creation script to adapt the relayout that move p
ortlib out of luni
Modified:
incubator/harmony/enhanced/classlib/trunk/doc/build.xml
incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg
Modified: incubator/harmony/enhanced/classlib/trunk/doc/build.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
oc/build.xml?view=diffrev=467634r1=467633r2=467634
=
=
--- incubator/harmony/enhanced/classlib/trunk/doc/build.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/doc/build.xml Wed Oct 25 06:21:
53 2006
@@ -88,6 +88,7 @@
env key=HARMONY_DOC_DIR value=${basedir} /
env key=HARMONY_LUNI_NATIVES_DIR value=${basedir}/../modules
/luni/src/main/native /
env key=HARMONY_ARCHIVE_NATIVES_DIR value=${basedir}/../modu
les/archive/src/main/native /
+env key=HARMONY_PORTLIB_NATIVES_DIR value=${basedir}/../modu
les/portlib/src/main/native /
env key=HARMONY_TARGET_PLATFORM value=${target.platform} /
/exec
/target
Modified: incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.c
fg
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
oc/vminterface/natives.cfg?view=diffrev=467634r1=467633r2=467634
=
=
--- incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg (or
iginal)
+++ incubator/harmony/enhanced/classlib/trunk/doc/vminterface/natives.cfg Wed
Oct 25 06:21:53 2006
@@ -438,16 +438,18 @@
$(HARMONY_DOC_DIR)/vminterface \
$(HARMONY_LUNI_NATIVES_DIR)/vmi/$(HARMONY_TARGET_PLATFORM) \
$(HARMONY_LUNI_NATIVES_DIR)/luni/$(HARMONY_TARGET_PLATFORM) \
- $(HARMONY_LUNI_NATIVES_DIR)/pool/$(HARMONY_TARGET_PLATFORM) \
- $(HARMONY_LUNI_NATIVES_DIR)/port/$(HARMONY_TARGET_PLATFORM) \
- $(HARMONY_LUNI_NATIVES_DIR)/thread/$(HARMONY_TARGET_PLATFORM)
\
$(HARMONY_LUNI_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFORM)
\
+ $(HARMONY_PORTLIB_NATIVES_DIR)/pool/$(HARMONY_TARGET_PLATFORM)
\
+ $(HARMONY_PORTLIB_NATIVES_DIR)/port/$(HARMONY_TARGET_PLATFORM)
\
+ $(HARMONY_PORTLIB_NATIVES_DIR)/thread/$(HARMONY_TARGET_PLATFOR
M) \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFO
RM) \
$(HARMONY_LUNI_NATIVES_DIR)/vmi/shared \
$(HARMONY_LUNI_NATIVES_DIR)/luni/shared \
- $(HARMONY_LUNI_NATIVES_DIR)/pool/shared \
- $(HARMONY_LUNI_NATIVES_DIR)/port/shared \
- $(HARMONY_LUNI_NATIVES_DIR)/thread/shared \
$(HARMONY_LUNI_NATIVES_DIR)/include/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/pool/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/port/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/thread/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/include/shared \
$(HARMONY_ARCHIVE_NATIVES_DIR)/zip/$(HARMONY_TARGET_PLATFORM)
\
$(HARMONY_ARCHIVE_NATIVES_DIR)/archive/$(HARMONY_TARGET_PLATFO
RM) \
$(HARMONY_ARCHIVE_NATIVES_DIR)/zip/shared \
@@ -975,7 +977,9 @@
# contain include files that are not input files but should be processed by
# the preprocessor.
-INCLUDE_PATH = $(HARMONY_LUNI_NATIVES_DIR)/include/shared \
+INCLUDE_PATH = $(HARMONY_PORTLIB_NATIVES_DIR)/include/shared \
+ $(HARMONY_PORTLIB_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFO
RM) \
+ $(HARMONY_LUNI_NATIVES_DIR)/include/shared \
$(HARMONY_LUNI_NATIVES_DIR)/include/$(HARMONY_TARGET_PLATFORM)
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
Re: [classlib][luni] signalis interruptus in hysock
On 10/25/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And after every N loops, print a warning/diagnostic message.
For whom and to what end? Why not just return EINTR (in hysock speak)?
The
value for N would have to be tuned. I don't know what the best number
would
be. Given that 1904 patch is not the final solution, at least a
diagnostic
that hints at where the system hangs would be useful. It might make
sense
to even print a stack trace. Also, I agree with Ivan below. Signals
bugs
are very hard to debug. And diagnostics can help us all understand the
corner cases better.
But so far, no one has shown that the system hangs, or can hang, simply
because we return EINTR
Sorry for not being clear. I was reacting to the patch in 1904 itself. Not
the bigger issue of fixing the upper layers to comprehend EINTR. My
understanding is that this patch does not fix the problem. This patch does
not return EINTR. If for whatever reason this patch is committed, I
recommend adding the above diagnostic code so that we don't dig ourselves an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
I would prefer to close it as fixed when the correct solution will be found.
--
Ivan
Intel Enterprise Solutions Software Division
[classlib][security]Re: [jira] Created: (HARMONY-1963) [classlib][security] Harmony cannot read security policy file correctly
Any security guys can help to look at this issue? thanks in advance. I
haven't found time to looked closer to find the cause yet, but it seems
a little serious.
Paulex Yang (JIRA) wrote:
[classlib][security] Harmony cannot read security policy file correctly
---
Key: HARMONY-1963
URL: http://issues.apache.org/jira/browse/HARMONY-1963
Project: Harmony
Issue Type: Bug
Components: Classlib
Environment: Harmony classlib + IBM VME, windows XP+sp2
Reporter: Paulex Yang
I created simple a java.policy file[1], and try to run SecurityManagerTest with
argument:
-Djava.security.manager -Dtest.bin.dir=path to test bin directory
-Djava.security.policy=path to policy file
public class SecurityManagerTest {
public static void main(String[] args) throws Exception{
System.out.println(System.getProperty(os.name)); //read access for
this property has been granted by default policy
System.out.println(System.getProperty(notexist)); // no access for
this property has been granted by default policy
}
}
RI prints:
Windows XP
null
Harmony prints:
Windows XP
K0319java.security.AccessControlException: Access denied
(java.util.PropertyPermission notexist read)
at
java.security.AccessController.checkPermission(AccessController.java:94)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:739)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:374)
at java.lang.System.getProperty(System.java:675)
at java.lang.System.getProperty(System.java:660)
at SecurityManagerTest.main(Unknown Source)
I got same results if add the content customized java.policy to default policy
file without specifying policy file in cmd line.
[1]
grant codeBase file:${test.bin.dir}/- {
permission java.security.AllPermission;
};
--
Paulex Yang
China Software Development Lab
IBM
Re: [drlvm] Class unloading support
On 10/24/06, Aleksey Ignatenko [EMAIL PROTECTED] wrote: *Automatic class unloading approach.* Automatic class unloading means that j.l.Classloader instance is unloaded automatically (w/o additional enumeration tricks or GC dependency) and after we detect that some class loader was unloaded we destroy its native resources. To do that we need to provide two conditions: 1. Introduce reference from object to its j.l.Class instance. hmm... I think this means the object header size will increase by sizeof(reference_ptr). In addition to the cons listed below, the added ref ptr can cause cache pollution problems. From old studies adding a ref ptr to object header degraded overall performance about 3%. Maybe it makes sense to add a dummy slot in the existing object header layout to see what the footprint and speed impact will be on modern hardware. 2. Class registry - introduce references from j.l.Classes to its defining j.l.Classloader and references from j.l.Classloader to j.l.Classes loaded by it (unloading is to be done for j.l.Classloaderand corresponding j.l.Classes at once). *Introduce reference from object to its j.l.Class instance.* DRLVM has definite implementation specifics. Object is described with native VTable structure, which has pointers to class and other related data. VTables can have different sizes according to object class specifics. The main idea of referencing j.l.Class from object is to make VTable a special Java object with reference to appropriate j.l.Class instance, but give it a regular object view from GC point of view. VTable pointer is located in object by zero offset and therefore can be simply considered as reference field. Thus we can implement j.l.Class instance tracing from object via VTable object. VTable object is considered to be pinned for simplification. In summary, having class registry and reference from object to its j.l.Classinstance we guarantee that some class loader CL can be unloaded only if three conditions are fulfilled described above (*). To find out when Java part of class loader was unloaded j.l.Classloader instance should be enumerated as weak root. When this root becomes equal to null – destroy native memory of appropriate class loader. Pros: - Unification of unloading approach – no additional requirements from GC. - Stop-the-world is not required. - GC handles VTables automatically as regular objects. Cons - Number of objects to be increased. - Memory footprint to be increased both for native and Java heaps (as VTable objects appear). *Conclusion. * I prefer automatic class unloading approach due to the described set of properties (see above). It is more flexible and perspective solution. Also JVM specification is mostly related to automatic class unloading approach while mark and scan based approach looks more like class unloading workaround. Please, do not hesitate to ask questions. Best regards, Aleksey Ignatenko, Intel Enterprise Solutions Software Division. -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][tests] Junit best practice
Mark, I have just tried your tool. It's really helpful, thanks a lot! It's so pitty that script doesn't fix issues by itself =) 2006/10/25, Geir Magnusson Jr. [EMAIL PROTECTED]: Mark Hindess wrote: On 25 October 2006 at 7:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Cool - but why not just put into SVN somewhere? Okay. classlib/trunk/support/tools/bin perhaps? Sure. Whatever you feel is best. I have no strong opinion. We do have junit tests in DRLVM too, but we can reach over and use from there for now. geir -Mark. either in enhanced/tools or classlib/trunk somewhere where it can be invoked as an option by people from ant (so that we can wire it into the CI system...) geir Mark Hindess wrote: Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments in the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script that I'd thrown together one evening that would handle multi-line asserts but annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefully not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi -- Denis M. Kishenko Intel Middleware Products Division
Re: [drlvm] Class unloading support
Weldon, You sort of missed that in the proposal. Current (possibly compressed) vtable pointer at the offset 0 in the object layout will be replaced with (possibly compressed) ManagedObject*. VTable itself is going to become an object allocated in Java heap. So, no encrease in object size. Pavel. On 10/25/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 10/24/06, Aleksey Ignatenko [EMAIL PROTECTED] wrote: *Automatic class unloading approach.* Automatic class unloading means that j.l.Classloader instance is unloaded automatically (w/o additional enumeration tricks or GC dependency) and after we detect that some class loader was unloaded we destroy its native resources. To do that we need to provide two conditions: 1. Introduce reference from object to its j.l.Class instance. hmm... I think this means the object header size will increase by sizeof(reference_ptr). In addition to the cons listed below, the added ref ptr can cause cache pollution problems. From old studies adding a ref ptr to object header degraded overall performance about 3%. Maybe it makes sense to add a dummy slot in the existing object header layout to see what the footprint and speed impact will be on modern hardware. 2. Class registry - introduce references from j.l.Classes to its defining j.l.Classloader and references from j.l.Classloader to j.l.Classes loaded by it (unloading is to be done for j.l.Classloaderand corresponding j.l.Classes at once). *Introduce reference from object to its j.l.Class instance.* DRLVM has definite implementation specifics. Object is described with native VTable structure, which has pointers to class and other related data. VTables can have different sizes according to object class specifics. The main idea of referencing j.l.Class from object is to make VTable a special Java object with reference to appropriate j.l.Class instance, but give it a regular object view from GC point of view. VTable pointer is located in object by zero offset and therefore can be simply considered as reference field. Thus we can implement j.l.Class instance tracing from object via VTable object. VTable object is considered to be pinned for simplification. In summary, having class registry and reference from object to its j.l.Classinstance we guarantee that some class loader CL can be unloaded only if three conditions are fulfilled described above (*). To find out when Java part of class loader was unloaded j.l.Classloader instance should be enumerated as weak root. When this root becomes equal to null – destroy native memory of appropriate class loader. Pros: - Unification of unloading approach – no additional requirements from GC. - Stop-the-world is not required. - GC handles VTables automatically as regular objects. Cons - Number of objects to be increased. - Memory footprint to be increased both for native and Java heaps (as VTable objects appear). *Conclusion. * I prefer automatic class unloading approach due to the described set of properties (see above). It is more flexible and perspective solution. Also JVM specification is mostly related to automatic class unloading approach while mark and scan based approach looks more like class unloading workaround. Please, do not hesitate to ask questions. Best regards, Aleksey Ignatenko, Intel Enterprise Solutions Software Division. -- Weldon Washburn Intel Middleware Products Division -- Pavel Pervov, Intel Enterprise Solutions Software Division
[classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [drlvm] Class unloading support
And yes, there will be reference to corresponding java/lang/Class in VTable object. Which means that j/l/Class will be reachable from any object of this class. So, still no object size increase. :) Pavel. On 10/25/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 10/24/06, Aleksey Ignatenko [EMAIL PROTECTED] wrote: *Automatic class unloading approach.* Automatic class unloading means that j.l.Classloader instance is unloaded automatically (w/o additional enumeration tricks or GC dependency) and after we detect that some class loader was unloaded we destroy its native resources. To do that we need to provide two conditions: 1. Introduce reference from object to its j.l.Class instance. hmm... I think this means the object header size will increase by sizeof(reference_ptr). In addition to the cons listed below, the added ref ptr can cause cache pollution problems. From old studies adding a ref ptr to object header degraded overall performance about 3%. Maybe it makes sense to add a dummy slot in the existing object header layout to see what the footprint and speed impact will be on modern hardware. 2. Class registry - introduce references from j.l.Classes to its defining j.l.Classloader and references from j.l.Classloader to j.l.Classes loaded by it (unloading is to be done for j.l.Classloaderand corresponding j.l.Classes at once). *Introduce reference from object to its j.l.Class instance.* DRLVM has definite implementation specifics. Object is described with native VTable structure, which has pointers to class and other related data. VTables can have different sizes according to object class specifics. The main idea of referencing j.l.Class from object is to make VTable a special Java object with reference to appropriate j.l.Class instance, but give it a regular object view from GC point of view. VTable pointer is located in object by zero offset and therefore can be simply considered as reference field. Thus we can implement j.l.Class instance tracing from object via VTable object. VTable object is considered to be pinned for simplification. In summary, having class registry and reference from object to its j.l.Classinstance we guarantee that some class loader CL can be unloaded only if three conditions are fulfilled described above (*). To find out when Java part of class loader was unloaded j.l.Classloader instance should be enumerated as weak root. When this root becomes equal to null – destroy native memory of appropriate class loader. Pros: - Unification of unloading approach – no additional requirements from GC. - Stop-the-world is not required. - GC handles VTables automatically as regular objects. Cons - Number of objects to be increased. - Memory footprint to be increased both for native and Java heaps (as VTable objects appear). *Conclusion. * I prefer automatic class unloading approach due to the described set of properties (see above). It is more flexible and perspective solution. Also JVM specification is mostly related to automatic class unloading approach while mark and scan based approach looks more like class unloading workaround. Please, do not hesitate to ask questions. Best regards, Aleksey Ignatenko, Intel Enterprise Solutions Software Division. -- Weldon Washburn Intel Middleware Products Division -- Pavel Pervov, Intel Enterprise Solutions Software Division
Re: [general] Board resolution for Apache Harmony project
any comments? any at all? Geir Magnusson Jr. wrote: I've been anticipating this moment for 2 years now... :) While it doesn't seem possible given infrastructure issues that are interfering with mail to get something in front of the board tomorrow (plus the fact that the board likes things in advance) if a miracle happens I'd like to try, and if not, we need this anyway for next month, so we should get this put to bed (and back to work). Here's a proposed resolution to put before the board to create Apache Harmony as a Top Level Project (TLP) of the ASF. As per a discussion on the -private list, it's been suggested that I be offered as the candidate to the board as the PMC chair, so I filled in that blank, but that's open for discussion like everything else in this proposal. (The board chooses a chair - we just make the suggestion). There's no real rush to get this in tomorrow - as I said, it's really unlikely anyway - so please speak up with comments or concerns. - 0 - Establish the Apache Harmony project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software implementing Java virtual machines, related class libraries, and other software that is commonly associated with Java platforms, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Harmony PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Harmony PMC be and hereby is responsible for the creation and maintenance of software related to Java virtual machines, related class libraries, and other software commonly associated with Java platform implementations; and be it further RESOLVED, that the office of Vice President, Harmony be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Harmony PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Harmony PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Harmony PMC: * Nathan Beyer ([EMAIL PROTECTED]) * Tim Ellison([EMAIL PROTECTED]) * Mark Hindess ([EMAIL PROTECTED]) * George Harley ([EMAIL PROTECTED]) * Mikhail Loenko ([EMAIL PROTECTED]) * Geir Magnusson Jr. ([EMAIL PROTECTED]) * Stepan Mishura ([EMAIL PROTECTED]) * Weldon Washburn([EMAIL PROTECTED]) * Paulex Yang([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Geir Magnusson Jr be appointed to the office of Vice President, Harmony, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Harmony PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Harmony Project; and be it further RESOLVED, that the initial Harmony PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator Harmony podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Harmony podling encumbered upon the Apache Incubator PMC are hereafter discharged. - 0 - Comments please? geir
Re: [general] POLL : supported platforms
I agree with Salikh -- the wiki will never keep up if you expect such frequent manual updates. That's a job for the test results' collator. Regards, Tim Salikh Zakirov wrote: Morozova, Nadezhda wrote: My two cents... I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Do you think we can add a note with the revision number? This way, you at least know that the code of revision worked ok/failed on this platform. Because such tests are done systematically, changing revisions would not take much time to update. -1 I think this is a conceptually incorrect approach to try to keep a relatively slowly changing wiki page up-to-date with fast-paced commits. I believe this approach is doomed, and the status page is going to get out-of-date while it is being edited. I would suggest the following fix to the approach: * Reserve the supported platforms notion for the developer releases or snapshots, and do not use the term with respect to SVN trunk * Relate the list of supported platforms with the release management process, and describe the status of particular snapshots, and not SVN trunk in general. -- Tim Ellison ([EMAIL PROTECTED])
Re: [classlib][tests] Junit best practice
On 25 October 2006 at 18:38, Denis Kishenko [EMAIL PROTECTED] wrote: Mark, I have just tried your tool. It's really helpful, thanks a lot! It's so pitty that script doesn't fix issues by itself =) It could (and I have been known to use scripts to fix things) but as Nathan recently pointed out. It's not always a good idea. Specifically, my tool is not perfect at identifying the different types of assertEquals calls (e.g. the variants for double where the last argument might look like a constant but isn't the expected value but a delta). It does a reasonable job but without implementing a full parser it's never going to be 100% reliable. I did use a script - a one-off on the command line - to fix a significant number of assertEquals calls to use assertTrue/assertFalse/assertNull a week or so ago, but I did also scan the diff to see if it looked sane. Scanning the diff was almost as tedious as fixing them manually. ;-( Regards, Mark. 2006/10/25, Geir Magnusson Jr. [EMAIL PROTECTED]: Mark Hindess wrote: On 25 October 2006 at 7:41, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Cool - but why not just put into SVN somewhere? Okay. classlib/trunk/support/tools/bin perhaps? Sure. Whatever you feel is best. I have no strong opinion. We do have junit tests in DRLVM too, but we can reach over and use from there for now. geir -Mark. either in enhanced/tools or classlib/trunk somewhere where it can be invoked as an option by people from ant (so that we can wire it into the CI system...) geir Mark Hindess wrote: Earlier in the year we discussed junit best practice. For example, making sure assertEquals calls have the expected and actual arguments i n the correct order to avoid getting confusing failure messages. Robert posted a script a week or so ago, to look for some of junit issues but it didn't handle asserts that spanned multiple lines so, unfortunately, it was missing the majority of them. I had a script tha t I'd thrown together one evening that would handle multi-line asserts bu t annoyingly (because it read the whole file at once) couldn't report the line number of the potential issue as Robert's script did. Inspired by Robert's post, I looked at my script again. I've now fixed it to report line numbers, added a little bit of documentation and attached it to a JIRA: https://issues.apache.org/jira/browse/HARMONY-1960 It finds quite a lot of potential problems (I've appended a summary of the findings below). (There will be a few false positives but hopefull y not too many.) It would be nice to fix these issues - I fixed several hundred while testing the script - but more importantly we should make sure we avoid adding any new issues. Improvements to the script would be most welcome. Regards, Mark. Types of issue identified 4949 should possibly use assertEquals 815 actual may be a constant 437 consider using separate asserts for each '' component 330 exception may be left to junit 135 actual *may* be a constant 48 should be fail (always false) 40 should be fail (always true) 20 expected is null - should use assertNull 12 consider using separate asserts for each '||' component 8 expected is false - should use assertFalse 7 expected is true - should use assertTrue 1 should use assertNotNull Number of Issues by module 1907 luni 1440 swing 699 math 611 security 335 text 322 awt 222 sound 186 nio 178 jndi 123 archive 118 auth 117 crypto 116 logging 91 nio_char 87 print 74 regex 68 concurrent 45 beans 41 x-net 21 sql 1 rmi -- Denis M. Kishenko Intel Middleware Products Division
Re: [build][federation] building snapshots and releases
Mark Hindess wrote: Currently, the federation build looks at the revision of the federation tree that you have checked out and checks out the same revision of the classlib and drlvm trees. That was just for convenience if you don't care. It doesn't work all that well in practice, because you want to do the same SVN rev on multiple platforms, so I tend to formally specify it on the command line : $ ant -Dsvn.revision=X Since we want releases to be reproducible (i.e. known tags of not only classlib and drlvm but also of the federation code that was used to combine them), then I think it make sense to use a similar mechanism when building from an svn tag. That is, if you check out the federation build from[0]: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/tags/1.0 then the federation build.xml should ensure that it also checks out the 1.0 tag of classlib and drlvm. That is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tags/1.0 and: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/drlvm/tags/1.0 This will need a little tweaking to the federation build.xml and I wanted to be sure this made sense before I started. What do people think? Well... certainly I think we'll need it at some point in the future, because it's clear we won't have the luxury of having the VM and classlib right in the same svn revision number. This also will be true when there are VM options, so you'll take VM_1234 and CLASSLIB_1292 and JAVATOOLS_1.2.3 (whatever those numbers mean), and combine into a JDK and test that with the TCK. First, do no harm. Make it a choice. The current snapshot mechanism is lightweight, and I do find the lack of tags and branches in SVN as first class citizens to be a royal PITA. So maybe I can either do : $ant -Dsvn.revision=X for a simple snapshot build or $ant -Dclasslib.tag=X -Ddrlvm.tag=Y -Djavatools.tag=Z ? I've started on the source archive for snapshots (though it doesn't work yet[1]). My feeling is that although the federation build.xml in the svn checkout can be used to produce the binary archives - as it was used to produce the current snapshots - that in order to prove the source snapshot works (and to make sure that what we test/release is consistent) we should actually create the binary archives for a release from the source archive. That is, the process should be: 1) check out federation build using https://.../tags/1.0 2) ant bundle_src 3) unpack the resulting source archive (or perhaps just cd target/src) 4) build binary archives using contents of the source archive Lets clarify. The federation tree is really just a build.xml file, and for convenience, there is LICENSE, NOTICE, etc, but that's a maintenance problem given we have info in multiple places. So lets assume we fix that, and the federation is just the build.xml Suppose we did this : $ant -Dfed.version=W -Dsvn.revision=X or $ant -Dfed.version=W -Dclasslib.tag=X -Ddrlvm.tag=Y -Djavatools.tag=Z leads to : 1) create directory under /trunk snapshot-W-rX or dist-W-X-Y-Z 2) checkout into that directory the build.xml rW 3) cd into that directory 4) run ant target to populate the source 5) (not sure?) Run the fetch targets to populate the deps 6) tar that directory to make the source tarball 7) run the build target It seems like the only issue is that we need to stable down the version of federation tree too (which is the build script) In short, make the binaries using the source archive that you are planning to release so that you know the source archive is really complete and works. Does the sequence above satisfy your requirements? Does this seem reasonable? Regards, Mark. [0] We don't have a tags directory yet and maybe we might make it under harmony/enchanced/federation rather than in harmony/enchanced but we can fix that later. this is an orthogonal thread. We need to think about this carefully. One idea that leaps to mind is harmony/enhanced/branches_and_tags/ with some structure under there and tagging convention. geir
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [general] Board resolution for Apache Harmony project
On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: any comments? any at all? Geir, Sorry about my confusion. Is this synonymous with or a part of the process of applying to Apache to graduate us from incubator status? Thanks, Rana
Re: [general] Board resolution for Apache Harmony project
I see, thanks. The TLP proposal looks good to me. Rana On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Rana Dasgupta wrote: On 10/25/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: any comments? any at all? Geir, Sorry about my confusion. Is this synonymous with or a part of the process of applying to Apache to graduate us from incubator status? This is the text of the resolution that we would present to the board to formally make us a TLP once the Incubator PMC votes to release us from incubation (on the condition the board makes us a TLP.) The vote on [EMAIL PROTECTED] is for the Incubator PMC to vote to release us from incubation on the condition that the board makes us a TLP (on the condition that the incubator releases us from incubation, on the condition that the board) The language is the formal language in which the board issues resolutions. geir
[drlvm][test]Exclude some tests from build test target, make 'build test' pass
Geir Some tests launched by command build test fail. The idea of build test is to run it before each commit. In this way you can catch regressions. In order to effectively catch regressions, i.e. tests that started to fail after some change, it's necessary to have 'build test' pass in a stable way. One of the ways to achieve stable state is to exclude failing tests or tests which show unstable behavior. So I analysed statistics of test runs on win ia32 platform and made up a list of tests to be excluded: 1) smoke *** gc.LOS fails always on jitrino and interpreter, debug and release 2) kernel *** java.lang.ClasssGenericsTest and *** java.lang.ClassGenericsTest4 fail because of timeout, so I increase timeout in kernel.test.xml *** java.lang.ObjectTest fail on interpreter with following message: Testsuite: java.lang.ObjectTest Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec Testcase: testWait1(java.lang.ObjectTest): FAILED An InterruptedException must be thrown in test thread! junit.framework.AssertionFailedError: An InterruptedException must be thrown in test thread! See HARNONY-1966 issue with attached patch. Vera Volynets Intel Middleware Products Division
RE: [general] POLL : supported platforms
Ok, thanks all, I see now. Can I suggest that we define the supported platforms (the term itself + the list of currently supported combinations) on the site. We can also keep a Wiki page for related issues. The platform support info could go to the download-snapshots page. Thank you, Nadya Morozova -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 7:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] POLL : supported platforms I agree with Salikh -- the wiki will never keep up if you expect such frequent manual updates. That's a job for the test results' collator. Regards, Tim Salikh Zakirov wrote: Morozova, Nadezhda wrote: My two cents... I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? IMHO if the next commit breakes the work-ok-platform and if you notice it, why not to update the wiki page? Or you can let me know about this bug and I'll make the update:) Do you think we can add a note with the revision number? This way, you at least know that the code of revision worked ok/failed on this platform. Because such tests are done systematically, changing revisions would not take much time to update. -1 I think this is a conceptually incorrect approach to try to keep a relatively slowly changing wiki page up-to-date with fast-paced commits. I believe this approach is doomed, and the status page is going to get out-of-date while it is being edited. I would suggest the following fix to the approach: * Reserve the supported platforms notion for the developer releases or snapshots, and do not use the term with respect to SVN trunk * Relate the list of supported platforms with the release management process, and describe the status of particular snapshots, and not SVN trunk in general. -- Tim Ellison ([EMAIL PROTECTED])
Re: [drlvm][test]Exclude some tests from build test target, make 'build test' pass
The ideal way would be for acceptance tests like build test to always pass and to catch and roll back the patch that breaks this invariant, rather than to disable the tests. But I agree with Vera, it is important to keep a running set up as acceptance tests, so disabling the well known failures may be the only way until we fix the problems. I don't know that any of the tests are unstable. These are implementation bugs. gc.LOS is a bug in thread yielding by the apr Windows functionality. The java.lang.ObjectTest also looks like an interpreter implementation error. On 10/25/06, Volynets, Vera [EMAIL PROTECTED] wrote: Geir Some tests launched by command build test fail. The idea of build test is to run it before each commit. In this way you can catch regressions. In order to effectively catch regressions, i.e. tests that started to fail after some change, it's necessary to have 'build test' pass in a stable way. One of the ways to achieve stable state is to exclude failing tests or tests which show unstable behavior. So I analysed statistics of test runs on win ia32 platform and made up a list of tests to be excluded: 1) smoke *** gc.LOS fails always on jitrino and interpreter, debug and release 2) kernel *** java.lang.ClasssGenericsTest and *** java.lang.ClassGenericsTest4 fail because of timeout, so I increase timeout in kernel.test.xml *** java.lang.ObjectTest fail on interpreter with following message: Testsuite: java.lang.ObjectTest Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec Testcase: testWait1(java.lang.ObjectTest): FAILED An InterruptedException must be thrown in test thread! junit.framework.AssertionFailedError: An InterruptedException must be thrown in test thread! See HARNONY-1966 issue with attached patch. Vera Volynets Intel Middleware ProductsDivision
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
If you mean libxlib, how it could be used without X server? Maybe some other library (e.g. font library like xft) simply preloads it during its initialization or tries to connect to the server (XOpenDisplay) to get some data, fails and uses defaults? Anyway, I think, testing on a headless environment will help us to determine the requirements. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: (e.g. for linux we need to exclude all xlib calls, right?). How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Regards, Martin Cordova On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
I don't know how it works, but what I can do is try to use headless without XOrg shared libs installed, and then take note of the missing .so modules the IBM JVM complains about). Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: If you mean libxlib, how it could be used without X server? Maybe some other library (e.g. font library like xft) simply preloads it during its initialization or tries to connect to the server (XOpenDisplay) to get some data, fails and uses defaults? Anyway, I think, testing on a headless environment will help us to determine the requirements. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: (e.g. for linux we need to exclude all xlib calls, right?). How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Regards, Martin Cordova On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
Could it be treated as a reverse engineering? I don't know :) On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: I don't know how it works, but what I can do is try to use headless without XOrg shared libs installed, and then take note of the missing .so modules the IBM JVM complains about). Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: If you mean libxlib, how it could be used without X server? Maybe some other library (e.g. font library like xft) simply preloads it during its initialization or tries to connect to the server (XOpenDisplay) to get some data, fails and uses defaults? Anyway, I think, testing on a headless environment will help us to determine the requirements. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: (e.g. for linux we need to exclude all xlib calls, right?). How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Regards, Martin Cordova On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
