You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/04/22 13:29:15 UTC
[DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Hi, folks, I've made the switch of default DRLVM GC component from
GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
for one week experiment. If things go well, it might be the default GC
from then on; otherwise, it will be switched back waiting for next
chance after JavaOne. (We do not know the switch result yet, since the
testing infrastructure looks to be resting in weekends.)
To make the switch is to bring Apache Harmony an advanced GC module
which has state-of-the-art design and implementation as a
stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
garbage collection, with a couple of dynamic runtime adaptation
innovations to improve the throughput. GCv5 supports both generational
and non-generational mode. Experiments showed good performance
improvement over GCv4.1 for most workloads on parallel machines.
I have put a quick overview of Harmony GCv5 at
http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
design principle of GCv5 is to be modular (or open). This is a big
difference from GCv4.1. Hope it could lay a good foundation for the
community to develop more sophisticated GC technologies. As I know,
there are two university projects already using GCv5 for their
Harmony-based research.
We would expect some regressions during the transition phase. Let's
promptly fix the bugs exposed, and try to make the switch smooth.
Thanks,
xiaofeng
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Vladimir Ivanov <iv...@gmail.com>.
I never saw this error message. So I can not help in this case :( Sorry.
Thanks, Vladimir
On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > Thanks for the notifications. Will check the issues immediately,
> > > basically they are:
> > >
> > > StressLoader and self-hosting on Win64, and RunFinalizersOnExit on Linux64.
> > >
> > > Vladimir, would you let me know how to run the self-hosting test
> > > locally with java.exe command line? Thanks!
> >
> > To run 'self-hosting' please set JAVA_HOME to HDK and just run the HDK
> > build again to other directory (-Dtarget.dir=<>).
>
> Thanks for the helps. I ran my build in way of:
>
> C:\trunk\working_vm\build>build.bat
> -Dtarget.dir=c:\trunk\working_vm\build\hdk_build
>
> Looks like it ran well but the last step failed in copying file as
> below. I suspect the new target.dir I specified didn't work for it.
> Right? Thanks, xiaofeng
>
> ==================================
> build_deploy:
> vf_debug: verifying class org/apache/tools/ant/taskdefs/optional/jdepend/JDepend
> Task (method executeInVM(Lorg/apache/tools/ant/types/CommandlineJava;)I) couldn'
> t load class "jdepend/textui/JDepend"
> vf_debug: VerifyError: Couldn't load class: jdepend/textui/JDepend
> vf_debug: verifying class org/apache/tools/ant/taskdefs/optional/ssh/SSHExec (me
> thod execute()V) couldn't load class "com/jcraft/jsch/JSchException"
> vf_debug: VerifyError: Couldn't load class: com/jcraft/jsch/JSchException
> vf_debug: verifying class org/apache/tools/ant/taskdefs/optional/image/Image (me
> thod processFile(Ljava/io/File;)V) couldn't load class "javax/media/jai/PlanarIm
> age"
> vf_debug: VerifyError: Couldn't load class: javax/media/jai/PlanarImage
> [copy] Copying 2 files to C:\trunk\working_vm\build\win_ia32_msvc_debug\dep
> loy\jdk\jre\bin\default
> [copy] Copying C:\trunk\working_vm\build\win_ia32_msvc_debug\semis\vm\vmi\_
> bin\vmi.dll to C:\trunk\working_vm\build\win_ia32_msvc_debug\deploy\jdk\jre\bin\
> default\vmi.dll
>
> BUILD FAILED
> C:\trunk\working_vm\build\make\build.xml:466: The following error occurred while
> executing this line:
> C:\trunk\working_vm\build\make\build.xml:468: The following error occurred while
> executing this line:
> C:\trunk\working_vm\build\make\build.xml:696: The following error occurred while
> executing this line:
> C:\trunk\working_vm\build\make\build.xml:726: Failed to copy C:\trunk\working_vm
> \build\win_ia32_msvc_debug\semis\vm\vmi\_bin\vmi.dll to C:\trunk\working_vm\buil
> d\win_ia32_msvc_debug\deploy\jdk\jre\bin\default\vmi.dll due to C:\trunk\working
> _vm\build\win_ia32_msvc_debug\deploy\jdk\jre\bin\default\vmi.dll and I couldn't
> delete the corrupt C:\trunk\working_vm\build\win_ia32_msvc_debug\deploy\jdk\jre\
> bin\default\vmi.dll
> =================================================
>
> > thanks, Vladimir
> >
> >
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > > Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> > > > x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
> > > >
> > > > Thanks, Vladimir
> > > >
> > > > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > > > I think one week is enough to investigate all possible issues with GCv5.
> > > > > Let's start.
> > > > > First of all, what should we do with failed tests on finalization,
> > > > > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> > > > >
> > > > > The second issue: the self-hosting (build of HDK on HDK) project is
> > > > > failed now on Windows x86_64 with message like that (stack trace is
> > > > > below):
> > > > > [exec] [javac] 1. ERROR in
> > > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > > [exec] [javac] (at line 0)
> > > > > [exec] [javac] /*
> > > > > [exec] [javac] ^
> > > > > [exec] [javac] Internal compiler error
> > > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > > number for one byte must be positive.
> > > > >
> > > > > Note, it is not the GCv5 issue but now it reproduced very often.
> > > > >
> > > > > thanks, Vladimir
> > > > >
> > > > > ---- self-hosting failure ----------------------------
> > > > > [exec] -compile:
> > > > > [exec] [mkdir] Created dir:
> > > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > > [exec] [javac] Compiling 3654 source files to
> > > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > > [exec] [javac] ----------
> > > > > [exec] [javac] 1. ERROR in
> > > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > > [exec] [javac] (at line 0)
> > > > > [exec] [javac] /*
> > > > > [exec] [javac] ^
> > > > > [exec] [javac] Internal compiler error
> > > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > > number for one byte must be positive.
> > > > > [exec] [javac] at
> > > > > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > > > > [exec] [javac] at
> > > > > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > > > > [exec] [javac] at
> > > > > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > > > > [exec] [javac] at
> > > > > java.io.InputStreamReader.<init>(Unknown Source)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:193)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7707)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:371)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2949)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > > > > [exec] [javac] at
> > > > > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > > > [exec] [javac] at
> > > > > java.lang.reflect.Method.invoke(Method.java:381)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java:79)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> > > > >
> > > > > [exec] [javac] ----------
> > > > > [exec] [javac] Characters number for one byte must be positive.
> > > > >
> > > > > [exec] BUILD FAILED
> > > > > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > > > > following error occurred while executing this line:
> > > > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > > > > The following error occurred while executing this line:
> > > > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-java.xml:130:
> > > > > Compile failed; see the compiler error output for details.
> > > > > ------------------------------------------------------------
> > > > >
> > > > >
> > > > > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > Nice document Xiao Feng. And it goes without saying, good work on gcv5.
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > > > > for one week experiment. If things go well, it might be the default GC
> > > > > > > from then on; otherwise, it will be switched back waiting for next
> > > > > > > chance after JavaOne. (We do not know the switch result yet, since the
> > > > > > > testing infrastructure looks to be resting in weekends.)
> > > > > > >
> > > > > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > > > > which has state-of-the-art design and implementation as a
> > > > > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > > > > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > > > > innovations to improve the throughput. GCv5 supports both generational
> > > > > > > and non-generational mode. Experiments showed good performance
> > > > > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > > > > >
> > > > > > > I have put a quick overview of Harmony GCv5 at
> > > > > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > > > > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > > > > community to develop more sophisticated GC technologies. As I know,
> > > > > > > there are two university projects already using GCv5 for their
> > > > > > > Harmony-based research.
> > > > > > >
> > > > > > > We would expect some regressions during the transition phase. Let's
> > > > > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > xiaofeng
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > Thanks for the notifications. Will check the issues immediately,
> > basically they are:
> >
> > StressLoader and self-hosting on Win64, and RunFinalizersOnExit on Linux64.
> >
> > Vladimir, would you let me know how to run the self-hosting test
> > locally with java.exe command line? Thanks!
>
> To run 'self-hosting' please set JAVA_HOME to HDK and just run the HDK
> build again to other directory (-Dtarget.dir=<>).
Thanks for the helps. I ran my build in way of:
C:\trunk\working_vm\build>build.bat
-Dtarget.dir=c:\trunk\working_vm\build\hdk_build
Looks like it ran well but the last step failed in copying file as
below. I suspect the new target.dir I specified didn't work for it.
Right? Thanks, xiaofeng
==================================
build_deploy:
vf_debug: verifying class org/apache/tools/ant/taskdefs/optional/jdepend/JDepend
Task (method executeInVM(Lorg/apache/tools/ant/types/CommandlineJava;)I) couldn'
t load class "jdepend/textui/JDepend"
vf_debug: VerifyError: Couldn't load class: jdepend/textui/JDepend
vf_debug: verifying class org/apache/tools/ant/taskdefs/optional/ssh/SSHExec (me
thod execute()V) couldn't load class "com/jcraft/jsch/JSchException"
vf_debug: VerifyError: Couldn't load class: com/jcraft/jsch/JSchException
vf_debug: verifying class org/apache/tools/ant/taskdefs/optional/image/Image (me
thod processFile(Ljava/io/File;)V) couldn't load class "javax/media/jai/PlanarIm
age"
vf_debug: VerifyError: Couldn't load class: javax/media/jai/PlanarImage
[copy] Copying 2 files to C:\trunk\working_vm\build\win_ia32_msvc_debug\dep
loy\jdk\jre\bin\default
[copy] Copying C:\trunk\working_vm\build\win_ia32_msvc_debug\semis\vm\vmi\_
bin\vmi.dll to C:\trunk\working_vm\build\win_ia32_msvc_debug\deploy\jdk\jre\bin\
default\vmi.dll
BUILD FAILED
C:\trunk\working_vm\build\make\build.xml:466: The following error occurred while
executing this line:
C:\trunk\working_vm\build\make\build.xml:468: The following error occurred while
executing this line:
C:\trunk\working_vm\build\make\build.xml:696: The following error occurred while
executing this line:
C:\trunk\working_vm\build\make\build.xml:726: Failed to copy C:\trunk\working_vm
\build\win_ia32_msvc_debug\semis\vm\vmi\_bin\vmi.dll to C:\trunk\working_vm\buil
d\win_ia32_msvc_debug\deploy\jdk\jre\bin\default\vmi.dll due to C:\trunk\working
_vm\build\win_ia32_msvc_debug\deploy\jdk\jre\bin\default\vmi.dll and I couldn't
delete the corrupt C:\trunk\working_vm\build\win_ia32_msvc_debug\deploy\jdk\jre\
bin\default\vmi.dll
=================================================
> thanks, Vladimir
>
>
> >
> > Thanks,
> > xiaofeng
> >
> > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> > > x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
> > >
> > > Thanks, Vladimir
> > >
> > > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > > I think one week is enough to investigate all possible issues with GCv5.
> > > > Let's start.
> > > > First of all, what should we do with failed tests on finalization,
> > > > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> > > >
> > > > The second issue: the self-hosting (build of HDK on HDK) project is
> > > > failed now on Windows x86_64 with message like that (stack trace is
> > > > below):
> > > > [exec] [javac] 1. ERROR in
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > [exec] [javac] (at line 0)
> > > > [exec] [javac] /*
> > > > [exec] [javac] ^
> > > > [exec] [javac] Internal compiler error
> > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > number for one byte must be positive.
> > > >
> > > > Note, it is not the GCv5 issue but now it reproduced very often.
> > > >
> > > > thanks, Vladimir
> > > >
> > > > ---- self-hosting failure ----------------------------
> > > > [exec] -compile:
> > > > [exec] [mkdir] Created dir:
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > [exec] [javac] Compiling 3654 source files to
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > [exec] [javac] ----------
> > > > [exec] [javac] 1. ERROR in
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > [exec] [javac] (at line 0)
> > > > [exec] [javac] /*
> > > > [exec] [javac] ^
> > > > [exec] [javac] Internal compiler error
> > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > number for one byte must be positive.
> > > > [exec] [javac] at
> > > > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > > > [exec] [javac] at
> > > > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > > > [exec] [javac] at
> > > > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > > > [exec] [javac] at
> > > > java.io.InputStreamReader.<init>(Unknown Source)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:193)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7707)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:371)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2949)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > > > [exec] [javac] at
> > > > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > > [exec] [javac] at
> > > > java.lang.reflect.Method.invoke(Method.java:381)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java:79)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> > > >
> > > > [exec] [javac] ----------
> > > > [exec] [javac] Characters number for one byte must be positive.
> > > >
> > > > [exec] BUILD FAILED
> > > > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > > > following error occurred while executing this line:
> > > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > > > The following error occurred while executing this line:
> > > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-java.xml:130:
> > > > Compile failed; see the compiler error output for details.
> > > > ------------------------------------------------------------
> > > >
> > > >
> > > > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > Nice document Xiao Feng. And it goes without saying, good work on gcv5.
> > > > >
> > > > > Rana
> > > > >
> > > > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > > > for one week experiment. If things go well, it might be the default GC
> > > > > > from then on; otherwise, it will be switched back waiting for next
> > > > > > chance after JavaOne. (We do not know the switch result yet, since the
> > > > > > testing infrastructure looks to be resting in weekends.)
> > > > > >
> > > > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > > > which has state-of-the-art design and implementation as a
> > > > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > > > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > > > innovations to improve the throughput. GCv5 supports both generational
> > > > > > and non-generational mode. Experiments showed good performance
> > > > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > > > >
> > > > > > I have put a quick overview of Harmony GCv5 at
> > > > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > > > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > > > community to develop more sophisticated GC technologies. As I know,
> > > > > > there are two university projects already using GCv5 for their
> > > > > > Harmony-based research.
> > > > > >
> > > > > > We would expect some regressions during the transition phase. Let's
> > > > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > > > >
> > > > > > Thanks,
> > > > > > xiaofeng
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> Thanks for the notifications. Will check the issues immediately,
> basically they are:
>
> StressLoader and self-hosting on Win64, and RunFinalizersOnExit on Linux64.
>
> Vladimir, would you let me know how to run the self-hosting test
> locally with java.exe command line? Thanks!
To run 'self-hosting' please set JAVA_HOME to HDK and just run the HDK
build again to other directory (-Dtarget.dir=<>).
thanks, Vladimir
>
> Thanks,
> xiaofeng
>
> On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> > x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
> >
> > Thanks, Vladimir
> >
> > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > I think one week is enough to investigate all possible issues with GCv5.
> > > Let's start.
> > > First of all, what should we do with failed tests on finalization,
> > > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> > >
> > > The second issue: the self-hosting (build of HDK on HDK) project is
> > > failed now on Windows x86_64 with message like that (stack trace is
> > > below):
> > > [exec] [javac] 1. ERROR in
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > [exec] [javac] (at line 0)
> > > [exec] [javac] /*
> > > [exec] [javac] ^
> > > [exec] [javac] Internal compiler error
> > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > number for one byte must be positive.
> > >
> > > Note, it is not the GCv5 issue but now it reproduced very often.
> > >
> > > thanks, Vladimir
> > >
> > > ---- self-hosting failure ----------------------------
> > > [exec] -compile:
> > > [exec] [mkdir] Created dir:
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > [exec] [javac] Compiling 3654 source files to
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > [exec] [javac] ----------
> > > [exec] [javac] 1. ERROR in
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > [exec] [javac] (at line 0)
> > > [exec] [javac] /*
> > > [exec] [javac] ^
> > > [exec] [javac] Internal compiler error
> > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > number for one byte must be positive.
> > > [exec] [javac] at
> > > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > > [exec] [javac] at
> > > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > > [exec] [javac] at
> > > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > > [exec] [javac] at
> > > java.io.InputStreamReader.<init>(Unknown Source)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:193)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7707)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:371)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2949)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > > [exec] [javac] at
> > > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > [exec] [javac] at
> > > java.lang.reflect.Method.invoke(Method.java:381)
> > > [exec] [javac] at
> > > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java:79)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > > [exec] [javac] at
> > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > > [exec] [javac] at
> > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> > >
> > > [exec] [javac] ----------
> > > [exec] [javac] Characters number for one byte must be positive.
> > >
> > > [exec] BUILD FAILED
> > > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > > following error occurred while executing this line:
> > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > > The following error occurred while executing this line:
> > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-java.xml:130:
> > > Compile failed; see the compiler error output for details.
> > > ------------------------------------------------------------
> > >
> > >
> > > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > Nice document Xiao Feng. And it goes without saying, good work on gcv5.
> > > >
> > > > Rana
> > > >
> > > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > > for one week experiment. If things go well, it might be the default GC
> > > > > from then on; otherwise, it will be switched back waiting for next
> > > > > chance after JavaOne. (We do not know the switch result yet, since the
> > > > > testing infrastructure looks to be resting in weekends.)
> > > > >
> > > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > > which has state-of-the-art design and implementation as a
> > > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > > innovations to improve the throughput. GCv5 supports both generational
> > > > > and non-generational mode. Experiments showed good performance
> > > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > > >
> > > > > I have put a quick overview of Harmony GCv5 at
> > > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > > community to develop more sophisticated GC technologies. As I know,
> > > > > there are two university projects already using GCv5 for their
> > > > > Harmony-based research.
> > > > >
> > > > > We would expect some regressions during the transition phase. Let's
> > > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > >
> > >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> Thanks for the notifications. Will check the issues immediately,
> basically they are:
>
> StressLoader and self-hosting on Win64, and RunFinalizersOnExit on Linux64.
RunFinalizersOnExit failure on Linux64 was fixed as well.
Thanks,
xiaofeng
> Vladimir, would you let me know how to run the self-hosting test
> locally with java.exe command line? Thanks!
>
> Thanks,
> xiaofeng
>
> On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> > x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
> >
> > Thanks, Vladimir
> >
> > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > I think one week is enough to investigate all possible issues with GCv5.
> > > Let's start.
> > > First of all, what should we do with failed tests on finalization,
> > > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> > >
> > > The second issue: the self-hosting (build of HDK on HDK) project is
> > > failed now on Windows x86_64 with message like that (stack trace is
> > > below):
> > > [exec] [javac] 1. ERROR in
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > [exec] [javac] (at line 0)
> > > [exec] [javac] /*
> > > [exec] [javac] ^
> > > [exec] [javac] Internal compiler error
> > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > number for one byte must be positive.
> > >
> > > Note, it is not the GCv5 issue but now it reproduced very often.
> > >
> > > thanks, Vladimir
> > >
> > > ---- self-hosting failure ----------------------------
> > > [exec] -compile:
> > > [exec] [mkdir] Created dir:
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > [exec] [javac] Compiling 3654 source files to
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > [exec] [javac] ----------
> > > [exec] [javac] 1. ERROR in
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > [exec] [javac] (at line 0)
> > > [exec] [javac] /*
> > > [exec] [javac] ^
> > > [exec] [javac] Internal compiler error
> > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > number for one byte must be positive.
> > > [exec] [javac] at
> > > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > > [exec] [javac] at
> > > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > > [exec] [javac] at
> > > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > > [exec] [javac] at
> > > java.io.InputStreamReader.<init>(Unknown Source)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:193)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7707)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:371)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2949)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > > [exec] [javac] at
> > > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > [exec] [javac] at
> > > java.lang.reflect.Method.invoke(Method.java:381)
> > > [exec] [javac] at
> > > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java:79)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > > [exec] [javac] at
> > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > > [exec] [javac] at
> > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> > >
> > > [exec] [javac] ----------
> > > [exec] [javac] Characters number for one byte must be positive.
> > >
> > > [exec] BUILD FAILED
> > > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > > following error occurred while executing this line:
> > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > > The following error occurred while executing this line:
> > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-java.xml:130:
> > > Compile failed; see the compiler error output for details.
> > > ------------------------------------------------------------
> > >
> > >
> > > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > Nice document Xiao Feng. And it goes without saying, good work on gcv5.
> > > >
> > > > Rana
> > > >
> > > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > > for one week experiment. If things go well, it might be the default GC
> > > > > from then on; otherwise, it will be switched back waiting for next
> > > > > chance after JavaOne. (We do not know the switch result yet, since the
> > > > > testing infrastructure looks to be resting in weekends.)
> > > > >
> > > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > > which has state-of-the-art design and implementation as a
> > > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > > innovations to improve the throughput. GCv5 supports both generational
> > > > > and non-generational mode. Experiments showed good performance
> > > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > > >
> > > > > I have put a quick overview of Harmony GCv5 at
> > > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > > community to develop more sophisticated GC technologies. As I know,
> > > > > there are two university projects already using GCv5 for their
> > > > > Harmony-based research.
> > > > >
> > > > > We would expect some regressions during the transition phase. Let's
> > > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > >
> > >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
http://xiao-feng.blogspot.com
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thanks for the notifications. Will check the issues immediately,
basically they are:
StressLoader and self-hosting on Win64, and RunFinalizersOnExit on Linux64.
Vladimir, would you let me know how to run the self-hosting test
locally with java.exe command line? Thanks!
Thanks,
xiaofeng
On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
>
> Thanks, Vladimir
>
> On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > I think one week is enough to investigate all possible issues with GCv5.
> > Let's start.
> > First of all, what should we do with failed tests on finalization,
> > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> >
> > The second issue: the self-hosting (build of HDK on HDK) project is
> > failed now on Windows x86_64 with message like that (stack trace is
> > below):
> > [exec] [javac] 1. ERROR in
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > [exec] [javac] (at line 0)
> > [exec] [javac] /*
> > [exec] [javac] ^
> > [exec] [javac] Internal compiler error
> > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > number for one byte must be positive.
> >
> > Note, it is not the GCv5 issue but now it reproduced very often.
> >
> > thanks, Vladimir
> >
> > ---- self-hosting failure ----------------------------
> > [exec] -compile:
> > [exec] [mkdir] Created dir:
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > [exec] [javac] Compiling 3654 source files to
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > [exec] [javac] ----------
> > [exec] [javac] 1. ERROR in
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > [exec] [javac] (at line 0)
> > [exec] [javac] /*
> > [exec] [javac] ^
> > [exec] [javac] Internal compiler error
> > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > number for one byte must be positive.
> > [exec] [javac] at
> > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > [exec] [javac] at
> > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > [exec] [javac] at
> > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > [exec] [javac] at
> > java.io.InputStreamReader.<init>(Unknown Source)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:193)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7707)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:371)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2949)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > [exec] [javac] at
> > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > [exec] [javac] at
> > java.lang.reflect.Method.invoke(Method.java:381)
> > [exec] [javac] at
> > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java:79)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > [exec] [javac] at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > [exec] [javac] at
> > org.apache.tools.ant.Task.perform(Task.java:364)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.execute(Target.java:341)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > [exec] [javac] at
> > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > [exec] [javac] at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > [exec] [javac] at
> > org.apache.tools.ant.Task.perform(Task.java:364)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.execute(Target.java:341)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > [exec] [javac] at
> > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > [exec] [javac] at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > [exec] [javac] at
> > org.apache.tools.ant.Task.perform(Task.java:364)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.execute(Target.java:341)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > [exec] [javac] at
> > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > [exec] [javac] at
> > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > [exec] [javac] at
> > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > [exec] [javac] at
> > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > [exec] [javac] at
> > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> >
> > [exec] [javac] ----------
> > [exec] [javac] Characters number for one byte must be positive.
> >
> > [exec] BUILD FAILED
> > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > following error occurred while executing this line:
> > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > The following error occurred while executing this line:
> > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-java.xml:130:
> > Compile failed; see the compiler error output for details.
> > ------------------------------------------------------------
> >
> >
> > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > Nice document Xiao Feng. And it goes without saying, good work on gcv5.
> > >
> > > Rana
> > >
> > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > for one week experiment. If things go well, it might be the default GC
> > > > from then on; otherwise, it will be switched back waiting for next
> > > > chance after JavaOne. (We do not know the switch result yet, since the
> > > > testing infrastructure looks to be resting in weekends.)
> > > >
> > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > which has state-of-the-art design and implementation as a
> > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > innovations to improve the throughput. GCv5 supports both generational
> > > > and non-generational mode. Experiments showed good performance
> > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > >
> > > > I have put a quick overview of Harmony GCv5 at
> > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > community to develop more sophisticated GC technologies. As I know,
> > > > there are two university projects already using GCv5 for their
> > > > Harmony-based research.
> > > >
> > > > We would expect some regressions during the transition phase. Let's
> > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > >
> >
>
--
http://xiao-feng.blogspot.com
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Vladimir Ivanov <iv...@gmail.com>.
In my case this test executed for 40 minutes of CPU time with 99% CPU
usage during this period. Yes, it can be just long test..
thanks, Vladimir
On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> One way to know if it hangs or is slowly crawling would be to check
> the system process status. For example, in Windows, "task manager"
> would show 99% CPU(s) usage and the java.exe process keeps activities
> with page faults or something changed visibly. In Linux, "top" can be
> a good tool as well.
>
> Thanks,
> xiaofeng
>
> On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > Looks like StressLoader was not hang up, it was just too slow on
> > 64-bit machine.
> >
> > Thanks,
> > xiaofeng
> >
> > On 4/23/07, chunrong lai <ch...@gmail.com> wrote:
> > > I could not reproduce the Windows X86_64 hangs in my testing.
> > > I tried the classloader.StressLoader in my Windows x86_64 by two times.
> > > It reported "PASSED" finally. The running time was 25mins in one run, and
> > > 30mins in another run.
> > >
> > > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > >
> > > > Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> > > > x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
> > > >
> > > > Thanks, Vladimir
> > > >
> > > > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > > > I think one week is enough to investigate all possible issues with GCv5.
> > > > > Let's start.
> > > > > First of all, what should we do with failed tests on finalization,
> > > > > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> > > > >
> > > > > The second issue: the self-hosting (build of HDK on HDK) project is
> > > > > failed now on Windows x86_64 with message like that (stack trace is
> > > > > below):
> > > > > [exec] [javac] 1. ERROR in
> > > > >
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > > [exec] [javac] (at line 0)
> > > > > [exec] [javac] /*
> > > > > [exec] [javac] ^
> > > > > [exec] [javac] Internal compiler error
> > > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > > number for one byte must be positive.
> > > > >
> > > > > Note, it is not the GCv5 issue but now it reproduced very often.
> > > > >
> > > > > thanks, Vladimir
> > > > >
> > > > > ---- self-hosting failure ----------------------------
> > > > > [exec] -compile:
> > > > > [exec] [mkdir] Created dir:
> > > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > > [exec] [javac] Compiling 3654 source files to
> > > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > > [exec] [javac] ----------
> > > > > [exec] [javac] 1. ERROR in
> > > > >
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > > [exec] [javac] (at line 0)
> > > > > [exec] [javac] /*
> > > > > [exec] [javac] ^
> > > > > [exec] [javac] Internal compiler error
> > > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > > number for one byte must be positive.
> > > > > [exec] [javac] at
> > > > > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > > > > [exec] [javac] at
> > > > > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > > > > [exec] [javac] at
> > > > > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > > > > [exec] [javac] at
> > > > > java.io.InputStreamReader.<init>(Unknown Source)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(
> > > > Util.java:193)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java
> > > > :70)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(
> > > > CompilationUnit.java:58)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java
> > > > :7707)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java
> > > > :371)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(
> > > > Main.java:2949)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > > > > [exec] [javac] at
> > > > > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > > > [exec] [javac] at
> > > > > java.lang.reflect.Method.invoke(Method.java:381)
> > > > > [exec] [javac] at
> > > > > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java
> > > > :79)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> > > > SingleCheckExecutor.java:37)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> > > > SingleCheckExecutor.java:37)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(
> > > > DefaultExecutor.java:40)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > > > > [exec] [javac] at
> > > > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> > > > >
> > > > > [exec] [javac] ----------
> > > > > [exec] [javac] Characters number for one byte must be positive.
> > > > >
> > > > > [exec] BUILD FAILED
> > > > > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > > > > following error occurred while executing this line:
> > > > > [exec]
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > > > > The following error occurred while executing this line:
> > > > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-
> > > > java.xml:130:
> > > > > Compile failed; see the compiler error output for details.
> > > > > ------------------------------------------------------------
> > > > >
> > > > >
> > > > > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > > Nice document Xiao Feng. And it goes without saying, good work on
> > > > gcv5.
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > > > > for one week experiment. If things go well, it might be the default
> > > > GC
> > > > > > > from then on; otherwise, it will be switched back waiting for next
> > > > > > > chance after JavaOne. (We do not know the switch result yet, since
> > > > the
> > > > > > > testing infrastructure looks to be resting in weekends.)
> > > > > > >
> > > > > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > > > > which has state-of-the-art design and implementation as a
> > > > > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases
> > > > of
> > > > > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > > > > innovations to improve the throughput. GCv5 supports both
> > > > generational
> > > > > > > and non-generational mode. Experiments showed good performance
> > > > > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > > > > >
> > > > > > > I have put a quick overview of Harmony GCv5 at
> > > > > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A
> > > > basic
> > > > > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > > > > community to develop more sophisticated GC technologies. As I know,
> > > > > > > there are two university projects already using GCv5 for their
> > > > > > > Harmony-based research.
> > > > > > >
> > > > > > > We would expect some regressions during the transition phase. Let's
> > > > > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > xiaofeng
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Xiao-Feng Li <xi...@gmail.com>.
One way to know if it hangs or is slowly crawling would be to check
the system process status. For example, in Windows, "task manager"
would show 99% CPU(s) usage and the java.exe process keeps activities
with page faults or something changed visibly. In Linux, "top" can be
a good tool as well.
Thanks,
xiaofeng
On 4/23/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> Looks like StressLoader was not hang up, it was just too slow on
> 64-bit machine.
>
> Thanks,
> xiaofeng
>
> On 4/23/07, chunrong lai <ch...@gmail.com> wrote:
> > I could not reproduce the Windows X86_64 hangs in my testing.
> > I tried the classloader.StressLoader in my Windows x86_64 by two times.
> > It reported "PASSED" finally. The running time was 25mins in one run, and
> > 30mins in another run.
> >
> > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > >
> > > Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> > > x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
> > >
> > > Thanks, Vladimir
> > >
> > > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > > I think one week is enough to investigate all possible issues with GCv5.
> > > > Let's start.
> > > > First of all, what should we do with failed tests on finalization,
> > > > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> > > >
> > > > The second issue: the self-hosting (build of HDK on HDK) project is
> > > > failed now on Windows x86_64 with message like that (stack trace is
> > > > below):
> > > > [exec] [javac] 1. ERROR in
> > > >
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > [exec] [javac] (at line 0)
> > > > [exec] [javac] /*
> > > > [exec] [javac] ^
> > > > [exec] [javac] Internal compiler error
> > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > number for one byte must be positive.
> > > >
> > > > Note, it is not the GCv5 issue but now it reproduced very often.
> > > >
> > > > thanks, Vladimir
> > > >
> > > > ---- self-hosting failure ----------------------------
> > > > [exec] -compile:
> > > > [exec] [mkdir] Created dir:
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > [exec] [javac] Compiling 3654 source files to
> > > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > > [exec] [javac] ----------
> > > > [exec] [javac] 1. ERROR in
> > > >
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > > [exec] [javac] (at line 0)
> > > > [exec] [javac] /*
> > > > [exec] [javac] ^
> > > > [exec] [javac] Internal compiler error
> > > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > > number for one byte must be positive.
> > > > [exec] [javac] at
> > > > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > > > [exec] [javac] at
> > > > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > > > [exec] [javac] at
> > > > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > > > [exec] [javac] at
> > > > java.io.InputStreamReader.<init>(Unknown Source)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(
> > > Util.java:193)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java
> > > :70)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(
> > > CompilationUnit.java:58)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java
> > > :7707)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java
> > > :371)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(
> > > Main.java:2949)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > > > [exec] [javac] at
> > > > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > > [exec] [javac] at
> > > > java.lang.reflect.Method.invoke(Method.java:381)
> > > > [exec] [javac] at
> > > > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java
> > > :79)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> > > SingleCheckExecutor.java:37)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> > > SingleCheckExecutor.java:37)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(
> > > DefaultExecutor.java:40)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > > > [exec] [javac] at
> > > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> > > >
> > > > [exec] [javac] ----------
> > > > [exec] [javac] Characters number for one byte must be positive.
> > > >
> > > > [exec] BUILD FAILED
> > > > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > > > following error occurred while executing this line:
> > > > [exec]
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > > > The following error occurred while executing this line:
> > > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-
> > > java.xml:130:
> > > > Compile failed; see the compiler error output for details.
> > > > ------------------------------------------------------------
> > > >
> > > >
> > > > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > Nice document Xiao Feng. And it goes without saying, good work on
> > > gcv5.
> > > > >
> > > > > Rana
> > > > >
> > > > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > > > for one week experiment. If things go well, it might be the default
> > > GC
> > > > > > from then on; otherwise, it will be switched back waiting for next
> > > > > > chance after JavaOne. (We do not know the switch result yet, since
> > > the
> > > > > > testing infrastructure looks to be resting in weekends.)
> > > > > >
> > > > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > > > which has state-of-the-art design and implementation as a
> > > > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases
> > > of
> > > > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > > > innovations to improve the throughput. GCv5 supports both
> > > generational
> > > > > > and non-generational mode. Experiments showed good performance
> > > > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > > > >
> > > > > > I have put a quick overview of Harmony GCv5 at
> > > > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A
> > > basic
> > > > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > > > community to develop more sophisticated GC technologies. As I know,
> > > > > > there are two university projects already using GCv5 for their
> > > > > > Harmony-based research.
> > > > > >
> > > > > > We would expect some regressions during the transition phase. Let's
> > > > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > > > >
> > > > > > Thanks,
> > > > > > xiaofeng
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
http://xiao-feng.blogspot.com
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Xiao-Feng Li <xi...@gmail.com>.
Looks like StressLoader was not hang up, it was just too slow on
64-bit machine.
Thanks,
xiaofeng
On 4/23/07, chunrong lai <ch...@gmail.com> wrote:
> I could not reproduce the Windows X86_64 hangs in my testing.
> I tried the classloader.StressLoader in my Windows x86_64 by two times.
> It reported "PASSED" finally. The running time was 25mins in one run, and
> 30mins in another run.
>
> On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> >
> > Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> > x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
> >
> > Thanks, Vladimir
> >
> > On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > I think one week is enough to investigate all possible issues with GCv5.
> > > Let's start.
> > > First of all, what should we do with failed tests on finalization,
> > > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> > >
> > > The second issue: the self-hosting (build of HDK on HDK) project is
> > > failed now on Windows x86_64 with message like that (stack trace is
> > > below):
> > > [exec] [javac] 1. ERROR in
> > >
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > [exec] [javac] (at line 0)
> > > [exec] [javac] /*
> > > [exec] [javac] ^
> > > [exec] [javac] Internal compiler error
> > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > number for one byte must be positive.
> > >
> > > Note, it is not the GCv5 issue but now it reproduced very often.
> > >
> > > thanks, Vladimir
> > >
> > > ---- self-hosting failure ----------------------------
> > > [exec] -compile:
> > > [exec] [mkdir] Created dir:
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > [exec] [javac] Compiling 3654 source files to
> > > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > > [exec] [javac] ----------
> > > [exec] [javac] 1. ERROR in
> > >
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > > [exec] [javac] (at line 0)
> > > [exec] [javac] /*
> > > [exec] [javac] ^
> > > [exec] [javac] Internal compiler error
> > > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > > number for one byte must be positive.
> > > [exec] [javac] at
> > > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > > [exec] [javac] at
> > > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > > [exec] [javac] at
> > > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > > [exec] [javac] at
> > > java.io.InputStreamReader.<init>(Unknown Source)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(
> > Util.java:193)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java
> > :70)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(
> > CompilationUnit.java:58)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java
> > :7707)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java
> > :371)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(
> > Main.java:2949)
> > > [exec] [javac] at
> > > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > > [exec] [javac] at
> > > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > [exec] [javac] at
> > > java.lang.reflect.Method.invoke(Method.java:381)
> > > [exec] [javac] at
> > > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java
> > :79)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> > SingleCheckExecutor.java:37)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> > SingleCheckExecutor.java:37)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > > [exec] [javac] at
> > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Task.perform(Task.java:364)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.execute(Target.java:341)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > > [exec] [javac] at
> > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(
> > DefaultExecutor.java:40)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > > [exec] [javac] at
> > > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > > [exec] [javac] at
> > > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > > [exec] [javac] at
> > > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> > >
> > > [exec] [javac] ----------
> > > [exec] [javac] Characters number for one byte must be positive.
> > >
> > > [exec] BUILD FAILED
> > > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > > following error occurred while executing this line:
> > > [exec]
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > > The following error occurred while executing this line:
> > > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-
> > java.xml:130:
> > > Compile failed; see the compiler error output for details.
> > > ------------------------------------------------------------
> > >
> > >
> > > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > Nice document Xiao Feng. And it goes without saying, good work on
> > gcv5.
> > > >
> > > > Rana
> > > >
> > > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > > for one week experiment. If things go well, it might be the default
> > GC
> > > > > from then on; otherwise, it will be switched back waiting for next
> > > > > chance after JavaOne. (We do not know the switch result yet, since
> > the
> > > > > testing infrastructure looks to be resting in weekends.)
> > > > >
> > > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > > which has state-of-the-art design and implementation as a
> > > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases
> > of
> > > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > > innovations to improve the throughput. GCv5 supports both
> > generational
> > > > > and non-generational mode. Experiments showed good performance
> > > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > > >
> > > > > I have put a quick overview of Harmony GCv5 at
> > > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A
> > basic
> > > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > > community to develop more sophisticated GC technologies. As I know,
> > > > > there are two university projects already using GCv5 for their
> > > > > Harmony-based research.
> > > > >
> > > > > We would expect some regressions during the transition phase. Let's
> > > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > > >
> > > > > Thanks,
> > > > > xiaofeng
> > > > >
> > > >
> > >
> >
>
--
http://xiao-feng.blogspot.com
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by chunrong lai <ch...@gmail.com>.
I could not reproduce the Windows X86_64 hangs in my testing.
I tried the classloader.StressLoader in my Windows x86_64 by two times.
It reported "PASSED" finally. The running time was 25mins in one run, and
30mins in another run.
On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
>
> Also the DRLVM smoke test classloader.StressLoader hangs on Windows
> x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
>
> Thanks, Vladimir
>
> On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > I think one week is enough to investigate all possible issues with GCv5.
> > Let's start.
> > First of all, what should we do with failed tests on finalization,
> > like gc.RunFinalizersOnExit (failed on Linux x86_64)?
> >
> > The second issue: the self-hosting (build of HDK on HDK) project is
> > failed now on Windows x86_64 with message like that (stack trace is
> > below):
> > [exec] [javac] 1. ERROR in
> >
> C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > [exec] [javac] (at line 0)
> > [exec] [javac] /*
> > [exec] [javac] ^
> > [exec] [javac] Internal compiler error
> > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > number for one byte must be positive.
> >
> > Note, it is not the GCv5 issue but now it reproduced very often.
> >
> > thanks, Vladimir
> >
> > ---- self-hosting failure ----------------------------
> > [exec] -compile:
> > [exec] [mkdir] Created dir:
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > [exec] [javac] Compiling 3654 source files to
> > C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> > [exec] [javac] ----------
> > [exec] [javac] 1. ERROR in
> >
> C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> > [exec] [javac] (at line 0)
> > [exec] [javac] /*
> > [exec] [javac] ^
> > [exec] [javac] Internal compiler error
> > [exec] [javac] java.lang.IllegalArgumentException: Characters
> > number for one byte must be positive.
> > [exec] [javac] at
> > java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> > [exec] [javac] at
> > com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> > [exec] [javac] at
> > com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> > [exec] [javac] at
> > java.io.InputStreamReader.<init>(Unknown Source)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(
> Util.java:193)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java
> :70)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(
> CompilationUnit.java:58)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java
> :7707)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java
> :371)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(
> Main.java:2949)
> > [exec] [javac] at
> > org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> > [exec] [javac] at
> > java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > [exec] [javac] at
> > java.lang.reflect.Method.invoke(Method.java:381)
> > [exec] [javac] at
> > org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java
> :79)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> > [exec] [javac] at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > [exec] [javac] at
> > org.apache.tools.ant.Task.perform(Task.java:364)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.execute(Target.java:341)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > [exec] [javac] at
> > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> SingleCheckExecutor.java:37)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > [exec] [javac] at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > [exec] [javac] at
> > org.apache.tools.ant.Task.perform(Task.java:364)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.execute(Target.java:341)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > [exec] [javac] at
> > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(
> SingleCheckExecutor.java:37)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > [exec] [javac] at
> > org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> > [exec] [javac] at
> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> > [exec] [javac] at
> > org.apache.tools.ant.Task.perform(Task.java:364)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.execute(Target.java:341)
> > [exec] [javac] at
> > org.apache.tools.ant.Target.performTasks(Target.java:369)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> > [exec] [javac] at
> > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(
> DefaultExecutor.java:40)
> > [exec] [javac] at
> > org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> > [exec] [javac] at
> > org.apache.tools.ant.Main.runBuild(Main.java:668)
> > [exec] [javac] at
> > org.apache.tools.ant.Main.startAnt(Main.java:187)
> > [exec] [javac] at
> > org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> > [exec] [javac] at
> > org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> >
> > [exec] [javac] ----------
> > [exec] [javac] Characters number for one byte must be positive.
> >
> > [exec] BUILD FAILED
> > [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> > following error occurred while executing this line:
> > [exec]
> C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> > The following error occurred while executing this line:
> > [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-
> java.xml:130:
> > Compile failed; see the compiler error output for details.
> > ------------------------------------------------------------
> >
> >
> > On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > Nice document Xiao Feng. And it goes without saying, good work on
> gcv5.
> > >
> > > Rana
> > >
> > > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > > for one week experiment. If things go well, it might be the default
> GC
> > > > from then on; otherwise, it will be switched back waiting for next
> > > > chance after JavaOne. (We do not know the switch result yet, since
> the
> > > > testing infrastructure looks to be resting in weekends.)
> > > >
> > > > To make the switch is to bring Apache Harmony an advanced GC module
> > > > which has state-of-the-art design and implementation as a
> > > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases
> of
> > > > garbage collection, with a couple of dynamic runtime adaptation
> > > > innovations to improve the throughput. GCv5 supports both
> generational
> > > > and non-generational mode. Experiments showed good performance
> > > > improvement over GCv4.1 for most workloads on parallel machines.
> > > >
> > > > I have put a quick overview of Harmony GCv5 at
> > > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A
> basic
> > > > design principle of GCv5 is to be modular (or open). This is a big
> > > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > > community to develop more sophisticated GC technologies. As I know,
> > > > there are two university projects already using GCv5 for their
> > > > Harmony-based research.
> > > >
> > > > We would expect some regressions during the transition phase. Let's
> > > > promptly fix the bugs exposed, and try to make the switch smooth.
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > >
> >
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Vladimir Ivanov <iv...@gmail.com>.
Also the DRLVM smoke test classloader.StressLoader hangs on Windows
x86_64 box in the 'opt' mode (at least work longer than 40 minutes).
Thanks, Vladimir
On 4/23/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> I think one week is enough to investigate all possible issues with GCv5.
> Let's start.
> First of all, what should we do with failed tests on finalization,
> like gc.RunFinalizersOnExit (failed on Linux x86_64)?
>
> The second issue: the self-hosting (build of HDK on HDK) project is
> failed now on Windows x86_64 with message like that (stack trace is
> below):
> [exec] [javac] 1. ERROR in
> C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> [exec] [javac] (at line 0)
> [exec] [javac] /*
> [exec] [javac] ^
> [exec] [javac] Internal compiler error
> [exec] [javac] java.lang.IllegalArgumentException: Characters
> number for one byte must be positive.
>
> Note, it is not the GCv5 issue but now it reproduced very often.
>
> thanks, Vladimir
>
> ---- self-hosting failure ----------------------------
> [exec] -compile:
> [exec] [mkdir] Created dir:
> C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> [exec] [javac] Compiling 3654 source files to
> C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
> [exec] [javac] ----------
> [exec] [javac] 1. ERROR in
> C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
> [exec] [javac] (at line 0)
> [exec] [javac] /*
> [exec] [javac] ^
> [exec] [javac] Internal compiler error
> [exec] [javac] java.lang.IllegalArgumentException: Characters
> number for one byte must be positive.
> [exec] [javac] at
> java.nio.charset.CharsetDecoder.<init>(Unknown Source)
> [exec] [javac] at
> com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
> [exec] [javac] at
> com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
> [exec] [javac] at
> java.io.InputStreamReader.<init>(Unknown Source)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:193)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7707)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:371)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2949)
> [exec] [javac] at
> org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
> [exec] [javac] at
> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> [exec] [javac] at
> java.lang.reflect.Method.invoke(Method.java:381)
> [exec] [javac] at
> org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java:79)
> [exec] [javac] at
> org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
> [exec] [javac] at
> org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
> [exec] [javac] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> [exec] [javac] at
> org.apache.tools.ant.Task.perform(Task.java:364)
> [exec] [javac] at
> org.apache.tools.ant.Target.execute(Target.java:341)
> [exec] [javac] at
> org.apache.tools.ant.Target.performTasks(Target.java:369)
> [exec] [javac] at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> [exec] [javac] at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> [exec] [javac] at
> org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> [exec] [javac] at
> org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> [exec] [javac] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> [exec] [javac] at
> org.apache.tools.ant.Task.perform(Task.java:364)
> [exec] [javac] at
> org.apache.tools.ant.Target.execute(Target.java:341)
> [exec] [javac] at
> org.apache.tools.ant.Target.performTasks(Target.java:369)
> [exec] [javac] at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> [exec] [javac] at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
> [exec] [javac] at
> org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> [exec] [javac] at
> org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
> [exec] [javac] at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> [exec] [javac] at
> org.apache.tools.ant.Task.perform(Task.java:364)
> [exec] [javac] at
> org.apache.tools.ant.Target.execute(Target.java:341)
> [exec] [javac] at
> org.apache.tools.ant.Target.performTasks(Target.java:369)
> [exec] [javac] at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> [exec] [javac] at
> org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> [exec] [javac] at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
> [exec] [javac] at
> org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> [exec] [javac] at
> org.apache.tools.ant.Main.runBuild(Main.java:668)
> [exec] [javac] at
> org.apache.tools.ant.Main.startAnt(Main.java:187)
> [exec] [javac] at
> org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> [exec] [javac] at
> org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
>
> [exec] [javac] ----------
> [exec] [javac] Characters number for one byte must be positive.
>
> [exec] BUILD FAILED
> [exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
> following error occurred while executing this line:
> [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
> The following error occurred while executing this line:
> [exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-java.xml:130:
> Compile failed; see the compiler error output for details.
> ------------------------------------------------------------
>
>
> On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > Nice document Xiao Feng. And it goes without saying, good work on gcv5.
> >
> > Rana
> >
> > On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > Hi, folks, I've made the switch of default DRLVM GC component from
> > > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > > for one week experiment. If things go well, it might be the default GC
> > > from then on; otherwise, it will be switched back waiting for next
> > > chance after JavaOne. (We do not know the switch result yet, since the
> > > testing infrastructure looks to be resting in weekends.)
> > >
> > > To make the switch is to bring Apache Harmony an advanced GC module
> > > which has state-of-the-art design and implementation as a
> > > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > > garbage collection, with a couple of dynamic runtime adaptation
> > > innovations to improve the throughput. GCv5 supports both generational
> > > and non-generational mode. Experiments showed good performance
> > > improvement over GCv4.1 for most workloads on parallel machines.
> > >
> > > I have put a quick overview of Harmony GCv5 at
> > > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > > design principle of GCv5 is to be modular (or open). This is a big
> > > difference from GCv4.1. Hope it could lay a good foundation for the
> > > community to develop more sophisticated GC technologies. As I know,
> > > there are two university projects already using GCv5 for their
> > > Harmony-based research.
> > >
> > > We would expect some regressions during the transition phase. Let's
> > > promptly fix the bugs exposed, and try to make the switch smooth.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> >
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Vladimir Ivanov <iv...@gmail.com>.
I think one week is enough to investigate all possible issues with GCv5.
Let's start.
First of all, what should we do with failed tests on finalization,
like gc.RunFinalizersOnExit (failed on Linux x86_64)?
The second issue: the self-hosting (build of HDK on HDK) project is
failed now on Windows x86_64 with message like that (stack trace is
below):
[exec] [javac] 1. ERROR in
C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
[exec] [javac] (at line 0)
[exec] [javac] /*
[exec] [javac] ^
[exec] [javac] Internal compiler error
[exec] [javac] java.lang.IllegalArgumentException: Characters
number for one byte must be positive.
Note, it is not the GCv5 issue but now it reproduced very often.
thanks, Vladimir
---- self-hosting failure ----------------------------
[exec] -compile:
[exec] [mkdir] Created dir:
C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
[exec] [javac] Compiling 3654 source files to
C:\cruise_hdk\cc\projects\trunk\working_classlib\build\classes
[exec] [javac] ----------
[exec] [javac] 1. ERROR in
C:\cruise_hdk\cc\projects\trunk\working_classlib\modules\beans\src\main\java\java\beans\MethodDescriptor.java
[exec] [javac] (at line 0)
[exec] [javac] /*
[exec] [javac] ^
[exec] [javac] Internal compiler error
[exec] [javac] java.lang.IllegalArgumentException: Characters
number for one byte must be positive.
[exec] [javac] at
java.nio.charset.CharsetDecoder.<init>(Unknown Source)
[exec] [javac] at
com.ibm.icu4jni.charset.CharsetDecoderICU.<init>(Unknown Source)
[exec] [javac] at
com.ibm.icu4jni.charset.CharsetICU.newDecoder(Unknown Source)
[exec] [javac] at
java.io.InputStreamReader.<init>(Unknown Source)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:193)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9047)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9019)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7707)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:371)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:397)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2949)
[exec] [javac] at
org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1357)
[exec] [javac] at
java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
[exec] [javac] at
java.lang.reflect.Method.invoke(Method.java:381)
[exec] [javac] at
org.eclipse.jdt.core.JDTCompilerAdapter.execute(JDTCompilerAdapter.java:79)
[exec] [javac] at
org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:931)
[exec] [javac] at
org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:757)
[exec] [javac] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[exec] [javac] at
org.apache.tools.ant.Task.perform(Task.java:364)
[exec] [javac] at
org.apache.tools.ant.Target.execute(Target.java:341)
[exec] [javac] at
org.apache.tools.ant.Target.performTasks(Target.java:369)
[exec] [javac] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
[exec] [javac] at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
[exec] [javac] at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
[exec] [javac] at
org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
[exec] [javac] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[exec] [javac] at
org.apache.tools.ant.Task.perform(Task.java:364)
[exec] [javac] at
org.apache.tools.ant.Target.execute(Target.java:341)
[exec] [javac] at
org.apache.tools.ant.Target.performTasks(Target.java:369)
[exec] [javac] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
[exec] [javac] at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:37)
[exec] [javac] at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
[exec] [javac] at
org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:382)
[exec] [javac] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[exec] [javac] at
org.apache.tools.ant.Task.perform(Task.java:364)
[exec] [javac] at
org.apache.tools.ant.Target.execute(Target.java:341)
[exec] [javac] at
org.apache.tools.ant.Target.performTasks(Target.java:369)
[exec] [javac] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
[exec] [javac] at
org.apache.tools.ant.Project.executeTarget(Project.java:1185)
[exec] [javac] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
[exec] [javac] at
org.apache.tools.ant.Project.executeTargets(Project.java:1068)
[exec] [javac] at
org.apache.tools.ant.Main.runBuild(Main.java:668)
[exec] [javac] at
org.apache.tools.ant.Main.startAnt(Main.java:187)
[exec] [javac] at
org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
[exec] [javac] at
org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
[exec] [javac] ----------
[exec] [javac] Characters number for one byte must be positive.
[exec] BUILD FAILED
[exec] C:\cruise_hdk\cc\projects\trunk\build.xml:324: The
following error occurred while executing this line:
[exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\build.xml:113:
The following error occurred while executing this line:
[exec] C:\cruise_hdk\cc\projects\trunk\working_classlib\make\build-java.xml:130:
Compile failed; see the compiler error output for details.
------------------------------------------------------------
On 4/23/07, Rana Dasgupta <rd...@gmail.com> wrote:
> Nice document Xiao Feng. And it goes without saying, good work on gcv5.
>
> Rana
>
> On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > Hi, folks, I've made the switch of default DRLVM GC component from
> > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > for one week experiment. If things go well, it might be the default GC
> > from then on; otherwise, it will be switched back waiting for next
> > chance after JavaOne. (We do not know the switch result yet, since the
> > testing infrastructure looks to be resting in weekends.)
> >
> > To make the switch is to bring Apache Harmony an advanced GC module
> > which has state-of-the-art design and implementation as a
> > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > garbage collection, with a couple of dynamic runtime adaptation
> > innovations to improve the throughput. GCv5 supports both generational
> > and non-generational mode. Experiments showed good performance
> > improvement over GCv4.1 for most workloads on parallel machines.
> >
> > I have put a quick overview of Harmony GCv5 at
> > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > design principle of GCv5 is to be modular (or open). This is a big
> > difference from GCv4.1. Hope it could lay a good foundation for the
> > community to develop more sophisticated GC technologies. As I know,
> > there are two university projects already using GCv5 for their
> > Harmony-based research.
> >
> > We would expect some regressions during the transition phase. Let's
> > promptly fix the bugs exposed, and try to make the switch smooth.
> >
> > Thanks,
> > xiaofeng
> >
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Rana Dasgupta <rd...@gmail.com>.
Nice document Xiao Feng. And it goes without saying, good work on gcv5.
Rana
On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> Hi, folks, I've made the switch of default DRLVM GC component from
> GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> for one week experiment. If things go well, it might be the default GC
> from then on; otherwise, it will be switched back waiting for next
> chance after JavaOne. (We do not know the switch result yet, since the
> testing infrastructure looks to be resting in weekends.)
>
> To make the switch is to bring Apache Harmony an advanced GC module
> which has state-of-the-art design and implementation as a
> stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> garbage collection, with a couple of dynamic runtime adaptation
> innovations to improve the throughput. GCv5 supports both generational
> and non-generational mode. Experiments showed good performance
> improvement over GCv4.1 for most workloads on parallel machines.
>
> I have put a quick overview of Harmony GCv5 at
> http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> design principle of GCv5 is to be modular (or open). This is a big
> difference from GCv4.1. Hope it could lay a good foundation for the
> community to develop more sophisticated GC technologies. As I know,
> there are two university projects already using GCv5 for their
> Harmony-based research.
>
> We would expect some regressions during the transition phase. Let's
> promptly fix the bugs exposed, and try to make the switch smooth.
>
> Thanks,
> xiaofeng
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/24/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> On 4/24/07, Sergey Kuksenko <se...@gmail.com> wrote:
> > *Hi Xiao-Feng Li,*
> >
> > Great!
> > But you forget about one thing - server mode.
> > Currently server.enconf contains gc_cc dependency.
> > If we turn on gc_gen as default we should change server.emconfrespectively.
> > Mikhail Fursov promise fixing server.emconf in svn tomorrow (after
> > checking).
> > But in case of switching back we should not forget about backing emconf
> too.
>
> Actually there is a JIRA for this submitted by Yunan He. Mikhail has a
> quick patch submitted as well, but then we think it might not be very
> urgent at the moment since he needs more time to have a good solution
> for both 32 and 64 bit platforms. I personally think Mikhail can take
> more time for this issue.
Yes, I remember this JIRA. I didn't check default server.emconf, because it
has another one attached. Actually the problem described in that JIRA has
gone after http://issues.apache.org/jira/browse/HARMONY-3721 is fixed.
Anyway I will provide a patch with fixed and tested server.emconf tomorrow.
> Also I suppose that it is possible to have unified server.emconf between
> > different gc versions,
> > so I created JIRA https://issues.apache.org/jira/browse/HARMONY-3745 in
> > order to initiate a discussion.
> > Let's do it in separate thread.
>
> Yes, actually Mikhail Fursov had proposed that before. Thanks to bring
> it into JIRA.
>
That was Sergey who asked me about this feature before :)
--
Mikhail Fursov
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/24/07, Alexey Varlamov <al...@gmail.com> wrote:
>
> 2007/4/24, Mikhail Fursov <mi...@gmail.com>:
> > On 4/24/07, Alexey Varlamov <al...@gmail.com> wrote:
> > >
> > > 2007/4/24, Mikhail Fursov <mi...@gmail.com>:
> > > > On 4/24/07, Sergey Kuksenko <se...@gmail.com> wrote:
> > > > >
> > > > > On 4/24/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > > >
> > > > > > Actually there is a JIRA for this submitted by Yunan He. Mikhail
> has
> > > a
> > > > > > quick patch submitted as well, but then we think it might not be
> > > very
> > > > > > urgent at the moment since he needs more time to have a good
> > > solution
> > > > > > for both 32 and 64 bit platforms. I personally think Mikhail can
> > > take
> > > > > > more time for this issue.
> > > > >
> > > > > But, without it we can't run DRLVM in server mode.
> > > > > (yes, we can with manual config manupulation, but it is bad and
> will
> > > > > confuse
> > > > > others who don't know such details and want to run Harmony DRLVM
> in
> > > sever
> > > > > mode).
> > > > >
> > > > > Standardizing names for all VM helpers is a good idea.
> > > > There are some problems that must be solved before.
> > > > One of the problems is: a conflict between multiple Java
> implementations
> > > of
> > > > a helper. Only one of the implementations must be added to bootstrap
> > > > classpath. Today all of the implementations (both gc_gen and gc_cc
> jars)
> > > are
> > > > in bootstrap. So we need an interface to allow adding custom item
> into
> > > > bootstrap classpath. After we have it GC can use this API to add its
> own
> > > > helpers and helpers from different GC can share the same name.
> > >
> > > We can just customize emconf properties and their semantics, so that
> > > EM will be more selective depending on which components are loaded at
> > > runtime. Then it is enough to package different impls separately and
> > > tie specific jars to concrete components via emconf.
> > > I don't think more specialized API worths it,
> >
> >
> > I do not understand what do you propose here. EM does not understand JIT
> > nor GC properties, it just passes it to VM.
>
> OK, actually I meant the part of VM which manages components loading
> and initialization, sorry for confusion. So instead of adding any of
> specified startup packages to bootclasspath as it happens now, it
> should first check if corresponding component is really present in
> runtime configuration and skip otherwise.
Both gc.dll and gc.jar are the parts of the one GC. So the option to use
custom gc.dll without specification of which gc.jar to use can be the reason
of the problem.
Another solution can be is to specify not gc.dll but
gc.<component_description> file in command line. In this file all gc
properties could be stored: which dll, which mode and which java helpers to
use.
In this case we can share the names of Java helpers between different
implementations.
--
Mikhail Fursov
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Alexey Varlamov <al...@gmail.com>.
2007/4/24, Mikhail Fursov <mi...@gmail.com>:
> On 4/24/07, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > 2007/4/24, Mikhail Fursov <mi...@gmail.com>:
> > > On 4/24/07, Sergey Kuksenko <se...@gmail.com> wrote:
> > > >
> > > > On 4/24/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > > >
> > > > > Actually there is a JIRA for this submitted by Yunan He. Mikhail has
> > a
> > > > > quick patch submitted as well, but then we think it might not be
> > very
> > > > > urgent at the moment since he needs more time to have a good
> > solution
> > > > > for both 32 and 64 bit platforms. I personally think Mikhail can
> > take
> > > > > more time for this issue.
> > > >
> > > > But, without it we can't run DRLVM in server mode.
> > > > (yes, we can with manual config manupulation, but it is bad and will
> > > > confuse
> > > > others who don't know such details and want to run Harmony DRLVM in
> > sever
> > > > mode).
> > > >
> > > > Standardizing names for all VM helpers is a good idea.
> > > There are some problems that must be solved before.
> > > One of the problems is: a conflict between multiple Java implementations
> > of
> > > a helper. Only one of the implementations must be added to bootstrap
> > > classpath. Today all of the implementations (both gc_gen and gc_cc jars)
> > are
> > > in bootstrap. So we need an interface to allow adding custom item into
> > > bootstrap classpath. After we have it GC can use this API to add its own
> > > helpers and helpers from different GC can share the same name.
> >
> > We can just customize emconf properties and their semantics, so that
> > EM will be more selective depending on which components are loaded at
> > runtime. Then it is enough to package different impls separately and
> > tie specific jars to concrete components via emconf.
> > I don't think more specialized API worths it,
>
>
> I do not understand what do you propose here. EM does not understand JIT
> nor GC properties, it just passes it to VM.
OK, actually I meant the part of VM which manages components loading
and initialization, sorry for confusion. So instead of adding any of
specified startup packages to bootclasspath as it happens now, it
should first check if corresponding component is really present in
runtime configuration and skip otherwise.
> EM does not know what 'server' or 'client' mode is either.
> It's just different configuration files from EM POV.
Yep, still it processes it's content and can transform to VM
properties depending on setup.
So it could either filter out some properties (based on component name
encoded in property name or such) or let VM care of it.
>
> moreover GC should not
> > care which execution engine and which mode is active.
> >
> > Yes, the only thing GC should care about is availability of its own
> helpers. All other runtime configuration settings can be prepared outside of
> GC.
>
>
> --
> Mikhail Fursov
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/24/07, Alexey Varlamov <al...@gmail.com> wrote:
>
> 2007/4/24, Mikhail Fursov <mi...@gmail.com>:
> > On 4/24/07, Sergey Kuksenko <se...@gmail.com> wrote:
> > >
> > > On 4/24/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > >
> > > > Actually there is a JIRA for this submitted by Yunan He. Mikhail has
> a
> > > > quick patch submitted as well, but then we think it might not be
> very
> > > > urgent at the moment since he needs more time to have a good
> solution
> > > > for both 32 and 64 bit platforms. I personally think Mikhail can
> take
> > > > more time for this issue.
> > >
> > > But, without it we can't run DRLVM in server mode.
> > > (yes, we can with manual config manupulation, but it is bad and will
> > > confuse
> > > others who don't know such details and want to run Harmony DRLVM in
> sever
> > > mode).
> > >
> > > Standardizing names for all VM helpers is a good idea.
> > There are some problems that must be solved before.
> > One of the problems is: a conflict between multiple Java implementations
> of
> > a helper. Only one of the implementations must be added to bootstrap
> > classpath. Today all of the implementations (both gc_gen and gc_cc jars)
> are
> > in bootstrap. So we need an interface to allow adding custom item into
> > bootstrap classpath. After we have it GC can use this API to add its own
> > helpers and helpers from different GC can share the same name.
>
> We can just customize emconf properties and their semantics, so that
> EM will be more selective depending on which components are loaded at
> runtime. Then it is enough to package different impls separately and
> tie specific jars to concrete components via emconf.
> I don't think more specialized API worths it,
I do not understand what do you propose here. EM does not understand JIT
nor GC properties, it just passes it to VM.
EM does not know what 'server' or 'client' mode is either.
It's just different configuration files from EM POV.
moreover GC should not
> care which execution engine and which mode is active.
>
> Yes, the only thing GC should care about is availability of its own
helpers. All other runtime configuration settings can be prepared outside of
GC.
--
Mikhail Fursov
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Alexey Varlamov <al...@gmail.com>.
2007/4/24, Mikhail Fursov <mi...@gmail.com>:
> On 4/24/07, Sergey Kuksenko <se...@gmail.com> wrote:
> >
> > On 4/24/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > >
> > > Actually there is a JIRA for this submitted by Yunan He. Mikhail has a
> > > quick patch submitted as well, but then we think it might not be very
> > > urgent at the moment since he needs more time to have a good solution
> > > for both 32 and 64 bit platforms. I personally think Mikhail can take
> > > more time for this issue.
> >
> > But, without it we can't run DRLVM in server mode.
> > (yes, we can with manual config manupulation, but it is bad and will
> > confuse
> > others who don't know such details and want to run Harmony DRLVM in sever
> > mode).
> >
> > Standardizing names for all VM helpers is a good idea.
> There are some problems that must be solved before.
> One of the problems is: a conflict between multiple Java implementations of
> a helper. Only one of the implementations must be added to bootstrap
> classpath. Today all of the implementations (both gc_gen and gc_cc jars) are
> in bootstrap. So we need an interface to allow adding custom item into
> bootstrap classpath. After we have it GC can use this API to add its own
> helpers and helpers from different GC can share the same name.
We can just customize emconf properties and their semantics, so that
EM will be more selective depending on which components are loaded at
runtime. Then it is enough to package different impls separately and
tie specific jars to concrete components via emconf.
I don't think more specialized API worths it, moreover GC should not
care which execution engine and which mode is active.
>
> --
> Mikhail Fursov
>
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Mikhail Fursov <mi...@gmail.com>.
On 4/24/07, Sergey Kuksenko <se...@gmail.com> wrote:
>
> On 4/24/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >
> > Actually there is a JIRA for this submitted by Yunan He. Mikhail has a
> > quick patch submitted as well, but then we think it might not be very
> > urgent at the moment since he needs more time to have a good solution
> > for both 32 and 64 bit platforms. I personally think Mikhail can take
> > more time for this issue.
>
> But, without it we can't run DRLVM in server mode.
> (yes, we can with manual config manupulation, but it is bad and will
> confuse
> others who don't know such details and want to run Harmony DRLVM in sever
> mode).
>
> Standardizing names for all VM helpers is a good idea.
There are some problems that must be solved before.
One of the problems is: a conflict between multiple Java implementations of
a helper. Only one of the implementations must be added to bootstrap
classpath. Today all of the implementations (both gc_gen and gc_cc jars) are
in bootstrap. So we need an interface to allow adding custom item into
bootstrap classpath. After we have it GC can use this API to add its own
helpers and helpers from different GC can share the same name.
--
Mikhail Fursov
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Sergey Kuksenko <se...@gmail.com>.
On 4/24/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> Actually there is a JIRA for this submitted by Yunan He. Mikhail has a
> quick patch submitted as well, but then we think it might not be very
> urgent at the moment since he needs more time to have a good solution
> for both 32 and 64 bit platforms. I personally think Mikhail can take
> more time for this issue.
But, without it we can't run DRLVM in server mode.
(yes, we can with manual config manupulation, but it is bad and will confuse
others who don't know such details and want to run Harmony DRLVM in sever
mode).
--
Best regards,
---
Sergey Kuksenko.
Intel Enterprise Solutions Software Division.
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/24/07, Sergey Kuksenko <se...@gmail.com> wrote:
> *Hi Xiao-Feng Li,*
>
> Great!
> But you forget about one thing - server mode.
> Currently server.enconf contains gc_cc dependency.
> If we turn on gc_gen as default we should change server.emconf respectively.
> Mikhail Fursov promise fixing server.emconf in svn tomorrow (after
> checking).
> But in case of switching back we should not forget about backing emconf too.
Actually there is a JIRA for this submitted by Yunan He. Mikhail has a
quick patch submitted as well, but then we think it might not be very
urgent at the moment since he needs more time to have a good solution
for both 32 and 64 bit platforms. I personally think Mikhail can take
more time for this issue.
> Also I suppose that it is possible to have unified server.emconf between
> different gc versions,
> so I created JIRA https://issues.apache.org/jira/browse/HARMONY-3745 in
> order to initiate a discussion.
> Let's do it in separate thread.
Yes, actually Mikhail Fursov had proposed that before. Thanks to bring
it into JIRA.
Thanks,
xiaofeng
> On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >
> > Hi, folks, I've made the switch of default DRLVM GC component from
> > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > for one week experiment. If things go well, it might be the default GC
> > from then on; otherwise, it will be switched back waiting for next
> > chance after JavaOne. (We do not know the switch result yet, since the
> > testing infrastructure looks to be resting in weekends.)
> >
> > To make the switch is to bring Apache Harmony an advanced GC module
> > which has state-of-the-art design and implementation as a
> > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > garbage collection, with a couple of dynamic runtime adaptation
> > innovations to improve the throughput. GCv5 supports both generational
> > and non-generational mode. Experiments showed good performance
> > improvement over GCv4.1 for most workloads on parallel machines.
> >
> > I have put a quick overview of Harmony GCv5 at
> > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > design principle of GCv5 is to be modular (or open). This is a big
> > difference from GCv4.1. Hope it could lay a good foundation for the
> > community to develop more sophisticated GC technologies. As I know,
> > there are two university projects already using GCv5 for their
> > Harmony-based research.
> >
> > We would expect some regressions during the transition phase. Let's
> > promptly fix the bugs exposed, and try to make the switch smooth.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
> --
> Best regards,
> ---
> Sergey Kuksenko.
> Intel Enterprise Solutions Software Division.
>
--
http://xiao-feng.blogspot.com
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Sergey Kuksenko <se...@gmail.com>.
*Hi Xiao-Feng Li,*
Great!
But you forget about one thing - server mode.
Currently server.enconf contains gc_cc dependency.
If we turn on gc_gen as default we should change server.emconf respectively.
Mikhail Fursov promise fixing server.emconf in svn tomorrow (after
checking).
But in case of switching back we should not forget about backing emconf too.
Also I suppose that it is possible to have unified server.emconf between
different gc versions,
so I created JIRA https://issues.apache.org/jira/browse/HARMONY-3745 in
order to initiate a discussion.
Let's do it in separate thread.
On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> Hi, folks, I've made the switch of default DRLVM GC component from
> GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> for one week experiment. If things go well, it might be the default GC
> from then on; otherwise, it will be switched back waiting for next
> chance after JavaOne. (We do not know the switch result yet, since the
> testing infrastructure looks to be resting in weekends.)
>
> To make the switch is to bring Apache Harmony an advanced GC module
> which has state-of-the-art design and implementation as a
> stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> garbage collection, with a couple of dynamic runtime adaptation
> innovations to improve the throughput. GCv5 supports both generational
> and non-generational mode. Experiments showed good performance
> improvement over GCv4.1 for most workloads on parallel machines.
>
> I have put a quick overview of Harmony GCv5 at
> http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> design principle of GCv5 is to be modular (or open). This is a big
> difference from GCv4.1. Hope it could lay a good foundation for the
> community to develop more sophisticated GC technologies. As I know,
> there are two university projects already using GCv5 for their
> Harmony-based research.
>
> We would expect some regressions during the transition phase. Let's
> promptly fix the bugs exposed, and try to make the switch smooth.
>
> Thanks,
> xiaofeng
>
--
Best regards,
---
Sergey Kuksenko.
Intel Enterprise Solutions Software Division.
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Xiao-Feng Li <xi...@gmail.com>.
Ok, let's start another thread to discuss the fat lock resource
reclamation design.
Thanks,
xiaofeng
On 4/23/07, Weldon Washburn <we...@gmail.com> wrote:
> Xiao Feng,
>
> I think the below is a good idea. I would very much like to use GCV5 to
> solve a fat lock design problem. However, we need to wait until GCV5 is the
> default collector.
>
> For those who have not looked at the code, DRLVM "malloc()s" little C
> structs to hold inflated java object locks. Currently these C structs are
> never reclaimed. It seems to be a classic GC kind of problem. The concept
> is to use a variant of finalizer to discover when a java object is no longer
> reachable and thus invoke C code that calls "free(fat_lock);".
>
> We probably should have a design discussion regarding GC support for
> reclaiming native resources on the dev list. In addition to reclaiming fat
> locks, there are probably other native resources that can benefit from the
> GC's knowledge of java object lifecycle. (Class unloading?
> DirectByteBuffer??) It would be nice to create a general interface for
> releasing internal DRLVM native resources that are tied to java objects.
>
>
>
>
> On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> >
> > Hi, folks, I've made the switch of default DRLVM GC component from
> > GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> > for one week experiment. If things go well, it might be the default GC
> > from then on; otherwise, it will be switched back waiting for next
> > chance after JavaOne. (We do not know the switch result yet, since the
> > testing infrastructure looks to be resting in weekends.)
> >
> > To make the switch is to bring Apache Harmony an advanced GC module
> > which has state-of-the-art design and implementation as a
> > stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> > garbage collection, with a couple of dynamic runtime adaptation
> > innovations to improve the throughput. GCv5 supports both generational
> > and non-generational mode. Experiments showed good performance
> > improvement over GCv4.1 for most workloads on parallel machines.
> >
> > I have put a quick overview of Harmony GCv5 at
> > http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> > design principle of GCv5 is to be modular (or open). This is a big
> > difference from GCv4.1. Hope it could lay a good foundation for the
> > community to develop more sophisticated GC technologies. As I know,
> > there are two university projects already using GCv5 for their
> > Harmony-based research.
> >
> > We would expect some regressions during the transition phase. Let's
> > promptly fix the bugs exposed, and try to make the switch smooth.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>
> --
> Weldon Washburn
>
--
http://xiao-feng.blogspot.com
Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Posted by Weldon Washburn <we...@gmail.com>.
Xiao Feng,
I think the below is a good idea. I would very much like to use GCV5 to
solve a fat lock design problem. However, we need to wait until GCV5 is the
default collector.
For those who have not looked at the code, DRLVM "malloc()s" little C
structs to hold inflated java object locks. Currently these C structs are
never reclaimed. It seems to be a classic GC kind of problem. The concept
is to use a variant of finalizer to discover when a java object is no longer
reachable and thus invoke C code that calls "free(fat_lock);".
We probably should have a design discussion regarding GC support for
reclaiming native resources on the dev list. In addition to reclaiming fat
locks, there are probably other native resources that can benefit from the
GC's knowledge of java object lifecycle. (Class unloading?
DirectByteBuffer??) It would be nice to create a general interface for
releasing internal DRLVM native resources that are tied to java objects.
On 4/22/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> Hi, folks, I've made the switch of default DRLVM GC component from
> GCv4.1 (gc_cc) to GCv5 (gc_gen) yesterday. This switch is only trial
> for one week experiment. If things go well, it might be the default GC
> from then on; otherwise, it will be switched back waiting for next
> chance after JavaOne. (We do not know the switch result yet, since the
> testing infrastructure looks to be resting in weekends.)
>
> To make the switch is to bring Apache Harmony an advanced GC module
> which has state-of-the-art design and implementation as a
> stop-the-world GC. Basically, GCv5 is fully parallel in all phases of
> garbage collection, with a couple of dynamic runtime adaptation
> innovations to improve the throughput. GCv5 supports both generational
> and non-generational mode. Experiments showed good performance
> improvement over GCv4.1 for most workloads on parallel machines.
>
> I have put a quick overview of Harmony GCv5 at
> http://people.apache.org/~xli/docs/harmony_gcv5_overview.pdf . A basic
> design principle of GCv5 is to be modular (or open). This is a big
> difference from GCv4.1. Hope it could lay a good foundation for the
> community to develop more sophisticated GC technologies. As I know,
> there are two university projects already using GCv5 for their
> Harmony-based research.
>
> We would expect some regressions during the transition phase. Let's
> promptly fix the bugs exposed, and try to make the switch smooth.
>
> Thanks,
> xiaofeng
>
--
Weldon Washburn