Re: [drlvm][thread] stacksize
Hi Pierre, 1) The stack size you see is most probably a main thread stack size, obtained once the global instance of "port shared data" object is created, while attaching main thread to the port threading system. You cannot change main thread stack size via Xss, it's set up in compile time I believe. To get size of all managed threads created by the VM, you can examine results returned by the call to find_stack_addr_size() in init_stack() function (vm/port/src/thread/linux/thread_os.c:395). 2) The meaning of the test is to check if our current stack position (obtained through getting an address of local variable) with a fixed spare space (mem_protect_size) overlaps with an area which is to be protected by set_guard_page() later in this function. If they do overlap, then we have way too small stack to work properly, even less than 0x400 (0x100 on 32-bit) bytes between current stack and special area supposed for catching stack overflow. Thanks, Ilya. On Thu, Apr 21, 2011 at 1:45 PM, Alexei Fedotov wrote: > Pierre, > > Please try the following searches: > > The parameter is set: > http://www.google.com/codesearch?q="thread.stacksize"&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F<http://www.google.com/codesearch?q=%22thread.stacksize%22&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F> > > The thread is created: > http://www.google.com/codesearch?lr=&q="port_thread_create"&sbtn=Поиск&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F<http://www.google.com/codesearch?lr=&q=%22port_thread_create%22&sbtn=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F> > > Maybe if you add more debugging there, this will help. > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > > On Fri, Apr 22, 2011 at 12:13 AM, Pierre Queinnec < > [email protected]> wrote: > >> Hi guys, >> >> I'm seeing some strange thread stack size behavior while porting to Mac, >> and I've been trying to compare to a build on a 64bit linux (Debian 6). >> >> Here's what I see on Linux, whatever I can define for my Xss, the stack >> size in init_psd_structure always calculates 8M : >> >> == >> queinnec@squeezy:~/Code/harmony-svn-java6/target/hdk/jdk$ ./bin/java >> -Xmx1024m -Xss12m -version >> init_psd_structure: stack_size = 8388608 >> init_psd_structure: guard_size = 4096 >> init_psd_structure: mem_protect_size = 1024 >> PMQ - setup_stack - (&res - mem_protect_size) = 140736255271036 >> PMQ - setup_stack - (guard_page_addr + guard_page_size = 140736246960128 >> PMQ - setup_stack - (&res - mem_protect_size) = 140715543796204 >> PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715541778432 >> PMQ - setup_stack - (&res - mem_protect_size) = 140715528108524 >> PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715515604992 >> PMQ - setup_stack - (&res - mem_protect_size) = 140715515521516 >> PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715513503744 >> PMQ - setup_stack - (&res - mem_protect_size) = 140715513420268 >> PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715511402496 >> Apache Harmony Launcher : (c) Copyright 1991, 2010 The Apache Software >> Foundation or its licensors, as applicable. >> java version "1.5.0" >> Apache Harmony (1.5.0) >> DRLVM (1.5.0-r1092753) >> pre-alpha : not complete or compatible >> svn = r1092753, (Apr 15 2011), Linux/em64t/gcc 4.4.5, release build >> http://harmony.apache.org >> == >> >> (patch attached, maybe I just missed something obvious... I've seen some >> maybe related JIRA but they were supposed to be closed) >> >> As a second question, in drlvm/vm/port/src/thread/linux/thread_os.c there's >> this test : >> >> if ((size_t)(&res) - PSD->mem_protect_size >> < (size_t)tlsdata->guard_page_addr + tlsdata->guard_page_size) >> return EINVAL; >> >> I'm not sure I get this... Anyone care to explain? >> >> As a side note, the port seems to start fine but crashes after starting >> some threads. >> Cheers, >> -- Pierre Queinnec >> >> >> >> >> >> >
Re: [drlvm][thread] stacksize
Pierre, Please try the following searches: The parameter is set: http://www.google.com/codesearch?q="thread.stacksize"&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F<http://www.google.com/codesearch?q=%22thread.stacksize%22&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F> The thread is created: http://www.google.com/codesearch?lr=&q="port_thread_create"&sbtn=Поиск&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F<http://www.google.com/codesearch?lr=&q=%22port_thread_create%22&sbtn=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&exact_package=http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fharmony%2Fenhanced%2F> Maybe if you add more debugging there, this will help. -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Fri, Apr 22, 2011 at 12:13 AM, Pierre Queinnec < [email protected]> wrote: > Hi guys, > > I'm seeing some strange thread stack size behavior while porting to Mac, > and I've been trying to compare to a build on a 64bit linux (Debian 6). > > Here's what I see on Linux, whatever I can define for my Xss, the stack > size in init_psd_structure always calculates 8M : > > == > queinnec@squeezy:~/Code/harmony-svn-java6/target/hdk/jdk$ ./bin/java > -Xmx1024m -Xss12m -version > init_psd_structure: stack_size = 8388608 > init_psd_structure: guard_size = 4096 > init_psd_structure: mem_protect_size = 1024 > PMQ - setup_stack - (&res - mem_protect_size) = 140736255271036 > PMQ - setup_stack - (guard_page_addr + guard_page_size = 140736246960128 > PMQ - setup_stack - (&res - mem_protect_size) = 140715543796204 > PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715541778432 > PMQ - setup_stack - (&res - mem_protect_size) = 140715528108524 > PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715515604992 > PMQ - setup_stack - (&res - mem_protect_size) = 140715515521516 > PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715513503744 > PMQ - setup_stack - (&res - mem_protect_size) = 140715513420268 > PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715511402496 > Apache Harmony Launcher : (c) Copyright 1991, 2010 The Apache Software > Foundation or its licensors, as applicable. > java version "1.5.0" > Apache Harmony (1.5.0) > DRLVM (1.5.0-r1092753) > pre-alpha : not complete or compatible > svn = r1092753, (Apr 15 2011), Linux/em64t/gcc 4.4.5, release build > http://harmony.apache.org > == > > (patch attached, maybe I just missed something obvious... I've seen some > maybe related JIRA but they were supposed to be closed) > > As a second question, in drlvm/vm/port/src/thread/linux/thread_os.c there's > this test : > > if ((size_t)(&res) - PSD->mem_protect_size > < (size_t)tlsdata->guard_page_addr + tlsdata->guard_page_size) > return EINVAL; > > I'm not sure I get this... Anyone care to explain? > > As a side note, the port seems to start fine but crashes after starting > some threads. > Cheers, > -- Pierre Queinnec > > > > > >
[drlvm][thread] stacksize
Hi guys,I'm seeing some strange thread stack size behavior while porting to Mac, and I've been trying to compare to a build on a 64bit linux (Debian 6).Here's what I see on Linux, whatever I can define for my Xss, the stack size in init_psd_structure always calculates 8M :==queinnec@squeezy:~/Code/harmony-svn-java6/target/hdk/jdk$ ./bin/java -Xmx1024m -Xss12m -versioninit_psd_structure: stack_size = 8388608init_psd_structure: guard_size = 4096init_psd_structure: mem_protect_size = 1024PMQ - setup_stack - (&res - mem_protect_size) = 140736255271036PMQ - setup_stack - (guard_page_addr + guard_page_size = 140736246960128PMQ - setup_stack - (&res - mem_protect_size) = 140715543796204PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715541778432PMQ - setup_stack - (&res - mem_protect_size) = 140715528108524PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715515604992PMQ - setup_stack - (&res - mem_protect_size) = 140715515521516PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715513503744PMQ - setup_stack - (&res - mem_protect_size) = 140715513420268PMQ - setup_stack - (guard_page_addr + guard_page_size = 140715511402496Apache Harmony Launcher : (c) Copyright 1991, 2010 The Apache Software Foundation or its licensors, as applicable.java version "1.5.0"Apache Harmony (1.5.0)DRLVM (1.5.0-r1092753)pre-alpha : not complete or compatiblesvn = r1092753, (Apr 15 2011), Linux/em64t/gcc 4.4.5, release buildhttp://harmony.apache.org==(patch attached, maybe I just missed something obvious... I've seen some maybe related JIRA but they were supposed to be closed)As a second question, in drlvm/vm/port/src/thread/linux/thread_os.c there's this test : if ((size_t)(&res) - PSD->mem_protect_size < (size_t)tlsdata->guard_page_addr + tlsdata->guard_page_size) return EINVAL;I'm not sure I get this... Anyone care to explain?As a side note, the port seems to start fine but crashes after starting some threads.Cheers,-- Pierre Queinnec drlvm-stacksize-printf.diff Description: Binary data
Re: Dalvik bytecode version of Harmony's DRLVM feasible as the new JVM?
Hello Paul, Dalvik VM is APL licensed and runs on x86_64. What is the point to compete? As years ago I still see an option for DRLVM to serve as a source of high quality portable modules (e.g. GC, asm utils, logging, crash handler) reusable by several VM implementations (e.g. Dalvik, QEMU, Parrot, etc) available as linux packages. Today you are reading this. Tomorrow you are known as the author of the DRLVM-based IR management module which has just replaced GIMPLE in gcc trunk. Your way to the glory of zlib is simple - just work on accepting your module into as many open source projects, as you can, and it inevitably becomes brilliant and widely used. We may also create JVM benchmarks and certification testsuites from our exisitng testbase with common ASF "field of use" restriction: those who tricked ASF with licenses cannot publish results and never get certified. -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Thu, Nov 11, 2010 at 6:33 AM, Paul Anderson wrote: > In view of the current problem with the TCK and software patents, > here's an idea - excuse me if it's come up before or if it's totally > wacky. > > The Dalvik VM was written for phones and similar small devices. For > servers and desktops, how about making an implementation of the > DRLVM that runs Dalvik bytecode? > The Apache name and ethos has great credibility, and a good > patent-unencumbered VM is desperately needed as an > Apache-webserver-like de-facto standard. > For various VM languages, the Android technique of compiling them or > their interpreters into Java bytecode then transforming to .dex > could be used in the interim as is already done on Android, followed > later by native compilation into Dalvik bytecode - so JRuby, JPython > etc could be adapted quickly to work directly on such a VM, and with > a bit more effort, even languages that dynamically generate and load > bytecode. > > For the Java language itself, Dalvik-ized Java platform classes > taken from Harmony could be a separate project with an open TCK > corresponding to Java 5 and 6, and a Java-to-dex compiler added > later. > > Could it be done? And should it? Maybe James Gosling could advise, > since he is free! > > >
Dalvik bytecode version of Harmony's DRLVM feasible as the new JVM?
In view of the current problem with the TCK and software patents, here's an idea - excuse me if it's come up before or if it's totally wacky. The Dalvik VM was written for phones and similar small devices. For servers and desktops, how about making an implementation of the DRLVM that runs Dalvik bytecode? The Apache name and ethos has great credibility, and a good patent-unencumbered VM is desperately needed as an Apache-webserver-like de-facto standard. For various VM languages, the Android technique of compiling them or their interpreters into Java bytecode then transforming to .dex could be used in the interim as is already done on Android, followed later by native compilation into Dalvik bytecode - so JRuby, JPython etc could be adapted quickly to work directly on such a VM, and with a bit more effort, even languages that dynamically generate and load bytecode. For the Java language itself, Dalvik-ized Java platform classes taken from Harmony could be a separate project with an open TCK corresponding to Java 5 and 6, and a Java-to-dex compiler added later. Could it be done? And should it? Maybe James Gosling could advise, since he is free!
Re: svn commit: r1002734 - in /harmony/enhanced/java/branches/java6: ./ classlib/ classlib/depends/libs/ classlib/modules/beans/src/main/java/java/beans/ drlvm/ jdktools/
On 2010-9-30 1:00, [email protected] wrote: Author: hindessm Date: Wed Sep 29 17:00:09 2010 New Revision: 1002734 URL: http://svn.apache.org/viewvc?rev=1002734&view=rev Log: Merge change from tr...@1002511: r1002511 | zhoukevin | 2010-09-29 09:10:27 +0100 (Wed, 29 Sep 2010) | 1 line Apply the patch for HARMONY-6664: Poor performance of java.beans.XMLEncoder.writeObject() method. This reduce the time of writing a list of 25000 integers from 30 seconds to 3 seconds, improve the performance of XMLEncoder.writeObject() to some extent. Removed: harmony/enhanced/java/branches/java6/classlib/modules/beans/src/main/java/java/beans/ReferenceMap.java Modified: harmony/enhanced/java/branches/java6/ (props changed) harmony/enhanced/java/branches/java6/classlib/ (props changed) harmony/enhanced/java/branches/java6/classlib/depends/libs/ (props changed) harmony/enhanced/java/branches/java6/classlib/modules/beans/src/main/java/java/beans/DefaultPersistenceDelegate.java harmony/enhanced/java/branches/java6/classlib/modules/beans/src/main/java/java/beans/Encoder.java harmony/enhanced/java/branches/java6/classlib/modules/beans/src/main/java/java/beans/PersistenceDelegate.java harmony/enhanced/java/branches/java6/classlib/modules/beans/src/main/java/java/beans/XMLEncoder.java harmony/enhanced/java/branches/java6/drlvm/ (props changed) harmony/enhanced/java/branches/java6/jdktools/ (props changed) Propchange: harmony/enhanced/java/branches/java6/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Sep 29 17:00:09 2010 @@ -1,4 +1,4 @@ /harmony/enhanced/java/branches/mrh:935751-941490 -/harmony/enhanced/java/trunk:929253-997624,997759,997980,997986,998010,998030,998619,998628,998759,998804,998822,999260,999286,999306,999591,999601,999623,999715-999716,999724,999793,105,1000169,1000213,1000229,1000231,1000233,1000240,1000245,1000248,1000265,1000527,1000689,1000696,1000699-1000700,1000705,1000708,1001065,1001080,1001153,1001187,1001490,1001609,1001638,1001652,1001723,1001741,1001744-1001745,1001751,1002080,1002189,1002476,1002480,1002488,1002506 +/harmony/enhanced/java/trunk:929253-997624,997759,997980,997986,998010,998030,998619,998628,998759,998804,998822,999260,999286,999306,999591,999601,999623,999715-999716,999724,999793,105,1000169,1000213,1000229,1000231,1000233,1000240,1000245,1000248,1000265,1000527,1000689,1000696,1000699-1000700,1000705,1000708,1001065,1001080,1001153,1001187,1001490,1001609,1001638,1001652,1001723,1001741,1001744-1001745,1001751,1002080,1002189,1002476,1002480,1002488,1002506,1002511 /harmony/enhanced/trunk:476395-929252 /incubator/harmony/enhanced/trunk:292550-476394 Propchange: harmony/enhanced/java/branches/java6/classlib/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Sep 29 17:00:09 2010 @@ -1,7 +1,7 @@ /harmony/enhanced/classlib/trunk:713674-735919,765923-926091,926318-926838 /harmony/enhanced/classlib/trunk/working_classlib:884014-884286 /harmony/enhanced/java/branches/mrh/classlib:935751-941490 -/harmony/enhanced/java/trunk/classlib:929253-997624,997759,997980,997986,998010,998030,998619,998628,998759,998804,998822,999260,999286,999306,999591,999601,999623,999715-999716,999724,999793,105,1000169,1000213,1000229,1000231,1000233,1000240,1000245,1000248,1000265,1000527,1000689,1000696,1000699-1000700,1000705,1000708,1001065,1001080,1001153,1001187,1001490,1001609,1001638,1001652,1001723,1001741,1001744-1001745,1001751,1002080,1002189,1002476,1002480,1002488,1002506 +/harmony/enhanced/java/trunk/classlib:929253-997624,997759,997980,997986,998010,998030,998619,998628,998759,998804,998822,999260,999286,999306,999591,999601,999623,999715-999716,999724,999793,105,1000169,1000213,1000229,1000231,1000233,1000240,1000245,1000248,1000265,1000527,1000689,1000696,1000699-1000700,1000705,1000708,1001065,1001080,1001153,1001187,1001490,1001609,1001638,1001652,1001723,1001741,1001744-1001745,1001751,1002080,1002189,1002476,1002480,1002488,1002506,1002511 /harmony/enhanced/trunk/classlib:476395-929252 /harmony/enhanced/trunk/working_classlib:476396-920147 /incubator/harmony/enhanced/trunk/classlib:292550-476394 Propchange: harmony/enhanced/java/branches/java6/classlib/depends/libs/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Sep 29 17:00:09 2010 @@ -1,4 +1,4 @@ /harmony/enhanced/classlib/trunk/depends/libs:544451-926091 -/harmony/enhanced/java/trunk/classlib/depends/libs:929253-997624,997759,997980,997986,998010,998030,998619,998628,998759,998804,998822,999260,999286,999306,999591,999601,999623,999715-999716,999724,999793,105,1000169,1000213,1000229,1000231,1000233,1000240,1000245,1000248,1000265,1000527,1000689,1000696,100
Re: [drlvm] Should the referent of a PhantomReference be cleared before it is enqueued?
Agreed. I tried some simple tests commenting out the line in the DRLVM code that nulls the referent (looks to be line 400, finalizer_weakref.cpp). This fixes the difference for one GC cycle, but we then crash in the next GC cycle. I have a feeling that this is because the referent is actually freed in the first cycle, but because we are no longer nulling the reference from the PhantomReference the next GC cycle tries to free it again and crashes. I'm not sure whether just removing the code above this line that GCs the referent (so it only gets GC'ed when it is completely unreachable rather than phantomly reachable) will fix the crash - I'll take a bit more of a look at it when I get time. If anyone has some knowledge of this code or how to fix this issue it'd be a great help! Regards, Oliver On 14/08/2010 11:39, Deven You wrote: I agree with you. > From my point, the spec means phantom references only be cleared by Java code, GC won't clear them automatically. And GC only adds them into the corresponding reference queue so that Java program can know the change and decides whether or not clear these phantom references to make their referents can be garbage collected. 2010/8/12 Oliver Deakin I have discovered that DRLVM appears to clear the referent field of a PhantomReference before calling its enqueue() method (this can be shown quite easily by printing the referent field in Reference.enqueue()). This behaviour appears to differ from the RI, on which a non-null referent can be got hold of via reflection [1]. The spec for PhantomReference says: "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable." This reads to me that soft and weak references clear their referent field before being enqueued, but phantom references should only make the referent eligible for gc once the referent is no longer phantomly reachable (or reachable at all). If this is the case, it would seem that DRLVM's current behaviour does not match the spec. Any comments/thoughts? Regards, Oliver [1] An example of this kind of use/abuse of PhantomReference can be found at: http://www.roseindia.net/javatutorials/references.shtml -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Should the referent of a PhantomReference be cleared before it is enqueued?
I agree with you. >From my point, the spec means phantom references only be cleared by Java code, GC won't clear them automatically. And GC only adds them into the corresponding reference queue so that Java program can know the change and decides whether or not clear these phantom references to make their referents can be garbage collected. 2010/8/12 Oliver Deakin > I have discovered that DRLVM appears to clear the referent field of a > PhantomReference before calling its enqueue() method (this can be shown > quite easily by printing the referent field in Reference.enqueue()). This > behaviour appears to differ from the RI, on which a non-null referent can be > got hold of via reflection [1]. The spec for PhantomReference says: > > "Unlike soft and weak references, phantom references are not automatically > cleared by the garbage collector as they are enqueued. An object that is > reachable via phantom references will remain so until all such references > are cleared or themselves become unreachable." > > This reads to me that soft and weak references clear their referent field > before being enqueued, but phantom references should only make the referent > eligible for gc once the referent is no longer phantomly reachable (or > reachable at all). If this is the case, it would seem that DRLVM's current > behaviour does not match the spec. > > Any comments/thoughts? > > Regards, > Oliver > > [1] An example of this kind of use/abuse of PhantomReference can be found > at: > http://www.roseindia.net/javatutorials/references.shtml > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >
[drlvm] Should the referent of a PhantomReference be cleared before it is enqueued?
I have discovered that DRLVM appears to clear the referent field of a PhantomReference before calling its enqueue() method (this can be shown quite easily by printing the referent field in Reference.enqueue()). This behaviour appears to differ from the RI, on which a non-null referent can be got hold of via reflection [1]. The spec for PhantomReference says: "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable." This reads to me that soft and weak references clear their referent field before being enqueued, but phantom references should only make the referent eligible for gc once the referent is no longer phantomly reachable (or reachable at all). If this is the case, it would seem that DRLVM's current behaviour does not match the spec. Any comments/thoughts? Regards, Oliver [1] An example of this kind of use/abuse of PhantomReference can be found at: http://www.roseindia.net/javatutorials/references.shtml -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Best practice compiling/building/debugging the VM under windows
В Чтв, 24/06/2010 в 23:15 +0200, Wagner, Michael пишет: > Hello, > > > > i am new to apache harmony. Unfortunately I was not really able to find > a best practice guide how to compile and especially debug the VM under > windows (best EMT64). I think there was something on wiki. > I had trouble directly using the 'sln' files for visual studio. Should > one use VS? What do you use? Or did I miss some documentation? Under Solution files don't work on windows. You should use the same ant command line build that worked for you on linux. It should work in the same way on windows. > Linux it went very well as described on the pages (but even there, it > was not really clear to me which IDE to use if any). However, I would > like to do it on windows, since this is the main platform for me. Build process doesn't require/work in any IDE. Just command line at the moment. Debugging requires native platform tools, gdb on linux, MSVC on windows. > Is anybody using eclipse cdt? I think no.
[drlvm] Best practice compiling/building/debugging the VM under windows
Hello, i am new to apache harmony. Unfortunately I was not really able to find a best practice guide how to compile and especially debug the VM under windows (best EMT64). I had trouble directly using the 'sln' files for visual studio. Should one use VS? What do you use? Or did I miss some documentation? Under Linux it went very well as described on the pages (but even there, it was not really clear to me which IDE to use if any). However, I would like to do it on windows, since this is the main platform for me. Is anybody using eclipse cdt? Appreciate every help and hint I can get, Michael
Re: zlib in drlvm
In message <[email protected]>, Mark Hindess writes: > > In message <[email protected]>, Mark Hindess writes: > > > > In message <[email protected]>, > > Nathan Beyer writes: > > > > > > While trying to perform a fresh build, zlib 1.2.3 wasn't downloading > > > and it looks like zlib.net has released 1.2.4. While trying to update > > > zlib, i noticed a few things: > > > * The pre-built binary is only used for Windows - i assume we're using > > > a shared zlib on other OSes, but do we keep the version controlled? > > > > I think the zlib api is pretty stable. So I'm not overly concerned > > about version control. However, I suspect it is moot since hyzlib > > is loaded first and almost certainly takes priority over the system > > version. (Unless you set -Dhy.local.zlib=true to pick up the system > > version instead of hyzlib [unix only].) > > > > > * The pre-built binary is only used for x86 Windows - we're > > > downloading an 'x86_64' version from a JIRA attachment [1]. Shouldn't > > > we put this into SVN, like the other pre-built dependencies? > > > > We should find a way to remove it and use only hyzlib instead. > > > > > * Anyone know how the x86_64 binary was built? > > > > No. I don't know enough about windows dll loading but perhaps it is > > overriden by hyzlib anyway? > > > > > -Nathan > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-3196 > > In commit r939640, I fixed drlvm to use hyzlib on windows as the > download was broken again and there didn't seem to be a new equivalent. > Still need to: > > 1) Remove depends.properties entries. Committed in r939661. > 2) Use hyzlib during link on unix (when hy.local.zlib=true is not set). Committed in r939686. > 3) Upgrade hyzlib in classlib to use zlib 1.2.5 Committed in r939663. Regards, -Mark.
Re: zlib in drlvm
In message <[email protected]>, Mark Hindess writes: > > In message <[email protected]>, > Nathan Beyer writes: > > > > While trying to perform a fresh build, zlib 1.2.3 wasn't downloading > > and it looks like zlib.net has released 1.2.4. While trying to update > > zlib, i noticed a few things: > > * The pre-built binary is only used for Windows - i assume we're using > > a shared zlib on other OSes, but do we keep the version controlled? > > I think the zlib api is pretty stable. So I'm not overly concerned > about version control. However, I suspect it is moot since hyzlib > is loaded first and almost certainly takes priority over the system > version. (Unless you set -Dhy.local.zlib=true to pick up the system > version instead of hyzlib [unix only].) > > > * The pre-built binary is only used for x86 Windows - we're > > downloading an 'x86_64' version from a JIRA attachment [1]. Shouldn't > > we put this into SVN, like the other pre-built dependencies? > > We should find a way to remove it and use only hyzlib instead. > > > * Anyone know how the x86_64 binary was built? > > No. I don't know enough about windows dll loading but perhaps it is > overriden by hyzlib anyway? > > > -Nathan > > > > [1] https://issues.apache.org/jira/browse/HARMONY-3196 In commit r939640, I fixed drlvm to use hyzlib on windows as the download was broken again and there didn't seem to be a new equivalent. Still need to: 1) Remove depends.properties entries. 2) Use hyzlib during link on unix (when hy.local.zlib=true is not set). 3) Upgrade hyzlib in classlib to use zlib 1.2.5 Regards, Mark.
Re: [drlvm][gc]: UNIQUE MARK SWEEP gc failed when running specjvm2008
Hi Dennis, With what sub-benchmark did you meet this problem? Some sub-benchmarks require large heap. You configuration should have no problem. Btw, what is the symptom? Thanks, Ligang On Mon, Apr 26, 2010 at 12:00 PM, dennis.xlc wrote: > Hi all, > I've just tried to run specjvm2008 using UNIQUE MARK SWEEP gc but > failed. > > I just uncomment the macro USE_UNIQUE_MARK_SWEEP_GC, and use comand line > like: > java -XX:gc.unique_algorithm=MARK_SWEEP ... > > Is there something wrong with my configure or the unique mark sweep does > NOT work when running specjvm2008? > > Regards, > > Dennis > -- Ligang Wang China Runtime Technologies Lab, SSG/SSD/MRTC, Intel
[drlvm][gc]: UNIQUE MARK SWEEP gc failed when running specjvm2008
Hi all, I've just tried to run specjvm2008 using UNIQUE MARK SWEEP gc but failed. I just uncomment the macro USE_UNIQUE_MARK_SWEEP_GC, and use comand line like: java -XX:gc.unique_algorithm=MARK_SWEEP ... Is there something wrong with my configure or the unique mark sweep does NOT work when running specjvm2008? Regards, Dennis
Re: svn commit: r926362 - /harmony/enhanced/branches/java6/drlvm/
In case anyone is wondering (I know I would be but perhaps it is just me) then the reason I did this copy rather than doing the merge of the equivalent change from federated trunk to the federated branches/java6 tree is that I think committing the merge would have resulted in transmitting the whole of drlvm where as the copy happens on the server. It will all come out the same when I finish doing the merges shortly. Regards, Mark. In message <[email protected]>, [email protected] writes: > > Author: hindessm > Date: Mon Mar 22 21:47:14 2010 > New Revision: 926362 > > URL: http://svn.apache.org/viewvc?rev=926362&view=rev > Log: > Copy drlvm/trunk (there was no drlvm java6 branch) to branches/java6/drlvm. > > Added: > harmony/enhanced/branches/java6/drlvm/ (props changed) > - copied from r926361, harmony/enhanced/drlvm/trunk/ > > Propchange: harmony/enhanced/branches/java6/drlvm/ > - > - > --- svn:ignore (added) > +++ svn:ignore Mon Mar 22 21:47:14 2010 > @@ -0,0 +1,4 @@ > +.cdtproject > +.project > +.settings > +deploy > > Propchange: harmony/enhanced/branches/java6/drlvm/ > - > - > --- svn:mergeinfo (added) > +++ svn:mergeinfo Mon Mar 22 21:47:14 2010 > @@ -0,0 +1,2 @@ > +/harmony/enhanced/trunk/working_vm:476396-920147 > +/incubator/harmony/enhanced/trunk/working_vm:423974-476394 >
Re: zlib in drlvm
In message <[email protected]>, Nathan Beyer writes: > > While trying to perform a fresh build, zlib 1.2.3 wasn't downloading > and it looks like zlib.net has released 1.2.4. While trying to update > zlib, i noticed a few things: > * The pre-built binary is only used for Windows - i assume we're using > a shared zlib on other OSes, but do we keep the version controlled? I think the zlib api is pretty stable. So I'm not overly concerned about version control. However, I suspect it is moot since hyzlib is loaded first and almost certainly takes priority over the system version. (Unless you set -Dhy.local.zlib=true to pick up the system version instead of hyzlib [unix only].) > * The pre-built binary is only used for x86 Windows - we're > downloading an 'x86_64' version from a JIRA attachment [1]. Shouldn't > we put this into SVN, like the other pre-built dependencies? We should find a way to remove it and use only hyzlib instead. > * Anyone know how the x86_64 binary was built? No. I don't know enough about windows dll loading but perhaps it is overriden by hyzlib anyway? > -Nathan > > [1] https://issues.apache.org/jira/browse/HARMONY-3196 Regards, Mark
zlib in drlvm
While trying to perform a fresh build, zlib 1.2.3 wasn't downloading and it looks like zlib.net has released 1.2.4. While trying to update zlib, i noticed a few things: * The pre-built binary is only used for Windows - i assume we're using a shared zlib on other OSes, but do we keep the version controlled? * The pre-built binary is only used for x86 Windows - we're downloading an 'x86_64' version from a JIRA attachment [1]. Shouldn't we put this into SVN, like the other pre-built dependencies? * Anyone know how the x86_64 binary was built? -Nathan [1] https://issues.apache.org/jira/browse/HARMONY-3196
Re: [drlvm] java.vm.version
In message <[email protected]>, Nathan Beyer writes: > > On Tue, Mar 9, 2010 at 4:09 PM, Mark Hindess > wrote: > > > > DRLVM current reports the java.vm.version system property as > > "11.2.0". It has done so since at least 2006-11-30. I think it > > would be more constructive if this version string changed over time. > > > > I propose changing this to be constructed from the existing > > variables defined vm/vmcore/include/version_svn_tag.h, namely: > > > > JAVA_RUNTIME_VERSION "r" VERSION_SVN_TAG > > > > which will be: > > > > 1.5.0r921154 > > 1.6.0r921154 > > > > for the trunk and java6 build respectively. > > > > Does this seem reasonable? > > Yes please! > > I'd perhaps propose a hyphen in front of the revision, but that's not > a big deal. Since the RI uses a hyphen before the build number that probably makes sense. Thanks, Mark
Re: [drlvm] java.vm.version
On Tue, Mar 9, 2010 at 4:09 PM, Mark Hindess wrote: > > DRLVM current reports the java.vm.version system property as "11.2.0". > It has done so since at least 2006-11-30. I think it would be more > constructive if this version string changed over time. > > I propose changing this to be constructed from the existing variables > defined vm/vmcore/include/version_svn_tag.h, namely: > > JAVA_RUNTIME_VERSION "r" VERSION_SVN_TAG > > which will be: > > 1.5.0r921154 > 1.6.0r921154 > > for the trunk and java6 build respectively. > > Does this seem reasonable? Yes please! I'd perhaps propose a hyphen in front of the revision, but that's not a big deal. > > Regards, > Mark. > > >
[drlvm] java.vm.version
DRLVM current reports the java.vm.version system property as "11.2.0". It has done so since at least 2006-11-30. I think it would be more constructive if this version string changed over time. I propose changing this to be constructed from the existing variables defined vm/vmcore/include/version_svn_tag.h, namely: JAVA_RUNTIME_VERSION "r" VERSION_SVN_TAG which will be: 1.5.0r921154 1.6.0r921154 for the trunk and java6 build respectively. Does this seem reasonable? Regards, Mark.
Re: The minimum environment need to set is SystemRoot, using harmony6 and drlvm
Yes. I see. It seems to be the difference between vs2003 and vs2008, since
Tony also failed on JarExecTest from his report. I will try to figure it
out.
On Tue, Dec 29, 2009 at 11:14 AM, Nathan Beyer wrote:
> I don't get any errors in the archive module.
> Environment:
> Windows XP SP3
> VisualStudio 2003 SP1
> java6 branch
>
> On Mon, Dec 28, 2009 at 8:29 PM, Charles Lee
> wrote:
> > Hi Nathan,
> >
> > With the code:
> > String[] envp = new String[] {"A=B", /*envSystemRoot*/};
> > Process p = rt.exec(command, envp);
> >
> > If we provide a envp to the Runtime, we are supposed to provide all the
> > environment to the sub process. (We are using CreateProcess on Windows,
> > which you can find in Runtime_win.cpp in vmcore).
> > It is not I do not have the SystemRoot env. It is just the program
> suppose
> > to be.
> >
> > I have found that JarExecTest is passed on your site according to your
> test
> > report. Would you please try the test case I have posted above? will it
> also
> > pass on your site?
> >
> > For more information:
> > I am using java6 branch with revision: r893709 and the drlvm with
> revision:
> > r889144
> >
> >
> > On Tue, Dec 29, 2009 at 9:01 AM, Nathan Beyer
> wrote:
> >
> >> SystemRoot is pretty common on Windows - it's been standard since
> >> WinXP. I'm surprised that you don't have it set.
> >>
> >> -Nathan
> >>
> >> On Mon, Dec 28, 2009 at 3:00 AM, Charles Lee
> >> wrote:
> >> > Hi guys,
> >> >
> >> > I am running the selected[1] test cases against the harmony6 + drlvm.
> My
> >> > local properties is:
> >> >
> >> > os: windows xp professional sp2
> >> > sdk: visual studio 2008
> >> > link: Microsoft (R) Incremental Linker Version 9.00.21022.08
> >> >
> >> > Only one test case fail on my
> >> > site: org.apache.harmony.archive.tests.java.util.jar.JarExecTest
> >> >
> >> > Running test case below[3], RI returns the version of its java but
> >> harmony
> >> > return nothing but the error code -1072365564 (0xC0150004). harmony
> can
> >> not
> >> > initialize the java command successfully. If I add the SystemRoot
> >> > environment (uncomment the code which is commented), harmony will pass
> >> test
> >> > case[3].
> >> >
> >> > 1. Will anybody test [3] using vs2003? will it pass building with
> vs2003?
> >> > 2. Why we need SystemRoot on windows?
> >> > 3. I can add the environment SystemRoot in the java code; or add the
> >> > SystemRoot in the Runtime_win.cpp in drlvm; any other good solution to
> >> this
> >> > problem?
> >> >
> >> >
> >> >
> >> > [1] ANNOTATION, ARCHIVE, AUTH, BEANS, CONCURRENT, CRYPTO, JNDI,
> >> > INSTRUMENT, LOGGING, LUNI, MATH, NIO,NIO_CHAR, PACK200, PREFS, REGEX,
> >> > SECURITY, SQL, TEXT, XML[2]
> >> > [2] I am not running lang-management test cases, because it will hang
> on
> >> my
> >> > machine.
> >> > [3] public static void main(String[] args) throws Exception {
> >> >Runtime rt = Runtime.getRuntime();
> >> >String javaHome = System.getProperty("java.home");
> >> >System.out.println(javaHome);
> >> >String command = javaHome + "/bin/java -version";
> >> > //String systemRoot = System.getenv("SystemRoot");
> >> > //System.out.println(systemRoot);
> >> > //String envSystemRoot = "SystemRoot="+systemRoot;
> >> >String[] envp = new String[] {"A=B", /*envSystemRoot*/};
> >> >Process p = rt.exec(command, envp);
> >> >p.waitFor();
> >> >System.out.println("Exit value: " + p.exitValue());
> >> >InputStream in = p.getInputStream();
> >> >int read = -1;
> >> >while ((read = in.read()) != -1) {
> >> >System.out.print((char)read);
> >> >}
> >> >System.out.println();
> >> >in = p.getErrorStream();
> >> >read = -1;
> >> >while ((read = in.read()) != -1) {
> >> >System.out.print((char)read);
> >> >}
> >> >System.out.println();
> >> >}
> >> >
> >> > --
> >> > Yours sincerely,
> >> > Charles Lee
> >> >
> >>
> >
> >
> >
> > --
> > Yours sincerely,
> > Charles Lee
> >
>
--
Yours sincerely,
Charles Lee
Re: The minimum environment need to set is SystemRoot, using harmony6 and drlvm
I don't get any errors in the archive module.
Environment:
Windows XP SP3
VisualStudio 2003 SP1
java6 branch
On Mon, Dec 28, 2009 at 8:29 PM, Charles Lee wrote:
> Hi Nathan,
>
> With the code:
> String[] envp = new String[] {"A=B", /*envSystemRoot*/};
> Process p = rt.exec(command, envp);
>
> If we provide a envp to the Runtime, we are supposed to provide all the
> environment to the sub process. (We are using CreateProcess on Windows,
> which you can find in Runtime_win.cpp in vmcore).
> It is not I do not have the SystemRoot env. It is just the program suppose
> to be.
>
> I have found that JarExecTest is passed on your site according to your test
> report. Would you please try the test case I have posted above? will it also
> pass on your site?
>
> For more information:
> I am using java6 branch with revision: r893709 and the drlvm with revision:
> r889144
>
>
> On Tue, Dec 29, 2009 at 9:01 AM, Nathan Beyer wrote:
>
>> SystemRoot is pretty common on Windows - it's been standard since
>> WinXP. I'm surprised that you don't have it set.
>>
>> -Nathan
>>
>> On Mon, Dec 28, 2009 at 3:00 AM, Charles Lee
>> wrote:
>> > Hi guys,
>> >
>> > I am running the selected[1] test cases against the harmony6 + drlvm. My
>> > local properties is:
>> >
>> > os: windows xp professional sp2
>> > sdk: visual studio 2008
>> > link: Microsoft (R) Incremental Linker Version 9.00.21022.08
>> >
>> > Only one test case fail on my
>> > site: org.apache.harmony.archive.tests.java.util.jar.JarExecTest
>> >
>> > Running test case below[3], RI returns the version of its java but
>> harmony
>> > return nothing but the error code -1072365564 (0xC0150004). harmony can
>> not
>> > initialize the java command successfully. If I add the SystemRoot
>> > environment (uncomment the code which is commented), harmony will pass
>> test
>> > case[3].
>> >
>> > 1. Will anybody test [3] using vs2003? will it pass building with vs2003?
>> > 2. Why we need SystemRoot on windows?
>> > 3. I can add the environment SystemRoot in the java code; or add the
>> > SystemRoot in the Runtime_win.cpp in drlvm; any other good solution to
>> this
>> > problem?
>> >
>> >
>> >
>> > [1] ANNOTATION, ARCHIVE, AUTH, BEANS, CONCURRENT, CRYPTO, JNDI,
>> > INSTRUMENT, LOGGING, LUNI, MATH, NIO,NIO_CHAR, PACK200, PREFS, REGEX,
>> > SECURITY, SQL, TEXT, XML[2]
>> > [2] I am not running lang-management test cases, because it will hang on
>> my
>> > machine.
>> > [3] public static void main(String[] args) throws Exception {
>> > Runtime rt = Runtime.getRuntime();
>> > String javaHome = System.getProperty("java.home");
>> > System.out.println(javaHome);
>> > String command = javaHome + "/bin/java -version";
>> > // String systemRoot = System.getenv("SystemRoot");
>> > // System.out.println(systemRoot);
>> > // String envSystemRoot = "SystemRoot="+systemRoot;
>> > String[] envp = new String[] {"A=B", /*envSystemRoot*/};
>> > Process p = rt.exec(command, envp);
>> > p.waitFor();
>> > System.out.println("Exit value: " + p.exitValue());
>> > InputStream in = p.getInputStream();
>> > int read = -1;
>> > while ((read = in.read()) != -1) {
>> > System.out.print((char)read);
>> > }
>> > System.out.println();
>> > in = p.getErrorStream();
>> > read = -1;
>> > while ((read = in.read()) != -1) {
>> > System.out.print((char)read);
>> > }
>> > System.out.println();
>> > }
>> >
>> > --
>> > Yours sincerely,
>> > Charles Lee
>> >
>>
>
>
>
> --
> Yours sincerely,
> Charles Lee
>
Re: The minimum environment need to set is SystemRoot, using harmony6 and drlvm
Hi Nathan,
With the code:
String[] envp = new String[] {"A=B", /*envSystemRoot*/};
Process p = rt.exec(command, envp);
If we provide a envp to the Runtime, we are supposed to provide all the
environment to the sub process. (We are using CreateProcess on Windows,
which you can find in Runtime_win.cpp in vmcore).
It is not I do not have the SystemRoot env. It is just the program suppose
to be.
I have found that JarExecTest is passed on your site according to your test
report. Would you please try the test case I have posted above? will it also
pass on your site?
For more information:
I am using java6 branch with revision: r893709 and the drlvm with revision:
r889144
On Tue, Dec 29, 2009 at 9:01 AM, Nathan Beyer wrote:
> SystemRoot is pretty common on Windows - it's been standard since
> WinXP. I'm surprised that you don't have it set.
>
> -Nathan
>
> On Mon, Dec 28, 2009 at 3:00 AM, Charles Lee
> wrote:
> > Hi guys,
> >
> > I am running the selected[1] test cases against the harmony6 + drlvm. My
> > local properties is:
> >
> > os: windows xp professional sp2
> > sdk: visual studio 2008
> > link: Microsoft (R) Incremental Linker Version 9.00.21022.08
> >
> > Only one test case fail on my
> > site: org.apache.harmony.archive.tests.java.util.jar.JarExecTest
> >
> > Running test case below[3], RI returns the version of its java but
> harmony
> > return nothing but the error code -1072365564 (0xC0150004). harmony can
> not
> > initialize the java command successfully. If I add the SystemRoot
> > environment (uncomment the code which is commented), harmony will pass
> test
> > case[3].
> >
> > 1. Will anybody test [3] using vs2003? will it pass building with vs2003?
> > 2. Why we need SystemRoot on windows?
> > 3. I can add the environment SystemRoot in the java code; or add the
> > SystemRoot in the Runtime_win.cpp in drlvm; any other good solution to
> this
> > problem?
> >
> >
> >
> > [1] ANNOTATION, ARCHIVE, AUTH, BEANS, CONCURRENT, CRYPTO, JNDI,
> > INSTRUMENT, LOGGING, LUNI, MATH, NIO,NIO_CHAR, PACK200, PREFS, REGEX,
> > SECURITY, SQL, TEXT, XML[2]
> > [2] I am not running lang-management test cases, because it will hang on
> my
> > machine.
> > [3] public static void main(String[] args) throws Exception {
> >Runtime rt = Runtime.getRuntime();
> >String javaHome = System.getProperty("java.home");
> >System.out.println(javaHome);
> >String command = javaHome + "/bin/java -version";
> > //String systemRoot = System.getenv("SystemRoot");
> > //System.out.println(systemRoot);
> > //String envSystemRoot = "SystemRoot="+systemRoot;
> >String[] envp = new String[] {"A=B", /*envSystemRoot*/};
> >Process p = rt.exec(command, envp);
> >p.waitFor();
> >System.out.println("Exit value: " + p.exitValue());
> >InputStream in = p.getInputStream();
> >int read = -1;
> >while ((read = in.read()) != -1) {
> >System.out.print((char)read);
> >}
> >System.out.println();
> >in = p.getErrorStream();
> >read = -1;
> >while ((read = in.read()) != -1) {
> >System.out.print((char)read);
> >}
> >System.out.println();
> >}
> >
> > --
> > Yours sincerely,
> > Charles Lee
> >
>
--
Yours sincerely,
Charles Lee
Re: The minimum environment need to set is SystemRoot, using harmony6 and drlvm
SystemRoot is pretty common on Windows - it's been standard since
WinXP. I'm surprised that you don't have it set.
-Nathan
On Mon, Dec 28, 2009 at 3:00 AM, Charles Lee wrote:
> Hi guys,
>
> I am running the selected[1] test cases against the harmony6 + drlvm. My
> local properties is:
>
> os: windows xp professional sp2
> sdk: visual studio 2008
> link: Microsoft (R) Incremental Linker Version 9.00.21022.08
>
> Only one test case fail on my
> site: org.apache.harmony.archive.tests.java.util.jar.JarExecTest
>
> Running test case below[3], RI returns the version of its java but harmony
> return nothing but the error code -1072365564 (0xC0150004). harmony can not
> initialize the java command successfully. If I add the SystemRoot
> environment (uncomment the code which is commented), harmony will pass test
> case[3].
>
> 1. Will anybody test [3] using vs2003? will it pass building with vs2003?
> 2. Why we need SystemRoot on windows?
> 3. I can add the environment SystemRoot in the java code; or add the
> SystemRoot in the Runtime_win.cpp in drlvm; any other good solution to this
> problem?
>
>
>
> [1] ANNOTATION, ARCHIVE, AUTH, BEANS, CONCURRENT, CRYPTO, JNDI,
> INSTRUMENT, LOGGING, LUNI, MATH, NIO,NIO_CHAR, PACK200, PREFS, REGEX,
> SECURITY, SQL, TEXT, XML[2]
> [2] I am not running lang-management test cases, because it will hang on my
> machine.
> [3] public static void main(String[] args) throws Exception {
> Runtime rt = Runtime.getRuntime();
> String javaHome = System.getProperty("java.home");
> System.out.println(javaHome);
> String command = javaHome + "/bin/java -version";
> // String systemRoot = System.getenv("SystemRoot");
> // System.out.println(systemRoot);
> // String envSystemRoot = "SystemRoot="+systemRoot;
> String[] envp = new String[] {"A=B", /*envSystemRoot*/};
> Process p = rt.exec(command, envp);
> p.waitFor();
> System.out.println("Exit value: " + p.exitValue());
> InputStream in = p.getInputStream();
> int read = -1;
> while ((read = in.read()) != -1) {
> System.out.print((char)read);
> }
> System.out.println();
> in = p.getErrorStream();
> read = -1;
> while ((read = in.read()) != -1) {
> System.out.print((char)read);
> }
> System.out.println();
> }
>
> --
> Yours sincerely,
> Charles Lee
>
The minimum environment need to set is SystemRoot, using harmony6 and drlvm
Hi guys,
I am running the selected[1] test cases against the harmony6 + drlvm. My
local properties is:
os: windows xp professional sp2
sdk: visual studio 2008
link: Microsoft (R) Incremental Linker Version 9.00.21022.08
Only one test case fail on my
site: org.apache.harmony.archive.tests.java.util.jar.JarExecTest
Running test case below[3], RI returns the version of its java but harmony
return nothing but the error code -1072365564 (0xC0150004). harmony can not
initialize the java command successfully. If I add the SystemRoot
environment (uncomment the code which is commented), harmony will pass test
case[3].
1. Will anybody test [3] using vs2003? will it pass building with vs2003?
2. Why we need SystemRoot on windows?
3. I can add the environment SystemRoot in the java code; or add the
SystemRoot in the Runtime_win.cpp in drlvm; any other good solution to this
problem?
[1] ANNOTATION, ARCHIVE, AUTH, BEANS, CONCURRENT, CRYPTO, JNDI,
INSTRUMENT, LOGGING, LUNI, MATH, NIO,NIO_CHAR, PACK200, PREFS, REGEX,
SECURITY, SQL, TEXT, XML[2]
[2] I am not running lang-management test cases, because it will hang on my
machine.
[3] public static void main(String[] args) throws Exception {
Runtime rt = Runtime.getRuntime();
String javaHome = System.getProperty("java.home");
System.out.println(javaHome);
String command = javaHome + "/bin/java -version";
//String systemRoot = System.getenv("SystemRoot");
//System.out.println(systemRoot);
//String envSystemRoot = "SystemRoot="+systemRoot;
String[] envp = new String[] {"A=B", /*envSystemRoot*/};
Process p = rt.exec(command, envp);
p.waitFor();
System.out.println("Exit value: " + p.exitValue());
InputStream in = p.getInputStream();
int read = -1;
while ((read = in.read()) != -1) {
System.out.print((char)read);
}
System.out.println();
in = p.getErrorStream();
read = -1;
while ((read = in.read()) != -1) {
System.out.print((char)read);
}
System.out.println();
}
--
Yours sincerely,
Charles Lee
Re: svn commit: r889047 - /harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp
On 2009-12-10 16:37, Regis wrote: On 2009-12-10 16:25, Mark Hindess wrote: Please revert this. DRLVM tree is still frozen for the 6.0M1 release. If you want it unfrozen, then perhaps you should test and report issues so that we can finalize the 6.0M1 release? -Mark In message<[email protected]>, [email protected] writes: Author: regisxu Date: Thu Dec 10 01:17:51 2009 New Revision: 889047 URL: http://svn.apache.org/viewvc?rev=889047&view=rev Log: Apply patch for HARMONY-6399: [drlvm] drlvm doesn't support "-javaagent" opti on Modified: harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp Modified: harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp URL: http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/vmcore/src/ init/parse_arguments.cpp?rev=889047&r1=889046&r2=889047&view=diff ===== = --- harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp (orig inal) +++ harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp Thu D ec 10 01:17:51 2009 @@ -348,6 +348,13 @@ else if (begins_with(option, "-agentpath:")) { p_env->TI->addAgent(option); } + else if (begins_with(option, "-javaagent:")) { + char* dest = (char*) STD_MALLOC(strlen("-agentlib:hyinstrument=" ) + strlen(option + 11) + 1); + strcpy(dest, "-agentlib:hyinstrument="); + strcat(dest, option + 11); + p_env->TI->addAgent(dest); + STD_FREE((void*) dest); + } else if (begins_with(option, "-Xrun")) { // Compatibility with JNDI p_env->TI->addAgent(option); Sorry, I thought it is reopened. I'll revert it. Reverted at r889144. -- Best Regards, Regis.
Re: svn commit: r889047 - /harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp
On 2009-12-10 16:25, Mark Hindess wrote: Please revert this. DRLVM tree is still frozen for the 6.0M1 release. If you want it unfrozen, then perhaps you should test and report issues so that we can finalize the 6.0M1 release? -Mark In message<[email protected]>, [email protected] writes: Author: regisxu Date: Thu Dec 10 01:17:51 2009 New Revision: 889047 URL: http://svn.apache.org/viewvc?rev=889047&view=rev Log: Apply patch for HARMONY-6399: [drlvm] drlvm doesn't support "-javaagent" opti on Modified: harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp Modified: harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp URL: http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/vmcore/src/ init/parse_arguments.cpp?rev=889047&r1=889046&r2=889047&view=diff = = --- harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp (orig inal) +++ harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp Thu D ec 10 01:17:51 2009 @@ -348,6 +348,13 @@ else if (begins_with(option, "-agentpath:")) { p_env->TI->addAgent(option); } +else if (begins_with(option, "-javaagent:")) { +char* dest = (char*) STD_MALLOC(strlen("-agentlib:hyinstrument=" ) + strlen(option + 11) + 1); +strcpy(dest, "-agentlib:hyinstrument="); +strcat(dest, option + 11); +p_env->TI->addAgent(dest); +STD_FREE((void*) dest); +} else if (begins_with(option, "-Xrun")) { // Compatibility with JNDI p_env->TI->addAgent(option); Sorry, I thought it is reopened. I'll revert it. -- Best Regards, Regis.
Re: svn commit: r889047 - /harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp
Please revert this. DRLVM tree is still frozen for the 6.0M1 release. If you want it unfrozen, then perhaps you should test and report issues so that we can finalize the 6.0M1 release? -Mark In message <[email protected]>, [email protected] writes: > > Author: regisxu > Date: Thu Dec 10 01:17:51 2009 > New Revision: 889047 > > URL: http://svn.apache.org/viewvc?rev=889047&view=rev > Log: > Apply patch for HARMONY-6399: [drlvm] drlvm doesn't support "-javaagent" opti > on > > > Modified: > harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp > > Modified: harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp > URL: http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/vmcore/src/ > init/parse_arguments.cpp?rev=889047&r1=889046&r2=889047&view=diff > ===== > = > --- harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp (orig > inal) > +++ harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/parse_arguments.cpp Thu D > ec 10 01:17:51 2009 > @@ -348,6 +348,13 @@ > else if (begins_with(option, "-agentpath:")) { > p_env->TI->addAgent(option); > } > +else if (begins_with(option, "-javaagent:")) { > +char* dest = (char*) STD_MALLOC(strlen("-agentlib:hyinstrument=" > ) + strlen(option + 11) + 1); > +strcpy(dest, "-agentlib:hyinstrument="); > +strcat(dest, option + 11); > +p_env->TI->addAgent(dest); > +STD_FREE((void*) dest); > +} > else if (begins_with(option, "-Xrun")) { > // Compatibility with JNDI > p_env->TI->addAgent(option); >
Re: Re: [DRLVM][JVMTI]a bug when running SpecJVM98 _201_compress
Thanks a lot! I modified the source code of SpecJVM and the agent works well
now~!
2009-11-27
johnnylj98
发件人： Gregory Shimansky
发送时间： 2009-11-26 02:46:12
收件人： dev
抄送：
主题： Re: [DRLVM][JVMTI]a bug when running SpecJVM98 _201_compress
IIRC VMDeath is not sent if System.exit is used by application. This is a
limitation of JMVTI implementation in DRLVM. Most likely Spec uses exit to
finish.
> Hi all,
> I'm doing some tuning work for Harmony running SpecJVM98.
> I write a JVMTI agent to catch VMDeath event and do something at the end of
> JVM's life, but that doesn't work(the same agent work well for hotspot).
>
> my agent likes bellow:
> ...
> static void JNICALL
> callbackVMDeath(jvmtiEnv *jvmti, JNIEnv *jni)
> {
> assert(false);
> printf("vm death\n");
> }
> JNIEXPORT void JNICALL Agent_OnUnload(JavaVM *jvm)
> {
> assert(false);
> printf("unload!");
> }
> JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void
> *reserved) {
> ...
> error = jvmti->SetEventNotificationMode(JVMTI_ENABLE,JVMTI_EVENT_VM_DEATH,
> (jthread)NULL); callbacks.VMDeath = &callbackVMDeath;
> error = jvmti->SetEventCallbacks(&callbacks,(jint)sizeof(callbacks));
> ...
> }
> ...
> The program ends correctly. This is really strange. Can anyone try this
> case and explain for me?
>
> Thanks a lot.
>
> 2009-11-26
>
>
>
> johnnylj98
>
Re: [DRLVM][JVMTI]a bug when running SpecJVM98 _201_compress
IIRC VMDeath is not sent if System.exit is used by application. This is a
limitation of JMVTI implementation in DRLVM. Most likely Spec uses exit to
finish.
> Hi all,
> I'm doing some tuning work for Harmony running SpecJVM98.
> I write a JVMTI agent to catch VMDeath event and do something at the end of
> JVM's life, but that doesn't work(the same agent work well for hotspot).
>
> my agent likes bellow:
> ...
> static void JNICALL
> callbackVMDeath(jvmtiEnv *jvmti, JNIEnv *jni)
> {
> assert(false);
> printf("vm death\n");
> }
> JNIEXPORT void JNICALL Agent_OnUnload(JavaVM *jvm)
> {
> assert(false);
> printf("unload!");
> }
> JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void
> *reserved) {
> ...
> error = jvmti->SetEventNotificationMode(JVMTI_ENABLE,JVMTI_EVENT_VM_DEATH,
> (jthread)NULL); callbacks.VMDeath = &callbackVMDeath;
> error = jvmti->SetEventCallbacks(&callbacks,(jint)sizeof(callbacks));
> ...
> }
> ...
> The program ends correctly. This is really strange. Can anyone try this
> case and explain for me?
>
> Thanks a lot.
>
> 2009-11-26
>
>
>
> johnnylj98
>
[DRLVM][JVMTI]a bug when running SpecJVM98 _201_compress
Hi all,
I'm doing some tuning work for Harmony running SpecJVM98.
I write a JVMTI agent to catch VMDeath event and do something at the end of
JVM's life, but that doesn't work(the same agent work well for hotspot).
my agent likes bellow:
...
static void JNICALL
callbackVMDeath(jvmtiEnv *jvmti, JNIEnv *jni)
{
assert(false);
printf("vm death\n");
}
JNIEXPORT void JNICALL Agent_OnUnload(JavaVM *jvm)
{
assert(false);
printf("unload!");
}
JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void *reserved)
{
...
error = jvmti->SetEventNotificationMode(JVMTI_ENABLE,JVMTI_EVENT_VM_DEATH,
(jthread)NULL);
callbacks.VMDeath = &callbackVMDeath;
error = jvmti->SetEventCallbacks(&callbacks,(jint)sizeof(callbacks));
...
}
...
The program ends correctly. This is really strange. Can anyone try this case
and explain for me?
Thanks a lot.
2009-11-26
johnnylj98
Re: Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning
For JVM performance tuning, I run Harmony as a common C application in Vtune, not as a Java application. Are you having to run Harmony in Linux? I had less experience with Vtune in Linux. But it works perfectly in Windows. Will you try running in Windows? Thanks, xiaofeng 2009/11/9 johnnylj98 : > Hi Xiao Feng, > Thanks for your help. I found Intel VTune use JVMTI to profile the > application if you specify your application as java program. So that it still > won't work in my case because I don't use the IR generated from bytecode. > But if I specify the java program as a linux excutable application, all I got > are hot modules. When I try to see the hot methods in a module, VTune > collapse. > Thanks a lot. > > 2009-11-09 > > > > johnnylj98 > > > > 发件人： Xiao-Feng Li > 发送时间： 2009-11-09 10:04:14 > 收件人： dev > 抄送： > 主题： Re: Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning > > Please build Harmony in debug mode, that will give you the symbols for > analysis. > Personally I do not see any special in using Vtune with Harmony than > with another applications. > Thanks, > xiaofeng > On Fri, Nov 6, 2009 at 2:30 PM, johnnylj98 wrote: >> Hi, Xiao-Feng Li >> >> Thanks for your help. I tried VTune according to your suggestion. I can >> trace the threads and modules in running of java, but every time I click >> hotspot tag for a specific module VTune goes out of response. >> Is there anything special I should care about when I use VTune to tune >> Harmony? >> >> Thanks a lot. >> >> >> 2009-11-06 >> >> >> >> johnnylj98 >> >> >> >> 发件人： Xiao-Feng Li >> 发送时间： 2009-11-04 21:50:54 >> 收件人： dev >> 抄送： >> 主题： Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning >> >> Intel Vtune is intensively used in my performance tuning work. >> Thanks, >> xiaofeng >> On Wed, Nov 4, 2009 at 9:44 AM, johnnylj98 wrote: >>> Thanks a lot. Perhaps we will make some LIR instrumentation to analyze the >>> run time of a method. >>> >>> >>> 2009-11-04 >>> >>> >>> >>> johnnylj98 >>> >>> >>> >>> 发件人： Alexei Fedotov >>> 发送时间： 2009-11-02 21:52:51 >>> 收件人： dev >>> 抄送： >>> 主题： Re: [drlvm]Is there any JVM profiler tool for Harmony tunning >>> >>> Hello Johny, >>> You can take a look here [1] for custom JVMTI agents. >>> [1] https://issues.apache.org/jira/browse/HARMONY-5514 >>> On Sun, Nov 1, 2009 at 7:57 AM, johnnylj98 wrote: >>>> Hi all, >>>> I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support >>>> Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? >>>> Thanks a lot. >>>> >>>> 2009-11-01 >>>> >>>> >>>> >>>> johnnylj98 >>>> >>> -- >>> With best regards / с наилучшими пожеланиями, >>> Alexei Fedotov / Алексей Федотов, >>> http://www.telecom-express.ru/ >>> http://harmony.apache.org/ >>> http://www.expressaas.com/ >>> http://openmeetings.googlecode.com/ >>> >> -- >> http://people.apache.org/~xli >> > -- > http://people.apache.org/~xli > -- http://people.apache.org/~xli
Re: Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning
Hi Xiao Feng, Thanks for your help. I found Intel VTune use JVMTI to profile the application if you specify your application as java program. So that it still won't work in my case because I don't use the IR generated from bytecode. But if I specify the java program as a linux excutable application, all I got are hot modules. When I try to see the hot methods in a module, VTune collapse. Thanks a lot. 2009-11-09 johnnylj98 发件人： Xiao-Feng Li 发送时间： 2009-11-09 10:04:14 收件人： dev 抄送： 主题： Re: Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning Please build Harmony in debug mode, that will give you the symbols for analysis. Personally I do not see any special in using Vtune with Harmony than with another applications. Thanks, xiaofeng On Fri, Nov 6, 2009 at 2:30 PM, johnnylj98 wrote: > Hi, Xiao-Feng Li > > Thanks for your help. I tried VTune according to your suggestion. I can trace > the threads and modules in running of java, but every time I click hotspot > tag for a specific module VTune goes out of response. > Is there anything special I should care about when I use VTune to tune > Harmony? > > Thanks a lot. > > > 2009-11-06 > > > > johnnylj98 > > > > 发件人： Xiao-Feng Li > 发送时间： 2009-11-04 21:50:54 > 收件人： dev > 抄送： > 主题： Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning > > Intel Vtune is intensively used in my performance tuning work. > Thanks, > xiaofeng > On Wed, Nov 4, 2009 at 9:44 AM, johnnylj98 wrote: >> Thanks a lot. Perhaps we will make some LIR instrumentation to analyze the >> run time of a method. >> >> >> 2009-11-04 >> >> >> >> johnnylj98 >> >> >> >> 发件人： Alexei Fedotov >> 发送时间： 2009-11-02 21:52:51 >> 收件人： dev >> 抄送： >> 主题： Re: [drlvm]Is there any JVM profiler tool for Harmony tunning >> >> Hello Johny, >> You can take a look here [1] for custom JVMTI agents. >> [1] https://issues.apache.org/jira/browse/HARMONY-5514 >> On Sun, Nov 1, 2009 at 7:57 AM, johnnylj98 wrote: >>> Hi all, >>> I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support >>> Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? >>> Thanks a lot. >>> >>> 2009-11-01 >>> >>> >>> >>> johnnylj98 >>> >> -- >> With best regards / с наилучшими пожеланиями, >> Alexei Fedotov / Алексей Федотов, >> http://www.telecom-express.ru/ >> http://harmony.apache.org/ >> http://www.expressaas.com/ >> http://openmeetings.googlecode.com/ >> > -- > http://people.apache.org/~xli > -- http://people.apache.org/~xli
Re: Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning
Please build Harmony in debug mode, that will give you the symbols for analysis. Personally I do not see any special in using Vtune with Harmony than with another applications. Thanks, xiaofeng On Fri, Nov 6, 2009 at 2:30 PM, johnnylj98 wrote: > Hi, Xiao-Feng Li > > Thanks for your help. I tried VTune according to your suggestion. I can trace > the threads and modules in running of java, but every time I click hotspot > tag for a specific module VTune goes out of response. > Is there anything special I should care about when I use VTune to tune > Harmony? > > Thanks a lot. > > > 2009-11-06 > > > > johnnylj98 > > > > 发件人： Xiao-Feng Li > 发送时间： 2009-11-04 21:50:54 > 收件人： dev > 抄送： > 主题： Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning > > Intel Vtune is intensively used in my performance tuning work. > Thanks, > xiaofeng > On Wed, Nov 4, 2009 at 9:44 AM, johnnylj98 wrote: >> Thanks a lot. Perhaps we will make some LIR instrumentation to analyze the >> run time of a method. >> >> >> 2009-11-04 >> >> >> >> johnnylj98 >> >> >> >> 发件人： Alexei Fedotov >> 发送时间： 2009-11-02 21:52:51 >> 收件人： dev >> 抄送： >> 主题： Re: [drlvm]Is there any JVM profiler tool for Harmony tunning >> >> Hello Johny, >> You can take a look here [1] for custom JVMTI agents. >> [1] https://issues.apache.org/jira/browse/HARMONY-5514 >> On Sun, Nov 1, 2009 at 7:57 AM, johnnylj98 wrote: >>> Hi all, >>> I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support >>> Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? >>> Thanks a lot. >>> >>> 2009-11-01 >>> >>> >>> >>> johnnylj98 >>> >> -- >> With best regards / с наилучшими пожеланиями, >> Alexei Fedotov / Алексей Федотов, >> http://www.telecom-express.ru/ >> http://harmony.apache.org/ >> http://www.expressaas.com/ >> http://openmeetings.googlecode.com/ >> > -- > http://people.apache.org/~xli > -- http://people.apache.org/~xli
Re: Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning
Hi, Xiao-Feng Li Thanks for your help. I tried VTune according to your suggestion. I can trace the threads and modules in running of java, but every time I click hotspot tag for a specific module VTune goes out of response. Is there anything special I should care about when I use VTune to tune Harmony? Thanks a lot. 2009-11-06 johnnylj98 发件人： Xiao-Feng Li 发送时间： 2009-11-04 21:50:54 收件人： dev 抄送： 主题： Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning Intel Vtune is intensively used in my performance tuning work. Thanks, xiaofeng On Wed, Nov 4, 2009 at 9:44 AM, johnnylj98 wrote: > Thanks a lot. Perhaps we will make some LIR instrumentation to analyze the > run time of a method. > > > 2009-11-04 > > > > johnnylj98 > > > > 发件人： Alexei Fedotov > 发送时间： 2009-11-02 21:52:51 > 收件人： dev > 抄送： > 主题： Re: [drlvm]Is there any JVM profiler tool for Harmony tunning > > Hello Johny, > You can take a look here [1] for custom JVMTI agents. > [1] https://issues.apache.org/jira/browse/HARMONY-5514 > On Sun, Nov 1, 2009 at 7:57 AM, johnnylj98 wrote: >> Hi all, >> I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support >> Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? >> Thanks a lot. >> >> 2009-11-01 >> >> >> >> johnnylj98 >> > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://www.telecom-express.ru/ > http://harmony.apache.org/ > http://www.expressaas.com/ > http://openmeetings.googlecode.com/ > -- http://people.apache.org/~xli
Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning
Intel Vtune is intensively used in my performance tuning work. Thanks, xiaofeng On Wed, Nov 4, 2009 at 9:44 AM, johnnylj98 wrote: > Thanks a lot. Perhaps we will make some LIR instrumentation to analyze the > run time of a method. > > > 2009-11-04 > > > > johnnylj98 > > > > 发件人： Alexei Fedotov > 发送时间： 2009-11-02 21:52:51 > 收件人： dev > 抄送： > 主题： Re: [drlvm]Is there any JVM profiler tool for Harmony tunning > > Hello Johny, > You can take a look here [1] for custom JVMTI agents. > [1] https://issues.apache.org/jira/browse/HARMONY-5514 > On Sun, Nov 1, 2009 at 7:57 AM, johnnylj98 wrote: >> Hi all, >> I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support >> Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? >> Thanks a lot. >> >> 2009-11-01 >> >> >> >> johnnylj98 >> > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://www.telecom-express.ru/ > http://harmony.apache.org/ > http://www.expressaas.com/ > http://openmeetings.googlecode.com/ > -- http://people.apache.org/~xli
Re: Re: [drlvm]Is there any JVM profiler tool for Harmony tunning
Thanks a lot. Perhaps we will make some LIR instrumentation to analyze the run time of a method. 2009-11-04 johnnylj98 发件人： Alexei Fedotov 发送时间： 2009-11-02 21:52:51 收件人： dev 抄送： 主题： Re: [drlvm]Is there any JVM profiler tool for Harmony tunning Hello Johny, You can take a look here [1] for custom JVMTI agents. [1] https://issues.apache.org/jira/browse/HARMONY-5514 On Sun, Nov 1, 2009 at 7:57 AM, johnnylj98 wrote: > Hi all, > I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support > Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? > Thanks a lot. > > 2009-11-01 > > > > johnnylj98 > -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://www.telecom-express.ru/ http://harmony.apache.org/ http://www.expressaas.com/ http://openmeetings.googlecode.com/
Re: Re: [drlvm][jitrino]Is this a bug in Ia32WebMaker action?
Thanks a lot. The LIR I use is not generated by Harmony so i can not provide a
java test case. I comment out some code in phase3() and it seems works.
2009-11-04
johnnylj98
发件人： Alexei Fedotov
发送时间： 2009-11-02 22:02:16
收件人： dev
抄送：
主题： Re: [drlvm][jitrino]Is this a bug in Ia32WebMaker action?
Hello,
Is it possible to create a java test case for this IR?
Thanks!
On Thu, Oct 15, 2009 at 5:07 AM, johnnylj98 wrote:
> Hi all,
>
> I met an issue in Ia32WebMaker action recently.
>
> In Ia32WebMaker action, function phase1() first generated array opndxs like
> this:
>
> void WebMaker::phase1()
> {
>opndxs.resize(opandcount);
>for (unsigned i = 0; i != opandcount; ++i)
>{
>Opndx* opndxp = 0;
>if (!irManager->getOpnd(i)->hasAssignedPhysicalLocation())
>opndxp = new (mm) Opndx(mm);
>opndxs[i] = opndxp;
>}
> ..
> So all the Opnd in IR are registed in array opndxp
>
> And in function phase3(), there are codes to splitOpnd and replaceOpnd in the
> same inst, like this:
>
>if (opdefp->globid == -1)
>{// local operand
>
>if (isdef)
>{
>++opndxp->webscount;
>if (opndxp->webscount > 1)
>{
>opndxp->newopndp = splitOpnd(opndp);
>DBGOUT("**new local web found " << *opndp
> << " -> " << *opndxp->newopndp << endl;)
>}
>}
>if (opndxp->webscount > 1 &&
> opdefp->defp->getNode() == nodep)
>{
>instp->replaceOpnd(opndp, opndxp->newopndp,
> isdef ? Inst::OpndRole_AllDefs : Inst::OpndRole_AllUses);
>DBGOUT(" replace B#" <<
> instp->getBasicBlock()->getId() << " " << *instp << endl;)
>}
> ...
>
> So the question is, if we meet an IR like
>
> I6: CALL t14[t12]:ptr:uintptr (AU:s7:cls:Hello,s7:cls:Hello) [bcmap:unknown]
> (from source code like hello.fun(hello) )
>
> WebMaker decides to replace the s7 with new generated s19 at the second
> Opnd(second iteration of I6) of I6, but the call of instp->replaceOpnd() will
> also change the third Opnd of I6 to s19. In the next iteration(thrid
> iteration of I6) of phase3(), the code
>
> Opndx* opndxp = opndxs.at(opndp->getId());
>
> will throw vector _range_out error because array opndxs has not been updated
> with new generated Opnd s19.
>
> So is this really a bug or I misunderstand some parts of the code?
>
> Thanks a lot!
>
> 2009-10-15
>
>
>
> johnnylj98
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: [drlvm][jitrino]Is this a bug in Ia32WebMaker action?
Hello,
Is it possible to create a java test case for this IR?
Thanks!
On Thu, Oct 15, 2009 at 5:07 AM, johnnylj98 wrote:
> Hi all,
>
> I met an issue in Ia32WebMaker action recently.
>
> In Ia32WebMaker action, function phase1() first generated array opndxs like
> this:
>
> void WebMaker::phase1()
> {
> opndxs.resize(opandcount);
> for (unsigned i = 0; i != opandcount; ++i)
> {
> Opndx* opndxp = 0;
> if (!irManager->getOpnd(i)->hasAssignedPhysicalLocation())
> opndxp = new (mm) Opndx(mm);
> opndxs[i] = opndxp;
> }
> ..
> So all the Opnd in IR are registed in array opndxp
>
> And in function phase3(), there are codes to splitOpnd and replaceOpnd in the
> same inst, like this:
>
> if (opdefp->globid == -1)
> {// local operand
>
> if (isdef)
> {
> ++opndxp->webscount;
> if (opndxp->webscount > 1)
> {
> opndxp->newopndp = splitOpnd(opndp);
> DBGOUT("**new local web found " << *opndp
> << " -> " << *opndxp->newopndp << endl;)
> }
> }
> if (opndxp->webscount > 1 &&
> opdefp->defp->getNode() == nodep)
> {
> instp->replaceOpnd(opndp, opndxp->newopndp,
> isdef ? Inst::OpndRole_AllDefs : Inst::OpndRole_AllUses);
> DBGOUT(" replace B#" <<
> instp->getBasicBlock()->getId() << " " << *instp << endl;)
> }
> ...
>
> So the question is, if we meet an IR like
>
> I6: CALL t14[t12]:ptr:uintptr (AU:s7:cls:Hello,s7:cls:Hello) [bcmap:unknown]
> (from source code like hello.fun(hello) )
>
> WebMaker decides to replace the s7 with new generated s19 at the second
> Opnd(second iteration of I6) of I6, but the call of instp->replaceOpnd() will
> also change the third Opnd of I6 to s19. In the next iteration(thrid
> iteration of I6) of phase3(), the code
>
> Opndx* opndxp = opndxs.at(opndp->getId());
>
> will throw vector _range_out error because array opndxs has not been updated
> with new generated Opnd s19.
>
> So is this really a bug or I misunderstand some parts of the code?
>
> Thanks a lot!
>
> 2009-10-15
>
>
>
> johnnylj98
>
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://www.telecom-express.ru/
http://harmony.apache.org/
http://www.expressaas.com/
http://openmeetings.googlecode.com/
Re: [drlvm]Is there any JVM profiler tool for Harmony tunning
Hello Johny, You can take a look here [1] for custom JVMTI agents. [1] https://issues.apache.org/jira/browse/HARMONY-5514 On Sun, Nov 1, 2009 at 7:57 AM, johnnylj98 wrote: > Hi all, > I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support > Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? > Thanks a lot. > > 2009-11-01 > > > > johnnylj98 > -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://www.telecom-express.ru/ http://harmony.apache.org/ http://www.expressaas.com/ http://openmeetings.googlecode.com/
[drlvm]Is there any JVM profiler tool for Harmony tunning
Hi all, I'm tunning a benchmark for Harmony but Jprofiler seems doesn't support Harmony JRE. So is there some JVM profiler tool available for Harmony JRE? Thanks a lot. 2009-11-01 johnnylj98
Re: [drlvm][JET] problem in pass arguments in instrumentation
hi all
I add a dummy parameter before m_method,
such as gen_call_vm(cs_put_sfield, rt_helper_putstatic,0, klass,
fieldOp.fld,NULL, m_method, m_pc);
instead of the original
gen_call_vm(cs_put_sfield, rt_helper_putstatic,0, klass,
fieldOp.fld,m_method, m_pc);
then, I got the right method name in the runtime routine to recode the access
history.
However, i donot known the reason. Who can explain?
-Joey
>hi all
> I want to instrument the static field access, and coding at
> jet/cg_fld_arr.cpp: do_field_op()
>a code sample:
> if(fieldOp.isStatic()) {
> Class_Handle klass = field_get_class(fieldOp.fld);
> if(fieldOp.isPut()) { //putstatic
> SYNC_FIRST(static const CallSig
> cs_put_sfield(CCONV_HELPERS,jvoid,jobj, jobj, jobj, iplatf));
> gen_call_vm(cs_put_sfield,
> rt_helper_putstatic,0, klass, fieldOp.fld , m_method, m_pc);
> }
>
>=== I pass four parameters, in the runtime routine.
>but in the jit_runtime_support.cxx, when handle the routine, I can not get the
>method name, while the other three
>parameters is no problem.
>any problem in the coding of pass parameters? who can help me, thanks for your
>help!
>
>-Joey
>
>
= = = = = = = = = = = = = = = = = = = =
Cheers!
keqiaoyang
[email protected]
2009-10-29
===
Room 108, Software Building, Software School, Fudan University,
825 Zhangheng Road, Shanghai, 201203,China
Re: [build] build drlvm error on SUSE x86_64
chunrong lai wrote: Is your Gcc 32 bits or 64 bits? According to the error message the drlvm thinks that it is built in a 32bits platform. On Thu, Oct 29, 2009 at 1:28 PM, Regis wrote: Hi, Today, I'm trying to build drlvm on SUSE x86_64 but got a error: drlvm-echo: [echo] DRLVM build Configuration: [echo] Hosting Java = 1.6.0 (IBM Corporation) [echo]os = linux [echo] arch = x86 [echo] hy.cpp.compiler = gcc [echo] cfg = debug [echo] svn revision = 830845 [echo] hy.local.zlib = false [echo] common resources = /home/ruizhi/common_resources [echo] HDK root = /home/ruizhi/working_classlib/deploy [echo]target dir = /home/ruizhi/working_vm/build/linux_x86_gcc_debug/deploy -auto-fetch: setup: encoder: -plugin-cpptasks: [echo] Checking for /home/ruizhi/common_resources/depends/jars/cpptasks-1.0b4/cpptasks.jar setup-native-build: init-compression-mode: -common-vm: build: [echo] ## Building 'encoder' [cc] Starting dependency analysis for 3 files. [cc] 3 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 1 total files to be compiled. [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_ip(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:216: error: cast from ‘void*’ to ‘U_32’ loses precision [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_sp(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:218: error: cast from ‘void*’ to ‘U_32’ loses precision BUILD FAILED /home/ruizhi/working_vm/build.xml:118: The following error occurred while executing this line: /home/ruizhi/working_vm/make/vm/encoder.xml:32: The following error occurred while executing this line: /home/ruizhi/working_vm/make/build-native.xml:163: gcc failed with return code 1 Our Hudson build passed normal, so it should work fine. Anyone can help to point out what's wrong here? Thanks. cat /etc/issue Welcome to SUSE Linux Enterprise Server 10 SP1 (x86_64) - Kernel \r (\l). -- Best Regards, Regis. It works when I changed to use 64-bits JRE. Thanks. -- Best Regards, Regis.
[drlvm][JET] problem in pass arguments in instrumentation
hi all
I want to instrument the static field access, and coding at
jet/cg_fld_arr.cpp: do_field_op()
a code sample:
if(fieldOp.isStatic()) {
Class_Handle klass = field_get_class(fieldOp.fld);
if(fieldOp.isPut()) { //putstatic
SYNC_FIRST(static const CallSig
cs_put_sfield(CCONV_HELPERS,jvoid,jobj, jobj, jobj, iplatf));
gen_call_vm(cs_put_sfield,
rt_helper_putstatic,0, klass, fieldOp.fld , m_method, m_pc);
}
=== I pass four parameters, in the runtime routine.
but in the jit_runtime_support.cxx, when handle the routine, I can not get the
method name, while the other three
parameters is no problem.
any problem in the coding of pass parameters? who can help me, thanks for your
help!
-Joey
Re: [build] build drlvm error on SUSE x86_64
Regis wrote: chunrong lai wrote: Is your Gcc 32 bits or 64 bits? It's 64 bits file /usr/bin/gcc /usr/bin/gcc: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, stripped According to the error message the drlvm thinks that it is built in a 32bits platform. I tried: ant -Dhy.arch=x86_64 the error is similar: drlvm-echo: [echo] DRLVM build Configuration: [echo] Hosting Java = 1.6.0 (IBM Corporation) [echo]os = linux [echo] arch = x86_64 seems ant think it's on x86_64 now [echo] hy.cpp.compiler = gcc [echo] cfg = debug [echo] svn revision = 830845 [echo] hy.local.zlib = false [echo] common resources = /home/ruizhi/common_resources [echo] HDK root = /home/ruizhi/working_classlib/deploy [echo]target dir = /home/ruizhi/working_vm/build/linux_x86_64_gcc_debug/deploy -auto-fetch: setup: encoder: -plugin-cpptasks: [echo] Checking for /home/ruizhi/common_resources/depends/jars/cpptasks-1.0b4/cpptasks.jar setup-native-build: init-compression-mode: -common-vm: build: [echo] ## Building 'encoder' [cc] Starting dependency analysis for 3 files. [cc] 3 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 1 total files to be compiled. [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_ip(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:216: error: cast from ‘void*’ to ‘U_32’ loses precision [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_sp(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:218: error: cast from ‘void*’ to ‘U_32’ loses precision platform_types.h:218 is not in "#ifdef _EM64T_" block, so gcc still doesn't think it's build on b4 bits. Is there any ways to specific it? BUILD FAILED /home/ruizhi/working_vm/build.xml:118: The following error occurred while executing this line: /home/ruizhi/working_vm/make/vm/encoder.xml:32: The following error occurred while executing this line: /home/ruizhi/working_vm/make/build-native.xml:163: gcc failed with return code 1 -- Best Regards, Regis.
Re: [build] build drlvm error on SUSE x86_64
chunrong lai wrote: Is your Gcc 32 bits or 64 bits? It's 64 bits file /usr/bin/gcc /usr/bin/gcc: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, stripped According to the error message the drlvm thinks that it is built in a 32bits platform. I tried: ant -Dhy.arch=x86_64 the error is similar: drlvm-echo: [echo] DRLVM build Configuration: [echo] Hosting Java = 1.6.0 (IBM Corporation) [echo]os = linux [echo] arch = x86_64 [echo] hy.cpp.compiler = gcc [echo] cfg = debug [echo] svn revision = 830845 [echo] hy.local.zlib = false [echo] common resources = /home/ruizhi/common_resources [echo] HDK root = /home/ruizhi/working_classlib/deploy [echo]target dir = /home/ruizhi/working_vm/build/linux_x86_64_gcc_debug/deploy -auto-fetch: setup: encoder: -plugin-cpptasks: [echo] Checking for /home/ruizhi/common_resources/depends/jars/cpptasks-1.0b4/cpptasks.jar setup-native-build: init-compression-mode: -common-vm: build: [echo] ## Building 'encoder' [cc] Starting dependency analysis for 3 files. [cc] 3 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 1 total files to be compiled. [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_ip(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:216: error: cast from ‘void*’ to ‘U_32’ loses precision [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_sp(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:218: error: cast from ‘void*’ to ‘U_32’ loses precision BUILD FAILED /home/ruizhi/working_vm/build.xml:118: The following error occurred while executing this line: /home/ruizhi/working_vm/make/vm/encoder.xml:32: The following error occurred while executing this line: /home/ruizhi/working_vm/make/build-native.xml:163: gcc failed with return code 1 -- Best Regards, Regis.
Re: [build] build drlvm error on SUSE x86_64
Is your Gcc 32 bits or 64 bits? According to the error message the drlvm thinks that it is built in a 32bits platform. On Thu, Oct 29, 2009 at 1:28 PM, Regis wrote: > Hi, > > Today, I'm trying to build drlvm on SUSE x86_64 but got a error: > > drlvm-echo: > [echo] DRLVM build Configuration: > [echo] Hosting Java = 1.6.0 (IBM Corporation) > [echo]os = linux > [echo] arch = x86 > [echo] hy.cpp.compiler = gcc > [echo] cfg = debug > [echo] svn revision = 830845 > [echo] hy.local.zlib = false > [echo] common resources = /home/ruizhi/common_resources > [echo] HDK root = /home/ruizhi/working_classlib/deploy > [echo]target dir = > /home/ruizhi/working_vm/build/linux_x86_gcc_debug/deploy > > -auto-fetch: > > setup: > > encoder: > > -plugin-cpptasks: > [echo] Checking for > /home/ruizhi/common_resources/depends/jars/cpptasks-1.0b4/cpptasks.jar > > setup-native-build: > > init-compression-mode: > > -common-vm: > > build: > [echo] ## Building 'encoder' > [cc] Starting dependency analysis for 3 files. > [cc] 3 files are up to date. > [cc] 0 files to be recompiled from dependency analysis. > [cc] 1 total files to be compiled. > [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In > member function ‘void Registers::set_ip(void*)’: > [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:216: > error: cast from ‘void*’ to ‘U_32’ loses precision > [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In > member function ‘void Registers::set_sp(void*)’: > [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:218: > error: cast from ‘void*’ to ‘U_32’ loses precision > > BUILD FAILED > /home/ruizhi/working_vm/build.xml:118: The following error occurred while > executing this line: > /home/ruizhi/working_vm/make/vm/encoder.xml:32: The following error > occurred while executing this line: > /home/ruizhi/working_vm/make/build-native.xml:163: gcc failed with return > code 1 > > Our Hudson build passed normal, so it should work fine. Anyone can help to > point out what's wrong here? Thanks. > > cat /etc/issue > > Welcome to SUSE Linux Enterprise Server 10 SP1 (x86_64) - Kernel \r (\l). > > > -- > Best Regards, > Regis. >
[build] build drlvm error on SUSE x86_64
Hi, Today, I'm trying to build drlvm on SUSE x86_64 but got a error: drlvm-echo: [echo] DRLVM build Configuration: [echo] Hosting Java = 1.6.0 (IBM Corporation) [echo]os = linux [echo] arch = x86 [echo] hy.cpp.compiler = gcc [echo] cfg = debug [echo] svn revision = 830845 [echo] hy.local.zlib = false [echo] common resources = /home/ruizhi/common_resources [echo] HDK root = /home/ruizhi/working_classlib/deploy [echo]target dir = /home/ruizhi/working_vm/build/linux_x86_gcc_debug/deploy -auto-fetch: setup: encoder: -plugin-cpptasks: [echo] Checking for /home/ruizhi/common_resources/depends/jars/cpptasks-1.0b4/cpptasks.jar setup-native-build: init-compression-mode: -common-vm: build: [echo] ## Building 'encoder' [cc] Starting dependency analysis for 3 files. [cc] 3 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 1 total files to be compiled. [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_ip(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:216: error: cast from ‘void*’ to ‘U_32’ loses precision [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h: In member function ‘void Registers::set_sp(void*)’: [cc] /home/ruizhi/working_vm/vm/include/open/platform_types.h:218: error: cast from ‘void*’ to ‘U_32’ loses precision BUILD FAILED /home/ruizhi/working_vm/build.xml:118: The following error occurred while executing this line: /home/ruizhi/working_vm/make/vm/encoder.xml:32: The following error occurred while executing this line: /home/ruizhi/working_vm/make/build-native.xml:163: gcc failed with return code 1 Our Hudson build passed normal, so it should work fine. Anyone can help to point out what's wrong here? Thanks. cat /etc/issue Welcome to SUSE Linux Enterprise Server 10 SP1 (x86_64) - Kernel \r (\l). -- Best Regards, Regis.
[drlvm][jitrino]Is this a bug in Ia32WebMaker action?
Hi all,
I met an issue in Ia32WebMaker action recently.
In Ia32WebMaker action, function phase1() first generated array opndxs like
this:
void WebMaker::phase1()
{
opndxs.resize(opandcount);
for (unsigned i = 0; i != opandcount; ++i)
{
Opndx* opndxp = 0;
if (!irManager->getOpnd(i)->hasAssignedPhysicalLocation())
opndxp = new (mm) Opndx(mm);
opndxs[i] = opndxp;
}
..
So all the Opnd in IR are registed in array opndxp
And in function phase3(), there are codes to splitOpnd and replaceOpnd in the
same inst, like this:
if (opdefp->globid == -1)
{// local operand
if (isdef)
{
++opndxp->webscount;
if (opndxp->webscount > 1)
{
opndxp->newopndp = splitOpnd(opndp);
DBGOUT("**new local web found " << *opndp
<< " -> " << *opndxp->newopndp << endl;)
}
}
if (opndxp->webscount > 1 &&
opdefp->defp->getNode() == nodep)
{
instp->replaceOpnd(opndp, opndxp->newopndp,
isdef ? Inst::OpndRole_AllDefs : Inst::OpndRole_AllUses);
DBGOUT(" replace B#" <<
instp->getBasicBlock()->getId() << " " << *instp << endl;)
}
...
So the question is, if we meet an IR like
I6: CALL t14[t12]:ptr:uintptr (AU:s7:cls:Hello,s7:cls:Hello) [bcmap:unknown]
(from source code like hello.fun(hello) )
WebMaker decides to replace the s7 with new generated s19 at the second
Opnd(second iteration of I6) of I6, but the call of instp->replaceOpnd() will
also change the third Opnd of I6 to s19. In the next iteration(thrid iteration
of I6) of phase3(), the code
Opndx* opndxp = opndxs.at(opndp->getId());
will throw vector _range_out error because array opndxs has not been updated
with new generated Opnd s19.
So is this really a bug or I misunderstand some parts of the code?
Thanks a lot!
2009-10-15
johnnylj98
Re: [drlvm] Loading 50:0 format class files
Mikhail Loenko wrote:
Hi!
If you are talking about this peace of code:
#ifndef _NDEBUG
vf_recompute_stackmaptable(method, &context6.substitution,
error, classwide.class_constraints);
result = context6.verify_method(method);
if (result != VF_OK) {
vf_create_error_message(method, context6, error);
}
tc_free(context6.substitution);
context6.substitution = NULL;
#endif
Yes, that's the piece of code.
then it should not be executed. it was written for debugging purposes
when I developed recompute stack map functionality.
(recompute stack map functionality populates modified on the fly class
file with correct stack map attributes)
This peace of code fails when original class file has 6.0 version
while it can't be verified with Java6 rules.
Just comment it out or even remove it.
Brilliant, thanks Mikhail! Ill remove that block altogether.
Regards,
Oliver
Thanks,
Mikhail
2009/9/4 Oliver Deakin :
Alexey Varlamov wrote:
The changes that went into JSR202 include:
- split verifier support
- increase various size limits
- adding support for class literals
- minor changes to support Java language changes
I'm assuming that the problem in DRLVM is the loading on class literals.
Actually the class literals were incorporated in Java 5 (v49.0), as
well as other minor features for language support. AFAIK there are no
Java language changes between Java 5 and 6.
DRLVM does support these features, so the evil should be somewhere else.
Hi Alexey,
I have replied about this issue in another part of this thread [1]. It seems
there is a problem with some code intended for debug in the verifier. After
the initial java 6 method verify, the debug code then tries to recompute the
stack map table (which only seems to include Java 5 references oddly) and
then verify the method again, and this is where we fail. Without the debug
code in place the verification completes successfully.
Any ideas why the failure is occurring or why we would want to do the second
verify in debug mode after recomputing the stack map table?
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%[email protected]%3e
[snip]
I'm happy to keep testing, and if we can make progress quickly then
let's press ahead, but otherwise let's open all the code and give the
6.0 stream a bit more attention before attempting the 6.0M1 again.
Right decision is already taken ;)
--
Regards,
Alexey
Regards,
Tim
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Loading 50:0 format class files
Hi!
If you are talking about this peace of code:
#ifndef _NDEBUG
vf_recompute_stackmaptable(method, &context6.substitution,
error, classwide.class_constraints);
result = context6.verify_method(method);
if (result != VF_OK) {
vf_create_error_message(method, context6, error);
}
tc_free(context6.substitution);
context6.substitution = NULL;
#endif
then it should not be executed. it was written for debugging purposes
when I developed recompute stack map functionality.
(recompute stack map functionality populates modified on the fly class
file with correct stack map attributes)
This peace of code fails when original class file has 6.0 version
while it can't be verified with Java6 rules.
Just comment it out or even remove it.
Thanks,
Mikhail
2009/9/4 Oliver Deakin :
> Alexey Varlamov wrote:
>>>
>>> The changes that went into JSR202 include:
>>> - split verifier support
>>> - increase various size limits
>>> - adding support for class literals
>>> - minor changes to support Java language changes
>>>
>>> I'm assuming that the problem in DRLVM is the loading on class literals.
>>>
>>
>> Actually the class literals were incorporated in Java 5 (v49.0), as
>> well as other minor features for language support. AFAIK there are no
>> Java language changes between Java 5 and 6.
>> DRLVM does support these features, so the evil should be somewhere else.
>>
>
> Hi Alexey,
>
> I have replied about this issue in another part of this thread [1]. It seems
> there is a problem with some code intended for debug in the verifier. After
> the initial java 6 method verify, the debug code then tries to recompute the
> stack map table (which only seems to include Java 5 references oddly) and
> then verify the method again, and this is where we fail. Without the debug
> code in place the verification completes successfully.
>
> Any ideas why the failure is occurring or why we would want to do the second
> verify in debug mode after recomputing the stack map table?
>
> Regards,
> Oliver
>
> [1]
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%[email protected]%3e
>
>> [snip]
>>
>>>
>>> I'm happy to keep testing, and if we can make progress quickly then
>>> let's press ahead, but otherwise let's open all the code and give the
>>> 6.0 stream a bit more attention before attempting the 6.0M1 again.
>>>
>>
>> Right decision is already taken ;)
>>
>> --
>> Regards,
>> Alexey
>>
>>
>>>
>>> Regards,
>>> Tim
>>>
>>>
>>>
>>
>>
>
> --
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>
Re: [drlvm] Loading 50:0 format class files
Alexey Varlamov wrote: The changes that went into JSR202 include: - split verifier support - increase various size limits - adding support for class literals - minor changes to support Java language changes I'm assuming that the problem in DRLVM is the loading on class literals. Actually the class literals were incorporated in Java 5 (v49.0), as well as other minor features for language support. AFAIK there are no Java language changes between Java 5 and 6. DRLVM does support these features, so the evil should be somewhere else. Hi Alexey, I have replied about this issue in another part of this thread [1]. It seems there is a problem with some code intended for debug in the verifier. After the initial java 6 method verify, the debug code then tries to recompute the stack map table (which only seems to include Java 5 references oddly) and then verify the method again, and this is where we fail. Without the debug code in place the verification completes successfully. Any ideas why the failure is occurring or why we would want to do the second verify in debug mode after recomputing the stack map table? Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%[email protected]%3e [snip] I'm happy to keep testing, and if we can make progress quickly then let's press ahead, but otherwise let's open all the code and give the 6.0 stream a bit more attention before attempting the 6.0M1 again. Right decision is already taken ;) -- Regards, Alexey Regards, Tim -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Loading 50:0 format class files (was: Re: [vote] Declare the signed source for r809832 as 6.0 Milestone 1)
> The changes that went into JSR202 include: > - split verifier support > - increase various size limits > - adding support for class literals > - minor changes to support Java language changes > > I'm assuming that the problem in DRLVM is the loading on class literals. Actually the class literals were incorporated in Java 5 (v49.0), as well as other minor features for language support. AFAIK there are no Java language changes between Java 5 and 6. DRLVM does support these features, so the evil should be somewhere else. [snip] > I'm happy to keep testing, and if we can make progress quickly then > let's press ahead, but otherwise let's open all the code and give the > 6.0 stream a bit more attention before attempting the 6.0M1 again. Right decision is already taken ;) -- Regards, Alexey > > Regards, > Tim > >
[drlvm] Loading 50:0 format class files (was: Re: [vote] Declare the signed source for r809832 as 6.0 Milestone 1)
On 02/Sep/2009 22:46, Mark Hindess wrote: > In message <[email protected]>, Tim Ellison writes: >> On 02/Sep/2009 18:28, Mark Hindess wrote: >>> In message <[email protected]>, Tim Ellison writes: >>>> On 01/Sep/2009 08:30, Mark Hindess wrote: >>>>> There was some agreement that we should create a 6.0 milestone >>>>> so I'm going to begin a vote. If anyone feels that three days >>>>> isn't enough time to complete testing then please just ask for >>>>> more time. >>>>> >>>>> I have created a signed source archive for this revision and made >>>>> it available at: >>>>> >>>>> http://people.apache.org/~hindessm/6.0m1/ >>>>> >>>>> Please test these artifacts and then vote for declaring these >>>>> source archives as 6.0 milestone 1, and opening up the remaining >>>>> frozen code trees for general development once again. >>>>> >>>>> This vote will be open for at least 3 days, or until all binding >>>>> votes have been cast (if earlier). >>>>> >>>>> If the vote is successful, binary builds from that level will be >>>>> made available on the download page. >>>> How is this going to work if the DRLVM cannot load class files >>>> compiled for 1.6 ?! See HARMONY-6317 >>> It will load some class files compiled for 1.6. For instance, if >>> I compile classlib with hy.javac.{source,target}=1.6 then it runs >>> eclipse. >> I was referring to the ability for the candidate to run applications >> compiled with target 1.6 (not the classlib compiled with target 1.6). > > I know but loading classes from a classlib compiled as 1.6 level class files > is a good test that using classes without 1.6 features are generally okay. I see, though classlib compiled as a 1.6 format source/target may also exhibit the same problems. The changes that went into JSR202 include: - split verifier support - increase various size limits - adding support for class literals - minor changes to support Java language changes I'm assuming that the problem in DRLVM is the loading on class literals. > As I wrote later, SwingSet2.jar works for me - I've tried several version > all with 1.6 level class files - on linux/x86. The first thing I tried was java -version (which reported the wrong version number) and the next was SwingSet2 from Sun JDK 6.0b16 which failed to load classes -- so it was not a great start! The SwingSet2 shipped with IBM JDKs works ok, so I assume that they compile it differently. >> AFAIK Eclipse doesn't have any 1.6 level class files. > > Of course. > >>> Do you think we should hold off releasing any 6.0 milestones >>> until the VM supports all 1.6 features? If no one is planning to >>> implement these we might not make any 6.0 releases for a rather long >>> time and so the 6.0 classlib code wont get released/exercised? >> No, I understand this is an early driver, so if there are some >> limitations then putting them into the README is fine. However, if we >> cannot run any 1.6 class files then that is a show stopper IMHO. > > Sorry, it wasn't clear from the JIRA you pointed to that you couldn't > run *any* 1.6 class files, I assumed the problematic classes used 1.6 > specific features. I can run some class files compiled with the 1.6 compiler. I haven't checked the class file format but assume that they are Major 50 Minor 0 format, in which case as I said above I think we should understand the limitation we have got and mention it in the readme. >> I also think we should fix HARMONY-6330, even in the first milestone, >> as that is just silly. > > Well, please vote -1 and save anyone wasting more time testing. ;-) Ok. >>> I'm fine if we decide not to make a release now but we should decide >>> exactly what the "must have" features are for milestone 1. >> Agreed. But I think we need to make a quick decision about whether >> the relevant branches need to remain frozen or not. > > If windows is as bad as you say then I'd be inclined to delay 6.0M1 > until after 5.0M12 to give us time to fix it. > > And re-open the entire code base ASAP. I'm happy to keep testing, and if we can make progress quickly then let's press ahead, but otherwise let's open all the code and give the 6.0 stream a bit more attention before attempting the 6.0M1 again. Regards, Tim
Re: [drlvm] Thread library function table added
Mark Hindess wrote: I think we should do this. However, this will "break" developers using the IBM VME. Perhaps we could do: Index: make/properties.xml === --- make/properties.xml (revision 805151) +++ make/properties.xml (working copy) @@ -286,7 +286,10 @@ - + + + + to mitigate this slightly? It's not very pretty, but it would at least automate this step for the current VME until it is updated. It would still be an issue if users take a first time checkout of the class libraries, build them and then overlay the IBM VME, as the j9vm23 library would not be present at build time, but at least it would save us specifying the hy.no.thr flag for subsequent builds. It also needs to look for j9vm23.dll on Windows, having an condition for either library should do the trick. Regards, Oliver Regards, Mark. In message <[email protected]>, Oliver Deakin writes: Carrying on from this discussion, I'd like to make hy.no.thr=true the default setting and stop building the classlib thread library in the federated build. Please let me know if there are any objections/comments on this, otherwise I will make the change after M11 is published. Regards, Oliver Oliver Deakin wrote: Mark Hindess wrote: In message <[email protected]>, Sean Qiu writes: +1 for both of your proposal, it sounds reasonable and cool. Thanks, Oli. I am in favour of removing the option completely and removing the classlib thread code. Of course, this breaks the IBM VME so perhaps we can leave it in place - but change the default? - until a new IBM VME is available? Yes, I think we should switch the default to hy.no.thr=true for a transition period. There is no harm in keeping the classlib thread code present for a while, but I think the eventual goal should be to delete it from the repo. One question here, what do you mean remove the code? svn del? What about we "svn move" it to some other place, such as https://svn.apache.org/repos/asf/harmony/enhanced/legacy Well, we already have: https://svn.apache.org/repos/asf/harmony/enhanced/classlib/archive but I think "svn delete" is fine since you can always checkout earlier revisions if you need to revisit the code. Agreed. Regards, Oliver Regards, Mark. 2009/8/11 Oliver Deakin : Hi all, I have added an implementation of the thread library function table for DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag specified on the Ant command line. This means we no longer need to build th e classlib thread library in the federated build, and we also no longer need to copy the DRLVM hythr library into jre/bin (although I havn't changed the build to not do the copy yet). I have temporarily set the hythr library version to 0.2 so that the federated build can be run with and without the hy.no.thr flag set. This opens a couple of questions for discussion: 1) Shall we set the hy.no.thr option to true as default? I personally think we should - the classlib hythr library is not used in the federated builds, so there is no reason to continue building it. 2) Shall we remove the thread library from classlib altogether? If hy.no.thr=true becomes the default, I can see reasons for and against [1] removing the source from classlib, but I think the reasons to remove the code outweigh the reasons to keep it. My vote is to remove that source module from classlib altogether. Ideas/comments? Regards, Oliver [1] A few I can think of straight off: For: - Unused thread library code in classlib is unlikely to be maintained. - Some classlib thread code is incorrect (x86_64 linux has some invalid assembler code I believe). - Shrinks the source tree footprint. - All VMs will likely have their own implementation of this functionality anyway. Against: - Raises the bar slightly for VM vendors wishing to use the Harmony class libraries. -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 7415 98. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Thread library function table added
I think we should do this. However, this will "break" developers using the IBM VME. Perhaps we could do: Index: make/properties.xml === --- make/properties.xml (revision 805151) +++ make/properties.xml (working copy) @@ -286,7 +286,10 @@ - + + + + to mitigate this slightly? Regards, Mark. In message <[email protected]>, Oliver Deakin writes: > > Carrying on from this discussion, I'd like to make hy.no.thr=true the > default setting and stop building the classlib thread library in the > federated build. > > Please let me know if there are any objections/comments on this, > otherwise I will make the change after M11 is published. > > Regards, > Oliver > > Oliver Deakin wrote: > > Mark Hindess wrote: > >> In message > >> <[email protected]>, > >> Sean Qiu writes: > >> > >>> +1 for both of your proposal, it sounds reasonable and cool. > >>> Thanks, Oli. > >>> > >> > >> I am in favour of removing the option completely and removing the > >> classlib thread code. Of course, this breaks the IBM VME so perhaps we > >> can leave it in place - but change the default? - until a new IBM VME is > >> available? > >> > > Yes, I think we should switch the default to hy.no.thr=true for a > > transition period. There is no harm in keeping the classlib thread > > code present for a while, but I think the eventual goal should be to > > delete it from the repo. > > > >> > >>> One question here, what do you mean remove the code? svn del? > >>> What about we "svn move" it to some other place, such as > >>> > >>> https://svn.apache.org/repos/asf/harmony/enhanced/legacy > >>> > >> > >> Well, we already have: > >> > >> https://svn.apache.org/repos/asf/harmony/enhanced/classlib/archive > >> > >> but I think "svn delete" is fine since you can always checkout earlier > >> revisions if you need to revisit the code. > >> > > > > Agreed. > > > > Regards, > > Oliver > > > >> Regards, > >> Mark. > >> > >> > >>> 2009/8/11 Oliver Deakin : > >>> > >>>> Hi all, > >>>> > >>>> I have added an implementation of the thread library function table > >>>> for > >>>> DRLVM which can be enabled by building with the "-Dhy.no.thr=true" > >>>> flag > >>>> specified on the Ant command line. This means we no longer need to > >>>> build th > >>>> > >>> e > >>> > >>>> classlib thread library in the federated build, and we also no > >>>> longer need > >>>> to copy the DRLVM hythr library into jre/bin (although I havn't > >>>> changed the > >>>> build to not do the copy yet). I have temporarily set the hythr > >>>> library > >>>> version to 0.2 so that the federated build can be run with and > >>>> without the > >>>> hy.no.thr flag set. > >>>> > >>>> This opens a couple of questions for discussion: > >>>> 1) Shall we set the hy.no.thr option to true as default? I > >>>> personally think > >>>> we should - the classlib hythr library is not used in the federated > >>>> builds, > >>>> so there is no reason to continue building it. > >>>> 2) Shall we remove the thread library from classlib altogether? If > >>>> hy.no.thr=true becomes the default, I can see reasons for and > >>>> against [1] > >>>> removing the source from classlib, but I think the reasons to > >>>> remove the > >>>> code outweigh the reasons to keep it. My vote is to remove that source > >>>> module from classlib altogether. > >>>> > >>>> Ideas/comments? > >>>> > >>>> Regards, > >>>> Oliver > >>>> > >>>> [1] A few I can think of straight off: > >>>> For: > >>>> - Unused thread library code in classlib is unlikely to be maintained. > >>>> - Some classlib thread code is incorrect (x86_64 linux has some > >>>> invalid > >>>> assembler code I believe). > >>>> - Shrinks the source tree footprint. > >>>> - All VMs will likely have their own implementation of this > >>>> functionality > >>>> anyway. > >>>> Against: > >>>> - Raises the bar slightly for VM vendors wishing to use the Harmony > >>>> class > >>>> libraries. > >>>> > >> > >> > >> > >> > > > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 7415 > 98. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >
Re: [drlvm] Thread library function table added
Carrying on from this discussion, I'd like to make hy.no.thr=true the default setting and stop building the classlib thread library in the federated build. Please let me know if there are any objections/comments on this, otherwise I will make the change after M11 is published. Regards, Oliver Oliver Deakin wrote: Mark Hindess wrote: In message <[email protected]>, Sean Qiu writes: +1 for both of your proposal, it sounds reasonable and cool. Thanks, Oli. I am in favour of removing the option completely and removing the classlib thread code. Of course, this breaks the IBM VME so perhaps we can leave it in place - but change the default? - until a new IBM VME is available? Yes, I think we should switch the default to hy.no.thr=true for a transition period. There is no harm in keeping the classlib thread code present for a while, but I think the eventual goal should be to delete it from the repo. One question here, what do you mean remove the code? svn del? What about we "svn move" it to some other place, such as https://svn.apache.org/repos/asf/harmony/enhanced/legacy Well, we already have: https://svn.apache.org/repos/asf/harmony/enhanced/classlib/archive but I think "svn delete" is fine since you can always checkout earlier revisions if you need to revisit the code. Agreed. Regards, Oliver Regards, Mark. 2009/8/11 Oliver Deakin : Hi all, I have added an implementation of the thread library function table for DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag specified on the Ant command line. This means we no longer need to build th e classlib thread library in the federated build, and we also no longer need to copy the DRLVM hythr library into jre/bin (although I havn't changed the build to not do the copy yet). I have temporarily set the hythr library version to 0.2 so that the federated build can be run with and without the hy.no.thr flag set. This opens a couple of questions for discussion: 1) Shall we set the hy.no.thr option to true as default? I personally think we should - the classlib hythr library is not used in the federated builds, so there is no reason to continue building it. 2) Shall we remove the thread library from classlib altogether? If hy.no.thr=true becomes the default, I can see reasons for and against [1] removing the source from classlib, but I think the reasons to remove the code outweigh the reasons to keep it. My vote is to remove that source module from classlib altogether. Ideas/comments? Regards, Oliver [1] A few I can think of straight off: For: - Unused thread library code in classlib is unlikely to be maintained. - Some classlib thread code is incorrect (x86_64 linux has some invalid assembler code I believe). - Shrinks the source tree footprint. - All VMs will likely have their own implementation of this functionality anyway. Against: - Raises the bar slightly for VM vendors wishing to use the Harmony class libraries. -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Upgrading APR
Mark Hindess wrote: In message <[email protected]>, Tim Ellison writes: On 13/Aug/2009 22:56, Pavel Pervov wrote: +1. This also makes APR buildable with VS 2K8. Thanks for the effort. Almost. I have a few changes sat in my workspace that are also required. I will commit them after Mark updates APR. Ok. My tests ran okay on Linux/x86, Linux/x86_64 and Windows/x86 so I've committed the upgrade in r804151. My tests on Windows x86 also ran well with no new failures. Regards, Oliver I notice that there are changes to the LICENSE/NOTICE files in APR 1.3.8 (appended below). Do we need to replicate these in our corresponding files. Regards, Mark. --- semis/apr/src/LICENSE 2004-12-05 21:34:37.0 + +++ semis/apr/src/LICENSE 2008-05-02 18:26:59.0 +0100 @@ -295,3 +295,47 @@ misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. +From strings/apr_snprintf.c: + + * + * cvt - IEEE floating point formatting routines. + * Derived from UNIX V7, Copyright(C) Caldera International Inc. + * + + Copyright(C) Caldera International Inc. 2001-2002. All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are + met: + + Redistributions of source code and documentation must retain the above + copyright notice, this list of conditions and the following disclaimer. + + Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + + All advertising materials mentioning features or use of this software + must display the following acknowledgement: + + This product includes software developed or owned by Caldera + International, Inc. + + Neither the name of Caldera International, Inc. nor the names of other + contributors may be used to endorse or promote products derived from + this software without specific prior written permission. + + USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA + INTERNATIONAL, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED + WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN + NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE FOR ANY DIRECT, + INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. + + --- semis/apr/src/NOTICE2004-11-24 22:51:51.0 + +++ semis/apr/src/NOTICE2009-07-02 03:45:11.0 +0100 @@ -1,3 +1,6 @@ +Apache Portable Runtime +Copyright (c) 2009 The Apache Software Foundation. + This product includes software developed by The Apache Software Foundation (http://www.apache.org/). @@ -7,3 +10,6 @@ This software contains code derived from the RSA Data Security Inc. MD5 Message-Digest Algorithm. + +This software contains code derived from UNIX V7, Copyright(C) +Caldera International Inc. -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Upgrading APR
In message <[email protected]>, Tim Ellison writes: > > On 13/Aug/2009 22:56, Pavel Pervov wrote: > > +1. This also makes APR buildable with VS 2K8. Thanks for the effort. > > Almost. I have a few changes sat in my workspace that are also > required. I will commit them after Mark updates APR. Ok. My tests ran okay on Linux/x86, Linux/x86_64 and Windows/x86 so I've committed the upgrade in r804151. I notice that there are changes to the LICENSE/NOTICE files in APR 1.3.8 (appended below). Do we need to replicate these in our corresponding files. Regards, Mark. --- semis/apr/src/LICENSE 2004-12-05 21:34:37.0 + +++ semis/apr/src/LICENSE 2008-05-02 18:26:59.0 +0100 @@ -295,3 +295,47 @@ misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. +From strings/apr_snprintf.c: + + * + * cvt - IEEE floating point formatting routines. + * Derived from UNIX V7, Copyright(C) Caldera International Inc. + * + + Copyright(C) Caldera International Inc. 2001-2002. All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are + met: + + Redistributions of source code and documentation must retain the above + copyright notice, this list of conditions and the following disclaimer. + + Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + + All advertising materials mentioning features or use of this software + must display the following acknowledgement: + + This product includes software developed or owned by Caldera + International, Inc. + + Neither the name of Caldera International, Inc. nor the names of other + contributors may be used to endorse or promote products derived from + this software without specific prior written permission. + + USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA + INTERNATIONAL, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED + WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN + NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE FOR ANY DIRECT, + INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN + ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. + + --- semis/apr/src/NOTICE2004-11-24 22:51:51.0 + +++ semis/apr/src/NOTICE2009-07-02 03:45:11.0 +0100 @@ -1,3 +1,6 @@ +Apache Portable Runtime +Copyright (c) 2009 The Apache Software Foundation. + This product includes software developed by The Apache Software Foundation (http://www.apache.org/). @@ -7,3 +10,6 @@ This software contains code derived from the RSA Data Security Inc. MD5 Message-Digest Algorithm. + +This software contains code derived from UNIX V7, Copyright(C) +Caldera International Inc.
Re: [drlvm] Thread library function table added
Mark Hindess wrote: In message <[email protected]>, Sean Qiu writes: +1 for both of your proposal, it sounds reasonable and cool. Thanks, Oli. I am in favour of removing the option completely and removing the classlib thread code. Of course, this breaks the IBM VME so perhaps we can leave it in place - but change the default? - until a new IBM VME is available? Yes, I think we should switch the default to hy.no.thr=true for a transition period. There is no harm in keeping the classlib thread code present for a while, but I think the eventual goal should be to delete it from the repo. One question here, what do you mean remove the code? svn del? What about we "svn move" it to some other place, such as https://svn.apache.org/repos/asf/harmony/enhanced/legacy Well, we already have: https://svn.apache.org/repos/asf/harmony/enhanced/classlib/archive but I think "svn delete" is fine since you can always checkout earlier revisions if you need to revisit the code. Agreed. Regards, Oliver Regards, Mark. 2009/8/11 Oliver Deakin : Hi all, I have added an implementation of the thread library function table for DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag specified on the Ant command line. This means we no longer need to build th e classlib thread library in the federated build, and we also no longer need to copy the DRLVM hythr library into jre/bin (although I havn't changed the build to not do the copy yet). I have temporarily set the hythr library version to 0.2 so that the federated build can be run with and without the hy.no.thr flag set. This opens a couple of questions for discussion: 1) Shall we set the hy.no.thr option to true as default? I personally think we should - the classlib hythr library is not used in the federated builds, so there is no reason to continue building it. 2) Shall we remove the thread library from classlib altogether? If hy.no.thr=true becomes the default, I can see reasons for and against [1] removing the source from classlib, but I think the reasons to remove the code outweigh the reasons to keep it. My vote is to remove that source module from classlib altogether. Ideas/comments? Regards, Oliver [1] A few I can think of straight off: For: - Unused thread library code in classlib is unlikely to be maintained. - Some classlib thread code is incorrect (x86_64 linux has some invalid assembler code I believe). - Shrinks the source tree footprint. - All VMs will likely have their own implementation of this functionality anyway. Against: - Raises the bar slightly for VM vendors wishing to use the Harmony class libraries. -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Upgrading APR
On 13/Aug/2009 22:56, Pavel Pervov wrote: > +1. This also makes APR buildable with VS 2K8. Thanks for the effort. Almost. I have a few changes sat in my workspace that are also required. I will commit them after Mark updates APR. Regards, Tim
Re: [drlvm] Upgrading APR
+1 to this also - Im giving the patch below a full test run on Windows
x86 at the moment, Ill let you know if anything turns up.
Regards,
Oliver
Mark Hindess wrote:
DRLVM is using APR version 1.2.12 which was released in November 2007.
There have been numerous bug/security fixes since that time. I think we
should upgrade to APR version 1.3.8 which was on August 6th 2009.
I've tested the following patch on Linux/x86_64 and I am running tests
on Linux/x86 and windows/x86. Assuming the Linux/x86 and windows/x86
tests are okay, then I'd like to commit this patch (from inclusion in
M11).
Any objections?
Regards,
Mark
Index: working_vm/README.txt
===
--- working_vm/README.txt (revision 803806)
+++ working_vm/README.txt (working copy)
@@ -112,7 +112,7 @@
Apache Harmony site [http://harmony.apache.org/quickhelp_contributors.html].
Also, there are external resources required for building DRLVM:
-zlib, apr-1.2.12, log4cxx, cpptasks-1.b04, etc.
+zlib, apr-1.3.8, log4cxx, cpptasks-1.b04, etc.
This list can change as DRLVM is being developed, so the best way to resolve
external dependencies is to let the build download them:
$ ant fetch-depends
Index: working_vm/make/depends.properties
===
--- working_vm/make/depends.properties (revision 803806)
+++ working_vm/make/depends.properties (working copy)
@@ -25,10 +25,10 @@
# Apache Portable Runtime, version 1.1 or above
# http://apr.apache.org/download.cgi
-apr.src.tgz=${depends.oss}/apr/apr-1.2.12.tar.gz
-apr.src.rootdir=apr-1.2.12
-apr.src.tgz.url=http://archive.apache.org/dist/apr/apr-1.2.12.tar.gz
-apr.src.tgz.md5=020ea947446dca2d1210c099c7a4c837
+apr.src.tgz=${depends.oss}/apr/apr-1.3.8.tar.gz
+apr.src.rootdir=apr-1.3.8
+apr.src.tgz.url=http://www.apache.org/dist/apr/apr-1.3.8.tar.gz
+apr.src.tgz.md5=310fac12285d94a162c488f4b8f1aabc
# ZLIB, version 1.2.1 or above
# http://www.zlib.net/
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Upgrading APR
+1
Thanks, Mark.
Best Regards
Sean, Xiao Xia Qiu
2009/8/14 Mark Hindess :
>
> DRLVM is using APR version 1.2.12 which was released in November 2007.
> There have been numerous bug/security fixes since that time. I think we
> should upgrade to APR version 1.3.8 which was on August 6th 2009.
>
> I've tested the following patch on Linux/x86_64 and I am running tests
> on Linux/x86 and windows/x86. Assuming the Linux/x86 and windows/x86
> tests are okay, then I'd like to commit this patch (from inclusion in
> M11).
>
> Any objections?
>
> Regards,
> Mark
>
> Index: working_vm/README.txt
> ===
> --- working_vm/README.txt (revision 803806)
> +++ working_vm/README.txt (working copy)
> @@ -112,7 +112,7 @@
> Apache Harmony site [http://harmony.apache.org/quickhelp_contributors.html].
>
> Also, there are external resources required for building DRLVM:
> -zlib, apr-1.2.12, log4cxx, cpptasks-1.b04, etc.
> +zlib, apr-1.3.8, log4cxx, cpptasks-1.b04, etc.
> This list can change as DRLVM is being developed, so the best way to resolve
> external dependencies is to let the build download them:
> $ ant fetch-depends
> Index: working_vm/make/depends.properties
> ===
> --- working_vm/make/depends.properties (revision 803806)
> +++ working_vm/make/depends.properties (working copy)
> @@ -25,10 +25,10 @@
>
> # Apache Portable Runtime, version 1.1 or above
> # http://apr.apache.org/download.cgi
> -apr.src.tgz=${depends.oss}/apr/apr-1.2.12.tar.gz
> -apr.src.rootdir=apr-1.2.12
> -apr.src.tgz.url=http://archive.apache.org/dist/apr/apr-1.2.12.tar.gz
> -apr.src.tgz.md5=020ea947446dca2d1210c099c7a4c837
> +apr.src.tgz=${depends.oss}/apr/apr-1.3.8.tar.gz
> +apr.src.rootdir=apr-1.3.8
> +apr.src.tgz.url=http://www.apache.org/dist/apr/apr-1.3.8.tar.gz
> +apr.src.tgz.md5=310fac12285d94a162c488f4b8f1aabc
>
> # ZLIB, version 1.2.1 or above
> # http://www.zlib.net/
>
>
>
Re: [drlvm] Upgrading APR
+1
On Fri, Aug 14, 2009 at 5:52 AM, Mark
Hindess wrote:
>
> DRLVM is using APR version 1.2.12 which was released in November 2007.
> There have been numerous bug/security fixes since that time. I think we
> should upgrade to APR version 1.3.8 which was on August 6th 2009.
>
> I've tested the following patch on Linux/x86_64 and I am running tests
> on Linux/x86 and windows/x86. Assuming the Linux/x86 and windows/x86
> tests are okay, then I'd like to commit this patch (from inclusion in
> M11).
>
> Any objections?
>
> Regards,
> Mark
>
> Index: working_vm/README.txt
> ===
> --- working_vm/README.txt (revision 803806)
> +++ working_vm/README.txt (working copy)
> @@ -112,7 +112,7 @@
> Apache Harmony site [http://harmony.apache.org/quickhelp_contributors.html].
>
> Also, there are external resources required for building DRLVM:
> -zlib, apr-1.2.12, log4cxx, cpptasks-1.b04, etc.
> +zlib, apr-1.3.8, log4cxx, cpptasks-1.b04, etc.
> This list can change as DRLVM is being developed, so the best way to resolve
> external dependencies is to let the build download them:
> $ ant fetch-depends
> Index: working_vm/make/depends.properties
> ===
> --- working_vm/make/depends.properties (revision 803806)
> +++ working_vm/make/depends.properties (working copy)
> @@ -25,10 +25,10 @@
>
> # Apache Portable Runtime, version 1.1 or above
> # http://apr.apache.org/download.cgi
> -apr.src.tgz=${depends.oss}/apr/apr-1.2.12.tar.gz
> -apr.src.rootdir=apr-1.2.12
> -apr.src.tgz.url=http://archive.apache.org/dist/apr/apr-1.2.12.tar.gz
> -apr.src.tgz.md5=020ea947446dca2d1210c099c7a4c837
> +apr.src.tgz=${depends.oss}/apr/apr-1.3.8.tar.gz
> +apr.src.rootdir=apr-1.3.8
> +apr.src.tgz.url=http://www.apache.org/dist/apr/apr-1.3.8.tar.gz
> +apr.src.tgz.md5=310fac12285d94a162c488f4b8f1aabc
>
> # ZLIB, version 1.2.1 or above
> # http://www.zlib.net/
>
>
>
--
http://people.apache.org/~xli
Re: [drlvm] Upgrading APR
Mark.
+1. This also makes APR buildable with VS 2K8. Thanks for the effort.
Pavel.
On Fri, Aug 14, 2009 at 1:52 AM, Mark
Hindess wrote:
>
> DRLVM is using APR version 1.2.12 which was released in November 2007.
> There have been numerous bug/security fixes since that time. I think we
> should upgrade to APR version 1.3.8 which was on August 6th 2009.
>
> I've tested the following patch on Linux/x86_64 and I am running tests
> on Linux/x86 and windows/x86. Assuming the Linux/x86 and windows/x86
> tests are okay, then I'd like to commit this patch (from inclusion in
> M11).
>
> Any objections?
>
> Regards,
> Mark
>
> Index: working_vm/README.txt
> ===
> --- working_vm/README.txt (revision 803806)
> +++ working_vm/README.txt (working copy)
> @@ -112,7 +112,7 @@
> Apache Harmony site [http://harmony.apache.org/quickhelp_contributors.html].
>
> Also, there are external resources required for building DRLVM:
> -zlib, apr-1.2.12, log4cxx, cpptasks-1.b04, etc.
> +zlib, apr-1.3.8, log4cxx, cpptasks-1.b04, etc.
> This list can change as DRLVM is being developed, so the best way to resolve
> external dependencies is to let the build download them:
> $ ant fetch-depends
> Index: working_vm/make/depends.properties
> ===
> --- working_vm/make/depends.properties (revision 803806)
> +++ working_vm/make/depends.properties (working copy)
> @@ -25,10 +25,10 @@
>
> # Apache Portable Runtime, version 1.1 or above
> # http://apr.apache.org/download.cgi
> -apr.src.tgz=${depends.oss}/apr/apr-1.2.12.tar.gz
> -apr.src.rootdir=apr-1.2.12
> -apr.src.tgz.url=http://archive.apache.org/dist/apr/apr-1.2.12.tar.gz
> -apr.src.tgz.md5=020ea947446dca2d1210c099c7a4c837
> +apr.src.tgz=${depends.oss}/apr/apr-1.3.8.tar.gz
> +apr.src.rootdir=apr-1.3.8
> +apr.src.tgz.url=http://www.apache.org/dist/apr/apr-1.3.8.tar.gz
> +apr.src.tgz.md5=310fac12285d94a162c488f4b8f1aabc
>
> # ZLIB, version 1.2.1 or above
> # http://www.zlib.net/
>
>
>
[drlvm] Upgrading APR
DRLVM is using APR version 1.2.12 which was released in November 2007.
There have been numerous bug/security fixes since that time. I think we
should upgrade to APR version 1.3.8 which was on August 6th 2009.
I've tested the following patch on Linux/x86_64 and I am running tests
on Linux/x86 and windows/x86. Assuming the Linux/x86 and windows/x86
tests are okay, then I'd like to commit this patch (from inclusion in
M11).
Any objections?
Regards,
Mark
Index: working_vm/README.txt
===
--- working_vm/README.txt (revision 803806)
+++ working_vm/README.txt (working copy)
@@ -112,7 +112,7 @@
Apache Harmony site [http://harmony.apache.org/quickhelp_contributors.html].
Also, there are external resources required for building DRLVM:
-zlib, apr-1.2.12, log4cxx, cpptasks-1.b04, etc.
+zlib, apr-1.3.8, log4cxx, cpptasks-1.b04, etc.
This list can change as DRLVM is being developed, so the best way to resolve
external dependencies is to let the build download them:
$ ant fetch-depends
Index: working_vm/make/depends.properties
===
--- working_vm/make/depends.properties (revision 803806)
+++ working_vm/make/depends.properties (working copy)
@@ -25,10 +25,10 @@
# Apache Portable Runtime, version 1.1 or above
# http://apr.apache.org/download.cgi
-apr.src.tgz=${depends.oss}/apr/apr-1.2.12.tar.gz
-apr.src.rootdir=apr-1.2.12
-apr.src.tgz.url=http://archive.apache.org/dist/apr/apr-1.2.12.tar.gz
-apr.src.tgz.md5=020ea947446dca2d1210c099c7a4c837
+apr.src.tgz=${depends.oss}/apr/apr-1.3.8.tar.gz
+apr.src.rootdir=apr-1.3.8
+apr.src.tgz.url=http://www.apache.org/dist/apr/apr-1.3.8.tar.gz
+apr.src.tgz.md5=310fac12285d94a162c488f4b8f1aabc
# ZLIB, version 1.2.1 or above
# http://www.zlib.net/
Re: [drlvm] Thread library function table added
Thanks Pavel - the code is now committed and can be built by specifying -Dhy.no.thr=true on the ant command line. Regards, Oliver Pavel Pervov wrote: Oliver. This is great progress with threading library. Once the table implementation is committed, we can move threading code inside harmony vm module from the separate dynamic library, which will certainly give us additional performance. Pavel. 2009/8/11, Oliver Deakin : Hi all, I have added an implementation of the thread library function table for DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag specified on the Ant command line. This means we no longer need to build the classlib thread library in the federated build, and we also no longer need to copy the DRLVM hythr library into jre/bin (although I havn't changed the build to not do the copy yet). I have temporarily set the hythr library version to 0.2 so that the federated build can be run with and without the hy.no.thr flag set. This opens a couple of questions for discussion: 1) Shall we set the hy.no.thr option to true as default? I personally think we should - the classlib hythr library is not used in the federated builds, so there is no reason to continue building it. 2) Shall we remove the thread library from classlib altogether? If hy.no.thr=true becomes the default, I can see reasons for and against [1] removing the source from classlib, but I think the reasons to remove the code outweigh the reasons to keep it. My vote is to remove that source module from classlib altogether. Ideas/comments? Regards, Oliver [1] A few I can think of straight off: For: - Unused thread library code in classlib is unlikely to be maintained. - Some classlib thread code is incorrect (x86_64 linux has some invalid assembler code I believe). - Shrinks the source tree footprint. - All VMs will likely have their own implementation of this functionality anyway. Against: - Raises the bar slightly for VM vendors wishing to use the Harmony class libraries. -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Thread library function table added
Oliver. This is great progress with threading library. Once the table implementation is committed, we can move threading code inside harmony vm module from the separate dynamic library, which will certainly give us additional performance. Pavel. 2009/8/11, Oliver Deakin : > Hi all, > > I have added an implementation of the thread library function table for > DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag > specified on the Ant command line. This means we no longer need to build > the classlib thread library in the federated build, and we also no > longer need to copy the DRLVM hythr library into jre/bin (although I > havn't changed the build to not do the copy yet). I have temporarily set > the hythr library version to 0.2 so that the federated build can be run > with and without the hy.no.thr flag set. > > This opens a couple of questions for discussion: > 1) Shall we set the hy.no.thr option to true as default? I personally > think we should - the classlib hythr library is not used in the > federated builds, so there is no reason to continue building it. > 2) Shall we remove the thread library from classlib altogether? If > hy.no.thr=true becomes the default, I can see reasons for and against > [1] removing the source from classlib, but I think the reasons to remove > the code outweigh the reasons to keep it. My vote is to remove that > source module from classlib altogether. > > Ideas/comments? > > Regards, > Oliver > > [1] A few I can think of straight off: > For: > - Unused thread library code in classlib is unlikely to be maintained. > - Some classlib thread code is incorrect (x86_64 linux has some invalid > assembler code I believe). > - Shrinks the source tree footprint. > - All VMs will likely have their own implementation of this > functionality anyway. > Against: > - Raises the bar slightly for VM vendors wishing to use the Harmony > class libraries. > > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >
Re: [drlvm] Thread library function table added
In message <[email protected]>, Sean Qiu writes: > > +1 for both of your proposal, it sounds reasonable and cool. > Thanks, Oli. I am in favour of removing the option completely and removing the classlib thread code. Of course, this breaks the IBM VME so perhaps we can leave it in place - but change the default? - until a new IBM VME is available? > One question here, what do you mean remove the code? svn del? > What about we "svn move" it to some other place, such as > > https://svn.apache.org/repos/asf/harmony/enhanced/legacy Well, we already have: https://svn.apache.org/repos/asf/harmony/enhanced/classlib/archive but I think "svn delete" is fine since you can always checkout earlier revisions if you need to revisit the code. Regards, Mark. > 2009/8/11 Oliver Deakin : > > Hi all, > > > > I have added an implementation of the thread library function table for > > DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag > > specified on the Ant command line. This means we no longer need to build th > e > > classlib thread library in the federated build, and we also no longer need > > to copy the DRLVM hythr library into jre/bin (although I havn't changed the > > build to not do the copy yet). I have temporarily set the hythr library > > version to 0.2 so that the federated build can be run with and without the > > hy.no.thr flag set. > > > > This opens a couple of questions for discussion: > > 1) Shall we set the hy.no.thr option to true as default? I personally think > > we should - the classlib hythr library is not used in the federated builds, > > so there is no reason to continue building it. > > 2) Shall we remove the thread library from classlib altogether? If > > hy.no.thr=true becomes the default, I can see reasons for and against [1] > > removing the source from classlib, but I think the reasons to remove the > > code outweigh the reasons to keep it. My vote is to remove that source > > module from classlib altogether. > > > > Ideas/comments? > > > > Regards, > > Oliver > > > > [1] A few I can think of straight off: > > For: > > - Unused thread library code in classlib is unlikely to be maintained. > > - Some classlib thread code is incorrect (x86_64 linux has some invalid > > assembler code I believe). > > - Shrinks the source tree footprint. > > - All VMs will likely have their own implementation of this functionality > > anyway. > > Against: > > - Raises the bar slightly for VM vendors wishing to use the Harmony class > > libraries.
Re: [drlvm] Thread library function table added
+1 for both of your proposal, it sounds reasonable and cool. Thanks, Oli. One question here, what do you mean remove the code? svn del? What about we "svn move" it to some other place, such as https://svn.apache.org/repos/asf/harmony/enhanced/legacy Best Regards Sean, Xiao Xia Qiu 2009/8/11 Oliver Deakin : > Hi all, > > I have added an implementation of the thread library function table for > DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag > specified on the Ant command line. This means we no longer need to build the > classlib thread library in the federated build, and we also no longer need > to copy the DRLVM hythr library into jre/bin (although I havn't changed the > build to not do the copy yet). I have temporarily set the hythr library > version to 0.2 so that the federated build can be run with and without the > hy.no.thr flag set. > > This opens a couple of questions for discussion: > 1) Shall we set the hy.no.thr option to true as default? I personally think > we should - the classlib hythr library is not used in the federated builds, > so there is no reason to continue building it. > 2) Shall we remove the thread library from classlib altogether? If > hy.no.thr=true becomes the default, I can see reasons for and against [1] > removing the source from classlib, but I think the reasons to remove the > code outweigh the reasons to keep it. My vote is to remove that source > module from classlib altogether. > > Ideas/comments? > > Regards, > Oliver > > [1] A few I can think of straight off: > For: > - Unused thread library code in classlib is unlikely to be maintained. > - Some classlib thread code is incorrect (x86_64 linux has some invalid > assembler code I believe). > - Shrinks the source tree footprint. > - All VMs will likely have their own implementation of this functionality > anyway. > Against: > - Raises the bar slightly for VM vendors wishing to use the Harmony class > libraries. > > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > >
Re: [drlvm] Thread library function table added
Oliver, I support this idea. Thanks, xiaofeng On Tue, Aug 11, 2009 at 10:02 PM, Oliver Deakin wrote: > Hi all, > > I have added an implementation of the thread library function table for > DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag > specified on the Ant command line. This means we no longer need to build the > classlib thread library in the federated build, and we also no longer need > to copy the DRLVM hythr library into jre/bin (although I havn't changed the > build to not do the copy yet). I have temporarily set the hythr library > version to 0.2 so that the federated build can be run with and without the > hy.no.thr flag set. > > This opens a couple of questions for discussion: > 1) Shall we set the hy.no.thr option to true as default? I personally think > we should - the classlib hythr library is not used in the federated builds, > so there is no reason to continue building it. > 2) Shall we remove the thread library from classlib altogether? If > hy.no.thr=true becomes the default, I can see reasons for and against [1] > removing the source from classlib, but I think the reasons to remove the > code outweigh the reasons to keep it. My vote is to remove that source > module from classlib altogether. > > Ideas/comments? > > Regards, > Oliver > > [1] A few I can think of straight off: > For: > - Unused thread library code in classlib is unlikely to be maintained. > - Some classlib thread code is incorrect (x86_64 linux has some invalid > assembler code I believe). > - Shrinks the source tree footprint. > - All VMs will likely have their own implementation of this functionality > anyway. > Against: > - Raises the bar slightly for VM vendors wishing to use the Harmony class > libraries. > > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > -- http://people.apache.org/~xli
[drlvm] Thread library function table added
Hi all, I have added an implementation of the thread library function table for DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag specified on the Ant command line. This means we no longer need to build the classlib thread library in the federated build, and we also no longer need to copy the DRLVM hythr library into jre/bin (although I havn't changed the build to not do the copy yet). I have temporarily set the hythr library version to 0.2 so that the federated build can be run with and without the hy.no.thr flag set. This opens a couple of questions for discussion: 1) Shall we set the hy.no.thr option to true as default? I personally think we should - the classlib hythr library is not used in the federated builds, so there is no reason to continue building it. 2) Shall we remove the thread library from classlib altogether? If hy.no.thr=true becomes the default, I can see reasons for and against [1] removing the source from classlib, but I think the reasons to remove the code outweigh the reasons to keep it. My vote is to remove that source module from classlib altogether. Ideas/comments? Regards, Oliver [1] A few I can think of straight off: For: - Unused thread library code in classlib is unlikely to be maintained. - Some classlib thread code is incorrect (x86_64 linux has some invalid assembler code I believe). - Shrinks the source tree footprint. - All VMs will likely have their own implementation of this functionality anyway. Against: - Raises the bar slightly for VM vendors wishing to use the Harmony class libraries. -- Oliver Deakin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [jira] Commented: (HARMONY-6279) [classlib][luni] file.encoding is always set to ISO-9959-1 if using drlvm
Thanks Alexey. I have tested on the Ubuntu 8.04 and windows xp sp3. On Fri, Jul 31, 2009 at 8:32 PM, Alexey Varlamov (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/HARMONY-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737510#action_12737510] > > Alexey Varlamov commented on HARMONY-6279: > -- > > Excellent! I assume you've tested it actually works on both OSes - then the > patch is ready for commit. > Nathan, could you please take it - I have no env set up now. > > > [classlib][luni] file.encoding is always set to ISO-9959-1 if using drlvm > > - > > > > Key: HARMONY-6279 > > URL: https://issues.apache.org/jira/browse/HARMONY-6279 > > Project: Harmony > > Issue Type: Bug > >Reporter: Li Jing Qin > > Attachments: HARMONY-6279.diff, HARMONY-6279.v2.diff, > HARMONY-6279.v3.diff, HARMONY-6279.v4.diff > > > > > > Our file.encoding in the system property is always set 8859-1 if we using > drlvm. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- Yours sincerely, Charles Lee
ANTLR in drlvm (was: [jira] Created: (HARMONY-6245) NoSuchMethod error with three-level hierarchy)
We'd hit this bar twice or thrice, and it looks like we'd hit it again. It's ANTLR parser used in DRLVM. AFAIR somebody volunteered to rewrite the parser from scratch. Is there any progress on this? -- Forwarded message -- From: "Hristo Spaschev Iliev (JIRA)" Date: Thu, 25 Jun 2009 01:35:07 -0700 (PDT) Subject: [jira] Created: (HARMONY-6245) NoSuchMethod error with three-level hierarchy To: [email protected] NoSuchMethod error with three-level hierarchy - Key: HARMONY-6245 URL: https://issues.apache.org/jira/browse/HARMONY-6245 Project: Harmony Issue Type: Bug Components: VM Affects Versions: 5.0M10 Environment: Windows XP SP2 32bit C:\jdk\harmony-jdk-782693\bin>java -version Apache Harmony Launcher : (c) Copyright 1991, 2009 The Apache Software Foundation or its licensors, as applicable. java version "1.5.0" pre-alpha : not complete or compatible svn = r782693, (Jun 12 2009), Windows/ia32/msvc 1310, release build http://harmony.apache.org Reporter: Hristo Spaschev Iliev Running the attached class produces: java.lang.NoSuchMethodError: com/sap/sql/sqlparser/SQLParser.resetTokenBuffer()V while resolving constant pool entry at index 9 in class Test at Test.main(Test.java:13) The hierarchy used is: public class SQLParser extends LLkParser public class LLkParser extends Parser The method resetTokenBuffer() however can be found in antlr.Parser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [drlvm] building DRLVM without JITRINO
Sergiy, the way to turn jitting off is to specify -Xint in the command line. Please look into processing of this option to undestand how to enforce interpreter from inside the drlvm code. 2009/6/18, Sergiy Lozovsky : > Hi, > > > > I'm trying to build DRLVM without JITRINO. One would guess that > interpreter is enough if speed is not a priority. I removed jitrino > directory all together and fixed ant scripts. Build is successful, but > there are problems during run time: > > > > EM: Can't read configuration from '... > /apache-harmony-src-r761593/working_vm/build/linux_x86_64_gcc_release/de > ploy/jdk/jre/bin/default/client.emconf' > > HMYEXEL062E Internal VM error: Failed to create Java VM > > FAILED to invoke JVM. > > > > client.emconf is provided by jitrino. Adding this file doesn't help > either: > > > > apr code: > .../apache-harmony-src-r761593/working_vm/build/linux_x86_64_gcc_release > /deploy/jdk/jre/bin/default/libjitrino.so: cannot open shared object > file: No such file or directory > > EM: JIT library loading error:'... > /apache-harmony-src-r761593/working_vm/build/linux_x86_64_gcc_release/de > ploy/jdk/jre/bin/default/libjitrino.so' > > HMYEXEL062E Internal VM error: Failed to create Java VM > > FAILED to invoke JVM. > > > > Does anyone know the clean way to remove jitrino and run DRLVM with > interpreter only? What changes should be made to do that? > > > > Thanks, > > > > Sergiy. > >
[drlvm] building DRLVM without JITRINO
Hi, I'm trying to build DRLVM without JITRINO. One would guess that interpreter is enough if speed is not a priority. I removed jitrino directory all together and fixed ant scripts. Build is successful, but there are problems during run time: EM: Can't read configuration from '... /apache-harmony-src-r761593/working_vm/build/linux_x86_64_gcc_release/de ploy/jdk/jre/bin/default/client.emconf' HMYEXEL062E Internal VM error: Failed to create Java VM FAILED to invoke JVM. client.emconf is provided by jitrino. Adding this file doesn't help either: apr code: .../apache-harmony-src-r761593/working_vm/build/linux_x86_64_gcc_release /deploy/jdk/jre/bin/default/libjitrino.so: cannot open shared object file: No such file or directory EM: JIT library loading error:'... /apache-harmony-src-r761593/working_vm/build/linux_x86_64_gcc_release/de ploy/jdk/jre/bin/default/libjitrino.so' HMYEXEL062E Internal VM error: Failed to create Java VM FAILED to invoke JVM. Does anyone know the clean way to remove jitrino and run DRLVM with interpreter only? What changes should be made to do that? Thanks, Sergiy.
Re: [drlvm][jitrino] write barrier was broken
Simon, a patch is here https://issues.apache.org/jira/browse/HARMONY-6211. -Xiaoming On Sat, May 23, 2009 at 6:00 PM, xiaoming gu wrote: > Hi, Simon. The debug is about an peephole optimization. I assumed no > control flow branch in the middle of a basic block. But I find some CALL > insts break the assumption sometimes like following: > > I4: t5:ref:cls:java/lang/ref/ReferenceQueue =ADD > t0:cls:java/lang/ref/Reference, t4(0):intptr > I5: CALL t7(0):I_32 (AU:t0:cls:java/lang/ref/Reference, > t5:ref:cls:java/lang/ref/ReferenceQueue, > t2:cls:java/lang/ref/ReferenceQueue) [bcmap:6] > I6: t9:ref:cls:java/lang/Object =ADD > t0:cls:java/lang/ref/Reference,t8(0):intptr > I7: CALL t10(0):I_32 > (AU:t0:cls:java/lang/ref/Reference,t9:ref:cls:java/lang/Object,t1:cls:java/lang/Object) > [bcmap:11] > I8: RET t11(0):int16! > > So far I don't know why CALL can sit there. Whatever, I'll file a bug on > JIRA and put a preliminary patch. Thanks. > > Xiaoming > > > On Sat, May 16, 2009 at 11:25 PM, xiaoming gu wrote: > >> Thanks for the helpful info, Simon. I'll look into it. -Xiaoming >> >> >> On Sat, May 16, 2009 at 10:56 PM, Simon Zhou wrote: >> >>> Xiaoming, >>> >>> I am sorry that maybe my previous guesswork is wrong. >>> it is not caused by global_prop, because the issue still exists after I >>> remove the global_prop in config file. >>> but after I revert all the modification of this patch, VM runs pretty >>> well, >>> so it maybe caused by other modification in this patch but global_prop, >>> or >>> not just global_prop. I am not sure... >>> Thanks for your help! >>> Thanks >>> Simon >>> 2009/5/16 xiaoming gu >>> >>> > Hi, Simon. A workaround is to replace global_prop with early_prop in >>> the >>> > used execution mode configuration file. I'll take care of this bug >>> these >>> > days. Thanks. >>> > >>> > Xiaoming >>> > >>> > On Sat, May 16, 2009 at 5:04 PM, Simon Zhou >>> > wrote: >>> > >>> > > I think I found the origin of this issue by binary searching the >>> previous >>> > > patches, I foud that it is broken since version 747844 (747843 is >>> OK), so >>> > > I am guessing the patch of 5826 breaks this. >>> > > >>> > > To replay the error, just add -XX:gc.generate_barrier=true to command >>> > line >>> > > when running a Java application. >>> > > I added some of my guesswork in >>> > > https://issues.apache.org/jira/browse/HARMONY-5826 >>> > > >>> > > Xiaoming, Would you like to give me advice for this issue? Or is >>> there >>> > some >>> > > workaroud for it? Thank you very much! >>> > > >>> > > Thanks >>> > > Simon >>> > > >>> > > 2009/5/16 Simon Zhou >>> > > >>> > > > Hi All, >>> > > > >>> > > > I am doing my GSoC2009 project of implementing weak reference in >>> > > > Concurrent GC. I found that as long as the gc.generate_barrier=true >>> is >>> > > set, >>> > > > VM will crash when it startups (int vm_init2() method). I was >>> following >>> > > this >>> > > > issue these days but did not work out. >>> > > > This issue seem to come out after milestone8, so I guess it >>> could be >>> > > > caused by some patches on Jitrino after M8. >>> > > >Is there anyone else being aware of that? Or could you please >>> > provide >>> > > > some information about which patch could cause it? >>> > > >Thank you very much! >>> > > > >>> > > > Thanks >>> > > > Simon >>> > > > >>> > > > -- >>> > > > From : simon.z...@ppi, Fudan University >>> > > > >>> > > >>> > > >>> > > >>> > > -- >>> > > From : simon.z...@ppi, Fudan University >>> > > >>> > >>> >>> >>> >>> -- >>> From : simon.z...@ppi, Fudan University >>> >> >> >
Re: [drlvm][jitrino] write barrier was broken
Hi, Simon. The debug is about an peephole optimization. I assumed no control flow branch in the middle of a basic block. But I find some CALL insts break the assumption sometimes like following: I4: t5:ref:cls:java/lang/ref/ReferenceQueue =ADD t0:cls:java/lang/ref/Reference, t4(0):intptr I5: CALL t7(0):I_32 (AU:t0:cls:java/lang/ref/Reference, t5:ref:cls:java/lang/ref/ReferenceQueue, t2:cls:java/lang/ref/ReferenceQueue) [bcmap:6] I6: t9:ref:cls:java/lang/Object =ADD t0:cls:java/lang/ref/Reference,t8(0):intptr I7: CALL t10(0):I_32 (AU:t0:cls:java/lang/ref/Reference,t9:ref:cls:java/lang/Object,t1:cls:java/lang/Object) [bcmap:11] I8: RET t11(0):int16! So far I don't know why CALL can sit there. Whatever, I'll file a bug on JIRA and put a preliminary patch. Thanks. Xiaoming On Sat, May 16, 2009 at 11:25 PM, xiaoming gu wrote: > Thanks for the helpful info, Simon. I'll look into it. -Xiaoming > > > On Sat, May 16, 2009 at 10:56 PM, Simon Zhou wrote: > >> Xiaoming, >> >> I am sorry that maybe my previous guesswork is wrong. >> it is not caused by global_prop, because the issue still exists after I >> remove the global_prop in config file. >> but after I revert all the modification of this patch, VM runs pretty >> well, >> so it maybe caused by other modification in this patch but global_prop, or >> not just global_prop. I am not sure... >> Thanks for your help! >> Thanks >> Simon >> 2009/5/16 xiaoming gu >> >> > Hi, Simon. A workaround is to replace global_prop with early_prop in the >> > used execution mode configuration file. I'll take care of this bug these >> > days. Thanks. >> > >> > Xiaoming >> > >> > On Sat, May 16, 2009 at 5:04 PM, Simon Zhou >> > wrote: >> > >> > > I think I found the origin of this issue by binary searching the >> previous >> > > patches, I foud that it is broken since version 747844 (747843 is OK), >> so >> > > I am guessing the patch of 5826 breaks this. >> > > >> > > To replay the error, just add -XX:gc.generate_barrier=true to command >> > line >> > > when running a Java application. >> > > I added some of my guesswork in >> > > https://issues.apache.org/jira/browse/HARMONY-5826 >> > > >> > > Xiaoming, Would you like to give me advice for this issue? Or is there >> > some >> > > workaroud for it? Thank you very much! >> > > >> > > Thanks >> > > Simon >> > > >> > > 2009/5/16 Simon Zhou >> > > >> > > > Hi All, >> > > > >> > > > I am doing my GSoC2009 project of implementing weak reference in >> > > > Concurrent GC. I found that as long as the gc.generate_barrier=true >> is >> > > set, >> > > > VM will crash when it startups (int vm_init2() method). I was >> following >> > > this >> > > > issue these days but did not work out. >> > > > This issue seem to come out after milestone8, so I guess it could >> be >> > > > caused by some patches on Jitrino after M8. >> > > >Is there anyone else being aware of that? Or could you please >> > provide >> > > > some information about which patch could cause it? >> > > >Thank you very much! >> > > > >> > > > Thanks >> > > > Simon >> > > > >> > > > -- >> > > > From : simon.z...@ppi, Fudan University >> > > > >> > > >> > > >> > > >> > > -- >> > > From : simon.z...@ppi, Fudan University >> > > >> > >> >> >> >> -- >> From : simon.z...@ppi, Fudan University >> > >
Re: [drlvm][jitrino] write barrier was broken
Thanks for the helpful info, Simon. I'll look into it. -Xiaoming On Sat, May 16, 2009 at 10:56 PM, Simon Zhou wrote: > Xiaoming, > > I am sorry that maybe my previous guesswork is wrong. > it is not caused by global_prop, because the issue still exists after I > remove the global_prop in config file. > but after I revert all the modification of this patch, VM runs pretty well, > so it maybe caused by other modification in this patch but global_prop, or > not just global_prop. I am not sure... > Thanks for your help! > Thanks > Simon > 2009/5/16 xiaoming gu > > > Hi, Simon. A workaround is to replace global_prop with early_prop in the > > used execution mode configuration file. I'll take care of this bug these > > days. Thanks. > > > > Xiaoming > > > > On Sat, May 16, 2009 at 5:04 PM, Simon Zhou > > wrote: > > > > > I think I found the origin of this issue by binary searching the > previous > > > patches, I foud that it is broken since version 747844 (747843 is OK), > so > > > I am guessing the patch of 5826 breaks this. > > > > > > To replay the error, just add -XX:gc.generate_barrier=true to command > > line > > > when running a Java application. > > > I added some of my guesswork in > > > https://issues.apache.org/jira/browse/HARMONY-5826 > > > > > > Xiaoming, Would you like to give me advice for this issue? Or is there > > some > > > workaroud for it? Thank you very much! > > > > > > Thanks > > > Simon > > > > > > 2009/5/16 Simon Zhou > > > > > > > Hi All, > > > > > > > > I am doing my GSoC2009 project of implementing weak reference in > > > > Concurrent GC. I found that as long as the gc.generate_barrier=true > is > > > set, > > > > VM will crash when it startups (int vm_init2() method). I was > following > > > this > > > > issue these days but did not work out. > > > > This issue seem to come out after milestone8, so I guess it could > be > > > > caused by some patches on Jitrino after M8. > > > >Is there anyone else being aware of that? Or could you please > > provide > > > > some information about which patch could cause it? > > > >Thank you very much! > > > > > > > > Thanks > > > > Simon > > > > > > > > -- > > > > From : simon.z...@ppi, Fudan University > > > > > > > > > > > > > > > > -- > > > From : simon.z...@ppi, Fudan University > > > > > > > > > -- > From : simon.z...@ppi, Fudan University >
Re: [drlvm][jitrino] write barrier was broken
Xiaoming, I am sorry that maybe my previous guesswork is wrong. it is not caused by global_prop, because the issue still exists after I remove the global_prop in config file. but after I revert all the modification of this patch, VM runs pretty well, so it maybe caused by other modification in this patch but global_prop, or not just global_prop. I am not sure... Thanks for your help! Thanks Simon 2009/5/16 xiaoming gu > Hi, Simon. A workaround is to replace global_prop with early_prop in the > used execution mode configuration file. I'll take care of this bug these > days. Thanks. > > Xiaoming > > On Sat, May 16, 2009 at 5:04 PM, Simon Zhou > wrote: > > > I think I found the origin of this issue by binary searching the previous > > patches, I foud that it is broken since version 747844 (747843 is OK), so > > I am guessing the patch of 5826 breaks this. > > > > To replay the error, just add -XX:gc.generate_barrier=true to command > line > > when running a Java application. > > I added some of my guesswork in > > https://issues.apache.org/jira/browse/HARMONY-5826 > > > > Xiaoming, Would you like to give me advice for this issue? Or is there > some > > workaroud for it? Thank you very much! > > > > Thanks > > Simon > > > > 2009/5/16 Simon Zhou > > > > > Hi All, > > > > > > I am doing my GSoC2009 project of implementing weak reference in > > > Concurrent GC. I found that as long as the gc.generate_barrier=true is > > set, > > > VM will crash when it startups (int vm_init2() method). I was following > > this > > > issue these days but did not work out. > > > This issue seem to come out after milestone8, so I guess it could be > > > caused by some patches on Jitrino after M8. > > >Is there anyone else being aware of that? Or could you please > provide > > > some information about which patch could cause it? > > >Thank you very much! > > > > > > Thanks > > > Simon > > > > > > -- > > > From : simon.z...@ppi, Fudan University > > > > > > > > > > > -- > > From : simon.z...@ppi, Fudan University > > > -- >From : simon.z...@ppi, Fudan University
Re: [drlvm][jitrino] write barrier was broken
Hi, Simon. A workaround is to replace global_prop with early_prop in the used execution mode configuration file. I'll take care of this bug these days. Thanks. Xiaoming On Sat, May 16, 2009 at 5:04 PM, Simon Zhou wrote: > I think I found the origin of this issue by binary searching the previous > patches, I foud that it is broken since version 747844 (747843 is OK), so > I am guessing the patch of 5826 breaks this. > > To replay the error, just add -XX:gc.generate_barrier=true to command line > when running a Java application. > I added some of my guesswork in > https://issues.apache.org/jira/browse/HARMONY-5826 > > Xiaoming, Would you like to give me advice for this issue? Or is there some > workaroud for it? Thank you very much! > > Thanks > Simon > > 2009/5/16 Simon Zhou > > > Hi All, > > > > I am doing my GSoC2009 project of implementing weak reference in > > Concurrent GC. I found that as long as the gc.generate_barrier=true is > set, > > VM will crash when it startups (int vm_init2() method). I was following > this > > issue these days but did not work out. > > This issue seem to come out after milestone8, so I guess it could be > > caused by some patches on Jitrino after M8. > >Is there anyone else being aware of that? Or could you please provide > > some information about which patch could cause it? > >Thank you very much! > > > > Thanks > > Simon > > > > -- > > From : simon.z...@ppi, Fudan University > > > > > > -- > From : simon.z...@ppi, Fudan University >
Re: [drlvm][jitrino] write barrier was broken
I think I found the origin of this issue by binary searching the previous patches, I foud that it is broken since version 747844 (747843 is OK), so I am guessing the patch of 5826 breaks this. To replay the error, just add -XX:gc.generate_barrier=true to command line when running a Java application. I added some of my guesswork in https://issues.apache.org/jira/browse/HARMONY-5826 Xiaoming, Would you like to give me advice for this issue? Or is there some workaroud for it? Thank you very much! Thanks Simon 2009/5/16 Simon Zhou > Hi All, > > I am doing my GSoC2009 project of implementing weak reference in > Concurrent GC. I found that as long as the gc.generate_barrier=true is set, > VM will crash when it startups (int vm_init2() method). I was following this > issue these days but did not work out. > This issue seem to come out after milestone8, so I guess it could be > caused by some patches on Jitrino after M8. >Is there anyone else being aware of that? Or could you please provide > some information about which patch could cause it? >Thank you very much! > > Thanks > Simon > > -- > From : simon.z...@ppi, Fudan University > -- >From : simon.z...@ppi, Fudan University
[drlvm][jitrino] write barrier was broken
Hi All, I am doing my GSoC2009 project of implementing weak reference in Concurrent GC. I found that as long as the gc.generate_barrier=true is set, VM will crash when it startups (int vm_init2() method). I was following this issue these days but did not work out. This issue seem to come out after milestone8, so I guess it could be caused by some patches on Jitrino after M8. Is there anyone else being aware of that? Or could you please provide some information about which patch could cause it? Thank you very much! Thanks Simon -- >From : simon.z...@ppi, Fudan University
Re: Fwd: [jira] Created: (HARMONY-6007) [drlvm][jit][abcd] classic abcd pass fixes
On the 0x572 day of Apache Harmony Naveen Neelakantam wrote: > Hi Egor, > > I had started to worry that this topic would be forgotten. Obviously it > hasn't been because you have been very busy! > > I will take a detailed look at your new patch this weekend and get back > to you. That way I can be sure to have a drink handy, per your > instructions.:-) JFYI: Committed revision 764315. Could not wait :) -- Egor Pasko
Fwd: [jira] Created: (HARMONY-6137) [drlvm][concurrent] AtomicLong compare and swap returning wrong indicator
I think this could be the cause of the concurrent test failures we are seeing on M9 testing. -- Forwarded message -- From: Tim Ellison (JIRA) Date: 2009/4/2 Subject: [jira] Created: (HARMONY-6137) [drlvm][concurrent] AtomicLong compare and swap returning wrong indicator To: [email protected] [drlvm][concurrent] AtomicLong compare and swap returning wrong indicator - Key: HARMONY-6137 URL: https://issues.apache.org/jira/browse/HARMONY-6137 Project: Harmony Issue Type: Bug Components: DRLVM Environment: Linux, r761319 Reporter: Tim Ellison Consider the following code that exercises AtomLong compare and swap operations: AtomicLong atomLong = new AtomicLong(1); System.out.println(atomLong.get()); System.out.println("CAS 1,-4 = " + atomLong.compareAndSet(1, -4)); System.out.println(atomLong.get()); System.out.println("CAS -5,1 = " + atomLong.compareAndSet(-5, 1)); System.out.println(atomLong.get()); I expect it to print out: 1 CAS 1,-4 = true -4 CAS -5,1 = false -4 Since the comparison of --4 and -5 fails. However when running that code on harmony r761319 I see 1 CAS 1,-4 = true -4 CAS -5,1 = true -4 i.e. the swap is not done, but the method returned true as though it had done the swap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [drlvm][GarbageCollector] SoftReferences
2009/3/26 Carlos Torrão : > Hi, > > Salvador was focusing in the behavior of the GC in the presence of > SoftReferences. For instance, if the objects are "deleted" if they don't > have any Reference (strong one) during the GC swap through the objects. If > this is true, maybe it's possible to do some kind of optimization to this > behavior of the GC to SoftReferences. Do you know if there is something like > that already developed for the DRLVM ? Yes, DRLVM has Weak References implemented including weak/soft/phantom references. Please check the source of DRLVM GC, and the source for Weak References processing is under /working_vm/vm/gc_gen/src/finalizer_weakref/. Feel free to ask questions about it. Thanks. Thanks, xiaofeng > Best regards, > Carlos Torrão > > > 2009/3/26 Xiao-Feng Li > >> Hi, Salvador, >> >> SoftReference is supported in DRLVM GC. I don't know what you mean for >> "optimization in the SoftReference". Do you mean that, SoftReferences >> are often used to implement object caching in a Java application? If >> that is what you mean, it is not what GC cares, because it is an >> optimization at application level, where SoftReferences are used as a >> handy tool to keep some dead but may-be-useful-in-future objects. >> >> In my understanding, those Weak Reference things are an utility >> provided to Java programmer to manage their objects life cycle. Java >> is supposed to manage all the objects automatically for the >> programmer, but sometimes the programmer wants to have control over >> their objects. It is a bit awkward, since Java should have been more >> intelligent to do this kind of tasks automatically for the programmer >> or with some hints from the programmer. >> >> Thanks, >> xiaofeng >> >> On Thu, Mar 26, 2009 at 3:22 AM, Salvador Canelas >> wrote: >> > Greetings >> > >> > I'm interested in the DRLVM garbage collector features. I was reading the >> > DRLVM development tasks and would like to know more about the task about >> > implementing SoftReferences. Is this list updated and this features is >> still >> > missing or it has already been implemented? If it's already implemented I >> > would like to know if there's any kind of optimization in the >> SoftReferences >> > and if caching is used in that optimization. >> > >> > Best Regards, Salvador Canelas >> > >> > >> >> >> >> -- >> http://people.apache.org/~xli <http://people.apache.org/%7Exli> >> > -- http://people.apache.org/~xli
Re: [drlvm][GarbageCollector] SoftReferences
Hi, Salvador was focusing in the behavior of the GC in the presence of SoftReferences. For instance, if the objects are "deleted" if they don't have any Reference (strong one) during the GC swap through the objects. If this is true, maybe it's possible to do some kind of optimization to this behavior of the GC to SoftReferences. Do you know if there is something like that already developed for the DRLVM ? Best regards, Carlos Torrão 2009/3/26 Xiao-Feng Li > Hi, Salvador, > > SoftReference is supported in DRLVM GC. I don't know what you mean for > "optimization in the SoftReference". Do you mean that, SoftReferences > are often used to implement object caching in a Java application? If > that is what you mean, it is not what GC cares, because it is an > optimization at application level, where SoftReferences are used as a > handy tool to keep some dead but may-be-useful-in-future objects. > > In my understanding, those Weak Reference things are an utility > provided to Java programmer to manage their objects life cycle. Java > is supposed to manage all the objects automatically for the > programmer, but sometimes the programmer wants to have control over > their objects. It is a bit awkward, since Java should have been more > intelligent to do this kind of tasks automatically for the programmer > or with some hints from the programmer. > > Thanks, > xiaofeng > > On Thu, Mar 26, 2009 at 3:22 AM, Salvador Canelas > wrote: > > Greetings > > > > I'm interested in the DRLVM garbage collector features. I was reading the > > DRLVM development tasks and would like to know more about the task about > > implementing SoftReferences. Is this list updated and this features is > still > > missing or it has already been implemented? If it's already implemented I > > would like to know if there's any kind of optimization in the > SoftReferences > > and if caching is used in that optimization. > > > > Best Regards, Salvador Canelas > > > > > > > > -- > http://people.apache.org/~xli <http://people.apache.org/%7Exli> >
Re: [drlvm][GarbageCollector] SoftReferences
Hi, Salvador, SoftReference is supported in DRLVM GC. I don't know what you mean for "optimization in the SoftReference". Do you mean that, SoftReferences are often used to implement object caching in a Java application? If that is what you mean, it is not what GC cares, because it is an optimization at application level, where SoftReferences are used as a handy tool to keep some dead but may-be-useful-in-future objects. In my understanding, those Weak Reference things are an utility provided to Java programmer to manage their objects life cycle. Java is supposed to manage all the objects automatically for the programmer, but sometimes the programmer wants to have control over their objects. It is a bit awkward, since Java should have been more intelligent to do this kind of tasks automatically for the programmer or with some hints from the programmer. Thanks, xiaofeng On Thu, Mar 26, 2009 at 3:22 AM, Salvador Canelas wrote: > Greetings > > I'm interested in the DRLVM garbage collector features. I was reading the > DRLVM development tasks and would like to know more about the task about > implementing SoftReferences. Is this list updated and this features is still > missing or it has already been implemented? If it's already implemented I > would like to know if there's any kind of optimization in the SoftReferences > and if caching is used in that optimization. > > Best Regards, Salvador Canelas > > -- http://people.apache.org/~xli
[drlvm][GarbageCollector] SoftReferences
Greetings I'm interested in the DRLVM garbage collector features. I was reading the DRLVM development tasks and would like to know more about the task about implementing SoftReferences. Is this list updated and this features is still missing or it has already been implemented? If it's already implemented I would like to know if there's any kind of optimization in the SoftReferences and if caching is used in that optimization. Best Regards, Salvador Canelas
[drlvm][GarbageCollector] SoftReferences
Greetings I'm interested in the DRLVM garbage collector features. I was reading the DRLVM development tasks and would like to know more about the task about implementing SoftReferences. Is this list updated and this features is still missing or it has already been implemented? If it's already implemented I would like to know if there's any kind of optimization in the SoftReferences and if caching is used in that optimization. Best Regards, Salvador Canelas
Re: DRLVM doesn't set java.endorsed.dirs system property
Geronimo also uses this property. So better set it.
-Jack
2009/3/14 Nathan Beyer
> Agreed.
>
> Sent from my iPhone
>
>
> On Mar 13, 2009, at 1:03 AM, Kevin Zhou wrote:
>
> Our Impl doesn't have this feature. My suggestion is to implement this
>> feature.
>>
>> On Sat, Mar 7, 2009 at 8:24 AM, Nathan Beyer wrote:
>>
>> Is there no endorsed directory feature at all or just this system
>>> property value? I know Tomcat, among others, set the endorsed
>>> directory during launch, so I'd say it's a necessary feature.
>>>
>>> -Nathan
>>>
>>> On Fri, Mar 6, 2009 at 3:53 AM, Kevin Zhou
>>> wrote:
>>>
Hi all,
When performing the given test [1] on HARMONY and RI, it shows RI
>>> provides
>>>
such "java.endorsed.dirs" SYSTEM PROPERTY while HARMONY doesn't.
Sometimes, JRE may search for JAR files in the endorsed directories in
>>> order
>>>
to run some specific applications correctly.
As for me, I think this is non-bug difference between HARMONY and RI. If
necessary, it could be implemented at VM-side.
Do we need to follow RI on this behaviour? What is your opinion? :)
[1] Sample:
public static void main(String[] args) {
System.out.println(System.getProperty("java.endorsed.dirs"));
}
>>>
Re: DRLVM doesn't set java.endorsed.dirs system property
Agreed.
Sent from my iPhone
On Mar 13, 2009, at 1:03 AM, Kevin Zhou wrote:
Our Impl doesn't have this feature. My suggestion is to implement this
feature.
On Sat, Mar 7, 2009 at 8:24 AM, Nathan Beyer
wrote:
Is there no endorsed directory feature at all or just this system
property value? I know Tomcat, among others, set the endorsed
directory during launch, so I'd say it's a necessary feature.
-Nathan
On Fri, Mar 6, 2009 at 3:53 AM, Kevin Zhou
wrote:
Hi all,
When performing the given test [1] on HARMONY and RI, it shows RI
provides
such "java.endorsed.dirs" SYSTEM PROPERTY while HARMONY doesn't.
Sometimes, JRE may search for JAR files in the endorsed
directories in
order
to run some specific applications correctly.
As for me, I think this is non-bug difference between HARMONY and
RI. If
necessary, it could be implemented at VM-side.
Do we need to follow RI on this behaviour? What is your opinion? :)
[1] Sample:
public static void main(String[] args) {
System.out.println(System.getProperty("java.endorsed.dirs"));
}
Re: DRLVM doesn't set java.endorsed.dirs system property
Our Impl doesn't have this feature. My suggestion is to implement this
feature.
On Sat, Mar 7, 2009 at 8:24 AM, Nathan Beyer wrote:
> Is there no endorsed directory feature at all or just this system
> property value? I know Tomcat, among others, set the endorsed
> directory during launch, so I'd say it's a necessary feature.
>
> -Nathan
>
> On Fri, Mar 6, 2009 at 3:53 AM, Kevin Zhou wrote:
> > Hi all,
> > When performing the given test [1] on HARMONY and RI, it shows RI
> provides
> > such "java.endorsed.dirs" SYSTEM PROPERTY while HARMONY doesn't.
> >
> > Sometimes, JRE may search for JAR files in the endorsed directories in
> order
> > to run some specific applications correctly.
> >
> > As for me, I think this is non-bug difference between HARMONY and RI. If
> > necessary, it could be implemented at VM-side.
> >
> > Do we need to follow RI on this behaviour? What is your opinion? :)
> >
> > [1] Sample:
> > public static void main(String[] args) {
> >System.out.println(System.getProperty("java.endorsed.dirs"));
> > }
> >
>
Re: Fwd: [jira] Created: (HARMONY-6007) [drlvm][jit][abcd] classic abcd pass fixes
On the 0x572 day of Apache Harmony Naveen Neelakantam wrote: > Hi Egor, > > I had started to worry that this topic would be forgotten. Obviously it > hasn't been because you have been very busy! > > I will take a detailed look at your new patch this weekend and get back > to you. That way I can be sure to have a drink handy, per your > instructions.:-) Naveen, thanks! nice to 'hear' from you. I just could not sleep well, so, to forget this I had to do something constructive :) -- Egor Pasko
Re: Fwd: [jira] Created: (HARMONY-6007) [drlvm][jit][abcd] classic abcd pass fixes
arraylen loads
if we are working with fields and not with arrays on stack.
Example:
public class field {
public Object ss = new Object();
public Object[] objs = null;
private Object[] run(int l) {
objs = new Object[l];
for (int i = l-1; i>= 0; i--) {
objs[i] = ss;
}
return objs;
}
public static void main(String[] args) {
field t = new field();
System.out.println(t.run(10)[0]);
}
}
this is probably not killing performance in real cases because there
is usually some external call in the loop that can potentially rewrite
the field (using reflection, argh).
If anyone finds more problems with bounds checks removal, please,
report with tests. To find out how many bounds checks was
detected/eliminated for each method, this DRLVM option is useful:
-XX:jit.arg.dump_abcd_stats=true, this dumps the info in the
./bounds_checks.log (Though do not forget that other optimizations can
also eliminate bounds checks as hvn,dabce,fastArrayFill).
Chapter 5. Conclusions.
Naveen, thank you thank you thank you for the great work! Without it I
would have been clueless about important problem sources for a much
longer while. Great job!
Re: Fwd: [jira] Created: (HARMONY-6007) [drlvm][jit][abcd] classic abcd pass fixes
1; i >= 0; i--) {
objs[i] = ss;
}
return objs;
}
public static void main(String[] args) {
field t = new field();
System.out.println(t.run(10)[0]);
}
}
this is probably not killing performance in real cases because there
is usually some external call in the loop that can potentially rewrite
the field (using reflection, argh).
If anyone finds more problems with bounds checks removal, please,
report with tests. To find out how many bounds checks was
detected/eliminated for each method, this DRLVM option is useful:
-XX:jit.arg.dump_abcd_stats=true, this dumps the info in the
./bounds_checks.log (Though do not forget that other optimizations can
also eliminate bounds checks as hvn,dabce,fastArrayFill).
Chapter 5. Conclusions.
Naveen, thank you thank you thank you for the great work! Without it I
would have been clueless about important problem sources for a much
longer while. Great job!
--
Egor Pasko
Re: [drlvm][vmcore]The use in M2nFrame in vmcore
Thanks a lot for you answer, it let me know more about the M2nFrame. Managed frames and native frames follow different calling conventions, and managed frames are produced by JIT. I thought M2nFrame is only used to connect managed frames and native frames, and interpreter don't produce M2nFrame, so I inferred "M2NFrame is only used in JET/OPT". But now, I know more about M2nFrame and its role in interpreter mode including unwinding and root set enumeration, so my conclusion is wrong. Thank you again! 2009/3/10 chunrong lai > hi, Yuan: > Besides the stack iteratoring and tracing (unwinding) the document > > http://harmony.apache.org/subcomponents/drlvm/developers_guide.html#About_the_Stack > also > indicate more usages of the M2nFrame: > > Container of object handles that are indirect pointers to the > Java*< > http://harmony.apache.org/subcomponents/drlvm/developers_guide.html#* > >heap. > Native code must use object handles to enable root set enumeration. > During this process, the VM traverses the list of M2nFrames for each thread > and enumerates object handles from each frame. > > Looking in the drlvm interpreter source code, the > oh_allocate_local_handle() are often seen for this. > I myself do not catch your idea that why M2NFrame is only used in JET/OPT > mode. Can you explain that? > > On Mon, Mar 9, 2009 at 3:38 PM, Yuan Zhang wrote: > > > Hello, everyone: > > I have read something about the M2nFrame described in “Developer's > > Guide"[1] and I thought the main use of M2nFrame is to handle the > > difference > > of the calling conventions between the native frames and the managed > frames > > compiled by JIT, so I concluded that M2nFrame would only be used in > > JET/OPT > > mode. However, I'm a little confused to found out that M2nFrame is also > > used > > in the interpreter mode because I think in the interpreter mode, the > native > > function is directed called by interpreter and interpreter runs in native > > frames. It seems that there is no need to use M2nFrame in interpreter, > and > > my only explanation is that using M2nFrame in the interpreter is for > stack > > iteratoring and tracing. But I'm not sure, can anybody give me some > ideas? > > Thanks! > > > > [1] > > > > > http://harmony.apache.org/subcomponents/drlvm/developers_guide.html#About_the_Stack > > >
Re: [drlvm][vmcore]The use in M2nFrame in vmcore
hi, Yuan: Besides the stack iteratoring and tracing (unwinding) the document http://harmony.apache.org/subcomponents/drlvm/developers_guide.html#About_the_Stack also indicate more usages of the M2nFrame: Container of object handles that are indirect pointers to the Java*<http://harmony.apache.org/subcomponents/drlvm/developers_guide.html#*>heap. Native code must use object handles to enable root set enumeration. During this process, the VM traverses the list of M2nFrames for each thread and enumerates object handles from each frame. Looking in the drlvm interpreter source code, the oh_allocate_local_handle() are often seen for this. I myself do not catch your idea that why M2NFrame is only used in JET/OPT mode. Can you explain that? On Mon, Mar 9, 2009 at 3:38 PM, Yuan Zhang wrote: > Hello, everyone: > I have read something about the M2nFrame described in “Developer's > Guide"[1] and I thought the main use of M2nFrame is to handle the > difference > of the calling conventions between the native frames and the managed frames > compiled by JIT, so I concluded that M2nFrame would only be used in > JET/OPT > mode. However, I'm a little confused to found out that M2nFrame is also > used > in the interpreter mode because I think in the interpreter mode, the native > function is directed called by interpreter and interpreter runs in native > frames. It seems that there is no need to use M2nFrame in interpreter, and > my only explanation is that using M2nFrame in the interpreter is for stack > iteratoring and tracing. But I'm not sure, can anybody give me some ideas? > Thanks! > > [1] > > http://harmony.apache.org/subcomponents/drlvm/developers_guide.html#About_the_Stack >
[drlvm][vmcore]The use in M2nFrame in vmcore
Hello, everyone: I have read something about the M2nFrame described in “Developer's Guide"[1] and I thought the main use of M2nFrame is to handle the difference of the calling conventions between the native frames and the managed frames compiled by JIT, so I concluded that M2nFrame would only be used in JET/OPT mode. However, I'm a little confused to found out that M2nFrame is also used in the interpreter mode because I think in the interpreter mode, the native function is directed called by interpreter and interpreter runs in native frames. It seems that there is no need to use M2nFrame in interpreter, and my only explanation is that using M2nFrame in the interpreter is for stack iteratoring and tracing. But I'm not sure, can anybody give me some ideas? Thanks! [1] http://harmony.apache.org/subcomponents/drlvm/developers_guide.html#About_the_Stack
