Re: [drlvm] DRLVM, jre/bin/default and launcher
On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Vladimir Ivanov wrote: > As we know the current IBM VM does not support all 'standard' java options. > > IBM VM peoples, could you give some expectation when this support will be > available (1 month, 3 or 6 ...)? Why do we as the Harmony project care? Now we have 2 VM at Harmony and to check API behavior I use both of them. It will be more comfortable for me to have one arguments set for both VMs. So, I think about my conveniences only :) Thanks, Vladimir geir > > thanks, Vladimir > > > > The standard options from my point of view are (without deprecated): > tmp>java > Usage: java [-options] class [args...] > (to execute a class) > or java [-options] -jar jarfile [args...] > (to execute a jar file) > > where options include: >-client to select the "client" VM >-server to select the "server" VM >-hotspot is a synonym for the "client" VM [deprecated] > The default VM is client. > >-cp >-classpath > A ; separated list of directories, JAR archives, > and ZIP archives to search for class files. >-D= > set a system property >-verbose[:class|gc|jni] > enable verbose output >-version print product version and exit >-version: > require the specified version to run >-showversion print product version and continue >-jre-restrict-search | -jre-no-restrict-search > include/exclude user private JREs in the version search >-? -help print this help message >-Xprint help on non-standard options >-ea[:...|:] >-enableassertions[:...|:] > enable assertions >-da[:...|:] >-disableassertions[:...|:] > disable assertions >-esa | -enablesystemassertions > enable system assertions >-dsa | -disablesystemassertions > disable system assertions > > > > On 9/4/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: >> >> Salikh Zakirov wrote: >> > Andrey Chernyshev wrote: >> > >> >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> >> ..dll/.so into the "default" subdirectory such that one doesn't >> have to >> >> type -vm and -vmdir options; >> >> >> > >> > While would you want to rename DRLVM to Harmony VM? >> > It feels to me like claiming DRLVM to be "the only" Harmony VM. >> > On the contrary, I thought Harmony project is about *encouraging* >> diversity. >> > >> > I think having library named libdrlvm.so would be much better. >> > >> >> The Harmony launcher looks for harmonyvm.dll as its default vm library. >> It's just a generic >> name so that the launcher can find the correct library without -vm. The >> IBM VME also >> contains a harmonyvm.dll, which is why it works without specifying >> command line options >> >> Regards, >> Oliver >> >> > >> >> 2. Exclude building of the "original" launcher from the DRLVM build - >> >> it currently conflicts with the classlib launcher (both are called >> >> "java"). >> >> >> >> 3. Aside from the hythread, it may also have a sense to make the >> >> classlib and DRLVM using the same zlib dll/so (preferably the system >> >> one). >> >> >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> Oliver Deakin >> IBM United Kingdom Limited >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Vladimir Ivanov wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? Why do we as the Harmony project care? geir thanks, Vladimir The standard options from my point of view are (without deprecated): tmp>java Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the "client" VM -server to select the "server" VM -hotspot is a synonym for the "client" VM [deprecated] The default VM is client. -cp -classpath A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -D= set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version: require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:...|:] -enableassertions[:...|:] enable assertions -da[:...|:] -disableassertions[:...|:] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Salikh Zakirov wrote: > Andrey Chernyshev wrote: > >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> ..dll/.so into the "default" subdirectory such that one doesn't have to >> type -vm and -vmdir options; >> > > While would you want to rename DRLVM to Harmony VM? > It feels to me like claiming DRLVM to be "the only" Harmony VM. > On the contrary, I thought Harmony project is about *encouraging* diversity. > > I think having library named libdrlvm.so would be much better. > The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver > >> 2. Exclude building of the "original" launcher from the DRLVM build - >> it currently conflicts with the classlib launcher (both are called >> "java"). >> >> 3. Aside from the hythread, it may also have a sense to make the >> classlib and DRLVM using the same zlib dll/so (preferably the system >> one). >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 10/4/06, Ivan Popov <[EMAIL PROTECTED]> wrote: J2SE documentation explicitely mention standard and non-standard but well-known option for 'java' tool in [1] and [2]. I think it makes sense to follow this description rather than help message, they are not equal. From my point of view we should support all widely used options and it should not depend on standard/non-standard definition (for example, support of '-Xmx' option is useful too). Seems, it should be discussed and store somewhere. Thanks, Vladimir [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html [2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html Ivan. On 10/4/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote: > As we know the current IBM VM does not support all 'standard' java options. > > IBM VM peoples, could you give some expectation when this support will be > available (1 month, 3 or 6 ...)? > > thanks, Vladimir > > > > The standard options from my point of view are (without deprecated): > tmp>java > Usage: java [-options] class [args...] > (to execute a class) > or java [-options] -jar jarfile [args...] > (to execute a jar file) > > where options include: >-client to select the "client" VM >-server to select the "server" VM >-hotspot is a synonym for the "client" VM [deprecated] > The default VM is client. > >-cp >-classpath > A ; separated list of directories, JAR archives, > and ZIP archives to search for class files. >-D= > set a system property >-verbose[:class|gc|jni] > enable verbose output >-version print product version and exit >-version: > require the specified version to run >-showversion print product version and continue >-jre-restrict-search | -jre-no-restrict-search > include/exclude user private JREs in the version search >-? -help print this help message >-Xprint help on non-standard options >-ea[:...|:] >-enableassertions[:...|:] > enable assertions >-da[:...|:] >-disableassertions[:...|:] > disable assertions >-esa | -enablesystemassertions > enable system assertions >-dsa | -disablesystemassertions > disable system assertions > > > > On 9/4/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: > > > > Salikh Zakirov wrote: > > > Andrey Chernyshev wrote: > > > > > >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move > > >> ..dll/.so into the "default" subdirectory such that one doesn't have to > > >> type -vm and -vmdir options; > > >> > > > > > > While would you want to rename DRLVM to Harmony VM? > > > It feels to me like claiming DRLVM to be "the only" Harmony VM. > > > On the contrary, I thought Harmony project is about *encouraging* > > diversity. > > > > > > I think having library named libdrlvm.so would be much better. > > > > > > > The Harmony launcher looks for harmonyvm.dll as its default vm library. > > It's just a generic > > name so that the launcher can find the correct library without -vm. The > > IBM VME also > > contains a harmonyvm.dll, which is why it works without specifying > > command line options > > > > Regards, > > Oliver > > > > > > > >> 2. Exclude building of the "original" launcher from the DRLVM build - > > >> it currently conflicts with the classlib launcher (both are called > > >> "java"). > > >> > > >> 3. Aside from the hythread, it may also have a sense to make the > > >> classlib and DRLVM using the same zlib dll/so (preferably the system > > >> one). > > >> > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > Oliver Deakin > > IBM United Kingdom Limited > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
J2SE documentation explicitely mention standard and non-standard but well-known option for 'java' tool in [1] and [2]. I think it makes sense to follow this description rather than help message, they are not equal. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html [2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html Ivan. On 10/4/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote: As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? thanks, Vladimir The standard options from my point of view are (without deprecated): tmp>java Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the "client" VM -server to select the "server" VM -hotspot is a synonym for the "client" VM [deprecated] The default VM is client. -cp -classpath A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -D= set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version: require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:...|:] -enableassertions[:...|:] enable assertions -da[:...|:] -disableassertions[:...|:] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: > > Salikh Zakirov wrote: > > Andrey Chernyshev wrote: > > > >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move > >> ..dll/.so into the "default" subdirectory such that one doesn't have to > >> type -vm and -vmdir options; > >> > > > > While would you want to rename DRLVM to Harmony VM? > > It feels to me like claiming DRLVM to be "the only" Harmony VM. > > On the contrary, I thought Harmony project is about *encouraging* > diversity. > > > > I think having library named libdrlvm.so would be much better. > > > > The Harmony launcher looks for harmonyvm.dll as its default vm library. > It's just a generic > name so that the launcher can find the correct library without -vm. The > IBM VME also > contains a harmonyvm.dll, which is why it works without specifying > command line options > > Regards, > Oliver > > > > >> 2. Exclude building of the "original" launcher from the DRLVM build - > >> it currently conflicts with the classlib launcher (both are called > >> "java"). > >> > >> 3. Aside from the hythread, it may also have a sense to make the > >> classlib and DRLVM using the same zlib dll/so (preferably the system > >> one). > >> > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Oliver Deakin > IBM United Kingdom Limited > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
As we know the current IBM VM does not support all 'standard' java options. IBM VM peoples, could you give some expectation when this support will be available (1 month, 3 or 6 ...)? thanks, Vladimir The standard options from my point of view are (without deprecated): tmp>java Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: -client to select the "client" VM -server to select the "server" VM -hotspot is a synonym for the "client" VM [deprecated] The default VM is client. -cp -classpath A ; separated list of directories, JAR archives, and ZIP archives to search for class files. -D= set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version: require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -Xprint help on non-standard options -ea[:...|:] -enableassertions[:...|:] enable assertions -da[:...|:] -disableassertions[:...|:] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions On 9/4/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Salikh Zakirov wrote: > Andrey Chernyshev wrote: > >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> ..dll/.so into the "default" subdirectory such that one doesn't have to >> type -vm and -vmdir options; >> > > While would you want to rename DRLVM to Harmony VM? > It feels to me like claiming DRLVM to be "the only" Harmony VM. > On the contrary, I thought Harmony project is about *encouraging* diversity. > > I think having library named libdrlvm.so would be much better. > The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver > >> 2. Exclude building of the "original" launcher from the DRLVM build - >> it currently conflicts with the classlib launcher (both are called >> "java"). >> >> 3. Aside from the hythread, it may also have a sense to make the >> classlib and DRLVM using the same zlib dll/so (preferably the system >> one). >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
On Friday 08 September 2006 17:31 Evgueni Brevnov wrote: > On 9/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Evgueni Brevnov wrote: > > > On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > >> Evgueni Brevnov wrote: > > >> > It seems we don't need vm.boot.library.path anymore. I propose to > > >> > remove it from the sources completely. What do you think? > > >> > > >> I wasn't sure. It is used in Classloader and Runtime, I suppose as a > > >> parallel to Sun's equivalent? > > > > > > No, not as Sun's equivalent. There are two different strategies to > > > load VM libraries. The first one which was implemented in DRLVM before > > > assumes full VM responsibility to load its dlls. It was done by means > > > of vm.boot.library.path option. Search order is also important. DRLVM > > > searches libraries in the following order java.library.path then > > > system path then vm.boot.library.path. Probably, it is wrong sequence > > > or it doesn't matter at all but it seems reference implementation does > > > it exactly the same way. > > > > Does the RI have a "vm.boot.library.path" option? > > Yes, it has I don't remeber exact name. It is sun.boot.library.path. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 9/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Evgueni Brevnov wrote: >> > >> > It seems we don't need vm.boot.library.path anymore. I propose to >> > remove it from the sources completely. What do you think? >> > >> >> I wasn't sure. It is used in Classloader and Runtime, I suppose as a >> parallel to Sun's equivalent? >> > No, not as Sun's equivalent. There are two different strategies to > load VM libraries. The first one which was implemented in DRLVM before > assumes full VM responsibility to load its dlls. It was done by means > of vm.boot.library.path option. Search order is also important. DRLVM > searches libraries in the following order java.library.path then > system path then vm.boot.library.path. Probably, it is wrong sequence > or it doesn't matter at all but it seems reference implementation does > it exactly the same way. Does the RI have a "vm.boot.library.path" option? Yes, it has I don't remeber exact name. > The second one which we are implementing now > is to let launcher to specify the search order. Actually, not only the > launcher but any native application which uses Invocation API. It > seems for me to be a little strict requirement. At least spec doesn't > require it. So it seems the first approach is more consistent with the > spec. But the second one gives as flexibility to place VM under any > directory. Sowhat to choose? > > >> >> >> >> I'll see what I can take out of HARMONY-1390 for some of the issues >> >> related to teardown. Or, Evgueni, you can tell me to close it and we >> >> can do another one. There seemed to be a few extra things included in >> >> that patch, btw :) >> > Ok, let me give you some details regarding HARMONY-1390 patches. You >> > definitely don't need classlib.launcher.patch anymore. >> > drlvm.launcghr.patch contains the following logic parts: >> > 1) Get rid of old DRLVM launcher and related stuff like parsing >> > command line (new launcher do it for us) and executing main method. >> > BTW I just noticed that I forgot to delete useless code in >> > j.l.VMStarter class. >> > 2) Fix stack trace creation for new scheme. Now when main thread >> > starts application main method from native code through JNI we have >> > different few first frames on the stack. See changes for >> > vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp >> > 3) Fix -help and -X options processing when VM is created by calling >> > JNI_CreateJavaVM. >> > 4) Changes related to new location of VM's dll's. >> > >> > We don't need part number 4) anymore since you did it in more elegant >> > way. I believe it still makes sense to apply parts 1) 2) 3). >> >> I was definitely going to do 1) and 3). I didn't really yet understand >> 2), but I'll study that and ask any questions if I have any. >> >> Thanks >> >> geir >> >> > >> >> >> >> Tomorrow, I'll finish the changes to the build so we get a >> >> launcher-based JRE and HDK. >> >> >> >> I know this isn't perfect, but it's a step forward - thanks all for >> all >> >> the help. >> >> >> >> geir >> >> >> >> (and for the record, working in C, C++ and Java all at the same >> time is >> >> a hoot...) >> >> >> >> >> >> Geir Magnusson Jr. wrote: >> >> > Ok, I think I have this working now. >> >> > >> >> > DRLVM can be put anywhere and it works w/ the launcher w/o any >> >> unnatural >> >> > acts with command line parameters and/or scripts. >> >> > >> >> > There are a few things to chat about - I'll get my thoughts together >> >> > later tonight and post, and check in the code. I just wanted to let >> >> > people know if they were thinking about working on it. >> >> > >> >> > geir >> >> > >> >> > >> >> > >> >> > Geir Magnusson Jr. wrote: >> >> >> >> >> >> >> >> >> Evgueni Brevnov wrote: >> >> >>> On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> Evgueni Brevnov wrote: >> >> > HI All, >> >> > >> >> > Good news! I have a patch to run DRLVM with the classlib's >> >> launcher >> >> > (I've checked Hello and Eclipse applications on Windows only). >> >> > Actually, there are two patches. The first one is for classlib >> >> which >> >> > changes vm default directory to drlvm. >> >> >> >> I don't think we should do that - we'll keep it the same as it is >> >> now - >> >> "default". >> >> >> >> Why should we change it? >> >> >>> >> >> >>> I don't care about it too much. Let it be "default". In that case >> >> >>> -vmdir option should be specified each time. Is it convenient for >> >> >>> users? >> >> >> >> >> >> ? right now, "default" is the default. So the user doesn't >> have to >> >> >> specify anything... >> >> >> >> >> >> With the DRLVM stuff in jre/bin/default the user just types >> >> >> >> >> >> java >> >> >> >> >> >> >> >> >> > BTW it seems there will be some problems with hythr.dll library >> >> >>> if we
Re: [drlvm] DRLVM, jre/bin/default and launcher
Evgueni Brevnov wrote: On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > > It seems we don't need vm.boot.library.path anymore. I propose to > remove it from the sources completely. What do you think? > I wasn't sure. It is used in Classloader and Runtime, I suppose as a parallel to Sun's equivalent? No, not as Sun's equivalent. There are two different strategies to load VM libraries. The first one which was implemented in DRLVM before assumes full VM responsibility to load its dlls. It was done by means of vm.boot.library.path option. Search order is also important. DRLVM searches libraries in the following order java.library.path then system path then vm.boot.library.path. Probably, it is wrong sequence or it doesn't matter at all but it seems reference implementation does it exactly the same way. Does the RI have a "vm.boot.library.path" option? The second one which we are implementing now is to let launcher to specify the search order. Actually, not only the launcher but any native application which uses Invocation API. It seems for me to be a little strict requirement. At least spec doesn't require it. So it seems the first approach is more consistent with the spec. But the second one gives as flexibility to place VM under any directory. Sowhat to choose? >> >> I'll see what I can take out of HARMONY-1390 for some of the issues >> related to teardown. Or, Evgueni, you can tell me to close it and we >> can do another one. There seemed to be a few extra things included in >> that patch, btw :) > Ok, let me give you some details regarding HARMONY-1390 patches. You > definitely don't need classlib.launcher.patch anymore. > drlvm.launcghr.patch contains the following logic parts: > 1) Get rid of old DRLVM launcher and related stuff like parsing > command line (new launcher do it for us) and executing main method. > BTW I just noticed that I forgot to delete useless code in > j.l.VMStarter class. > 2) Fix stack trace creation for new scheme. Now when main thread > starts application main method from native code through JNI we have > different few first frames on the stack. See changes for > vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp > 3) Fix -help and -X options processing when VM is created by calling > JNI_CreateJavaVM. > 4) Changes related to new location of VM's dll's. > > We don't need part number 4) anymore since you did it in more elegant > way. I believe it still makes sense to apply parts 1) 2) 3). I was definitely going to do 1) and 3). I didn't really yet understand 2), but I'll study that and ask any questions if I have any. Thanks geir > >> >> Tomorrow, I'll finish the changes to the build so we get a >> launcher-based JRE and HDK. >> >> I know this isn't perfect, but it's a step forward - thanks all for all >> the help. >> >> geir >> >> (and for the record, working in C, C++ and Java all at the same time is >> a hoot...) >> >> >> Geir Magnusson Jr. wrote: >> > Ok, I think I have this working now. >> > >> > DRLVM can be put anywhere and it works w/ the launcher w/o any >> unnatural >> > acts with command line parameters and/or scripts. >> > >> > There are a few things to chat about - I'll get my thoughts together >> > later tonight and post, and check in the code. I just wanted to let >> > people know if they were thinking about working on it. >> > >> > geir >> > >> > >> > >> > Geir Magnusson Jr. wrote: >> >> >> >> >> >> Evgueni Brevnov wrote: >> >>> On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Evgueni Brevnov wrote: >> > HI All, >> > >> > Good news! I have a patch to run DRLVM with the classlib's >> launcher >> > (I've checked Hello and Eclipse applications on Windows only). >> > Actually, there are two patches. The first one is for classlib >> which >> > changes vm default directory to drlvm. >> >> I don't think we should do that - we'll keep it the same as it is >> now - >> "default". >> >> Why should we change it? >> >>> >> >>> I don't care about it too much. Let it be "default". In that case >> >>> -vmdir option should be specified each time. Is it convenient for >> >>> users? >> >> >> >> ? right now, "default" is the default. So the user doesn't have to >> >> specify anything... >> >> >> >> With the DRLVM stuff in jre/bin/default the user just types >> >> >> >> java >> >> >> >> >> >> > BTW it seems there will be some problems with hythr.dll library >> >>> if we wish to use drlvm and j9 in simultaneously. But that's another >> >>> story... >> >> >> >> Yes, we need to resolve this. >> >> >> >>> >> >> > The second one is for build >> > system and VM itself. Unfortunatelly, it is impossible to >> eliminate >> > all problems in a short period of time. There is still a bunch of >> work >> > in initialization and jni modules. So this patch is just a one >> more >> >
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> Code is checked in for linux - and updating and testing now on WinXP. >> >> The issue was that all of our library loading was done with full paths, >> which didn't let APR via dlopen() use LD_LIBRARY_PATH. >> >> So I made some small mods - please review. One problem I found was that >> I had to make assumptions such as passing NULL instead of a path being >> safe, because there was no comments in the code about expected inputs >> (or resulting outputs). >> >> I also neutered "vm.boot.library.path" to be "" unless set on command >> line, rather than be the directory of the launching executable, as I >> figured that a) I needed to have it be "" and b) that would lead to some >> interesting failures when people tried to embed DRLVM in other apps or >> such. > > It seems we don't need vm.boot.library.path anymore. I propose to > remove it from the sources completely. What do you think? > I wasn't sure. It is used in Classloader and Runtime, I suppose as a parallel to Sun's equivalent? No, not as Sun's equivalent. There are two different strategies to load VM libraries. The first one which was implemented in DRLVM before assumes full VM responsibility to load its dlls. It was done by means of vm.boot.library.path option. Search order is also important. DRLVM searches libraries in the following order java.library.path then system path then vm.boot.library.path. Probably, it is wrong sequence or it doesn't matter at all but it seems reference implementation does it exactly the same way. The second one which we are implementing now is to let launcher to specify the search order. Actually, not only the launcher but any native application which uses Invocation API. It seems for me to be a little strict requirement. At least spec doesn't require it. So it seems the first approach is more consistent with the spec. But the second one gives as flexibility to place VM under any directory. Sowhat to choose? >> >> I'll see what I can take out of HARMONY-1390 for some of the issues >> related to teardown. Or, Evgueni, you can tell me to close it and we >> can do another one. There seemed to be a few extra things included in >> that patch, btw :) > Ok, let me give you some details regarding HARMONY-1390 patches. You > definitely don't need classlib.launcher.patch anymore. > drlvm.launcghr.patch contains the following logic parts: > 1) Get rid of old DRLVM launcher and related stuff like parsing > command line (new launcher do it for us) and executing main method. > BTW I just noticed that I forgot to delete useless code in > j.l.VMStarter class. > 2) Fix stack trace creation for new scheme. Now when main thread > starts application main method from native code through JNI we have > different few first frames on the stack. See changes for > vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp > 3) Fix -help and -X options processing when VM is created by calling > JNI_CreateJavaVM. > 4) Changes related to new location of VM's dll's. > > We don't need part number 4) anymore since you did it in more elegant > way. I believe it still makes sense to apply parts 1) 2) 3). I was definitely going to do 1) and 3). I didn't really yet understand 2), but I'll study that and ask any questions if I have any. Thanks geir > >> >> Tomorrow, I'll finish the changes to the build so we get a >> launcher-based JRE and HDK. >> >> I know this isn't perfect, but it's a step forward - thanks all for all >> the help. >> >> geir >> >> (and for the record, working in C, C++ and Java all at the same time is >> a hoot...) >> >> >> Geir Magnusson Jr. wrote: >> > Ok, I think I have this working now. >> > >> > DRLVM can be put anywhere and it works w/ the launcher w/o any >> unnatural >> > acts with command line parameters and/or scripts. >> > >> > There are a few things to chat about - I'll get my thoughts together >> > later tonight and post, and check in the code. I just wanted to let >> > people know if they were thinking about working on it. >> > >> > geir >> > >> > >> > >> > Geir Magnusson Jr. wrote: >> >> >> >> >> >> Evgueni Brevnov wrote: >> >>> On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Evgueni Brevnov wrote: >> > HI All, >> > >> > Good news! I have a patch to run DRLVM with the classlib's >> launcher >> > (I've checked Hello and Eclipse applications on Windows only). >> > Actually, there are two patches. The first one is for classlib >> which >> > changes vm default directory to drlvm. >> >> I don't think we should do that - we'll keep it the same as it is >> now - >> "default". >> >> Why should we change it? >> >>> >> >>> I don't care about it too much. Let it be "default". In that case >> >>> -vmdir option should be specified each time. Is it convenient for >> >>> users? >
Re: [drlvm] DRLVM, jre/bin/default and launcher
Evgueni Brevnov wrote: On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Code is checked in for linux - and updating and testing now on WinXP. The issue was that all of our library loading was done with full paths, which didn't let APR via dlopen() use LD_LIBRARY_PATH. So I made some small mods - please review. One problem I found was that I had to make assumptions such as passing NULL instead of a path being safe, because there was no comments in the code about expected inputs (or resulting outputs). I also neutered "vm.boot.library.path" to be "" unless set on command line, rather than be the directory of the launching executable, as I figured that a) I needed to have it be "" and b) that would lead to some interesting failures when people tried to embed DRLVM in other apps or such. It seems we don't need vm.boot.library.path anymore. I propose to remove it from the sources completely. What do you think? I wasn't sure. It is used in Classloader and Runtime, I suppose as a parallel to Sun's equivalent? I'll see what I can take out of HARMONY-1390 for some of the issues related to teardown. Or, Evgueni, you can tell me to close it and we can do another one. There seemed to be a few extra things included in that patch, btw :) Ok, let me give you some details regarding HARMONY-1390 patches. You definitely don't need classlib.launcher.patch anymore. drlvm.launcghr.patch contains the following logic parts: 1) Get rid of old DRLVM launcher and related stuff like parsing command line (new launcher do it for us) and executing main method. BTW I just noticed that I forgot to delete useless code in j.l.VMStarter class. 2) Fix stack trace creation for new scheme. Now when main thread starts application main method from native code through JNI we have different few first frames on the stack. See changes for vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp 3) Fix -help and -X options processing when VM is created by calling JNI_CreateJavaVM. 4) Changes related to new location of VM's dll's. We don't need part number 4) anymore since you did it in more elegant way. I believe it still makes sense to apply parts 1) 2) 3). I was definitely going to do 1) and 3). I didn't really yet understand 2), but I'll study that and ask any questions if I have any. Thanks geir Tomorrow, I'll finish the changes to the build so we get a launcher-based JRE and HDK. I know this isn't perfect, but it's a step forward - thanks all for all the help. geir (and for the record, working in C, C++ and Java all at the same time is a hoot...) Geir Magnusson Jr. wrote: > Ok, I think I have this working now. > > DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural > acts with command line parameters and/or scripts. > > There are a few things to chat about - I'll get my thoughts together > later tonight and post, and check in the code. I just wanted to let > people know if they were thinking about working on it. > > geir > > > > Geir Magnusson Jr. wrote: >> >> >> Evgueni Brevnov wrote: >>> On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > HI All, > > Good news! I have a patch to run DRLVM with the classlib's launcher > (I've checked Hello and Eclipse applications on Windows only). > Actually, there are two patches. The first one is for classlib which > changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - "default". Why should we change it? >>> >>> I don't care about it too much. Let it be "default". In that case >>> -vmdir option should be specified each time. Is it convenient for >>> users? >> >> ? right now, "default" is the default. So the user doesn't have to >> specify anything... >> >> With the DRLVM stuff in jre/bin/default the user just types >> >> java >> >> >> > BTW it seems there will be some problems with hythr.dll library >>> if we wish to use drlvm and j9 in simultaneously. But that's another >>> story... >> >> Yes, we need to resolve this. >> >>> > The second one is for build > system and VM itself. Unfortunatelly, it is impossible to eliminate > all problems in a short period of time. There is still a bunch of work > in initialization and jni modules. So this patch is just a one more > step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? >>> >>> Yes, the patch contains changes for both parts vm and build. >>> It was easy for me to change the build than do manual manipulations >>> each time to >>> check whether it runs OK or not. >> >> So does this mean if I apply the patch, then DRLVM works w/ the >> launcher from the jre/bin/default directory w/o any problems? >> >> geir >> >>> >
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Code is checked in for linux - and updating and testing now on WinXP. The issue was that all of our library loading was done with full paths, which didn't let APR via dlopen() use LD_LIBRARY_PATH. So I made some small mods - please review. One problem I found was that I had to make assumptions such as passing NULL instead of a path being safe, because there was no comments in the code about expected inputs (or resulting outputs). I also neutered "vm.boot.library.path" to be "" unless set on command line, rather than be the directory of the launching executable, as I figured that a) I needed to have it be "" and b) that would lead to some interesting failures when people tried to embed DRLVM in other apps or such. It seems we don't need vm.boot.library.path anymore. I propose to remove it from the sources completely. What do you think? I'll see what I can take out of HARMONY-1390 for some of the issues related to teardown. Or, Evgueni, you can tell me to close it and we can do another one. There seemed to be a few extra things included in that patch, btw :) Ok, let me give you some details regarding HARMONY-1390 patches. You definitely don't need classlib.launcher.patch anymore. drlvm.launcghr.patch contains the following logic parts: 1) Get rid of old DRLVM launcher and related stuff like parsing command line (new launcher do it for us) and executing main method. BTW I just noticed that I forgot to delete useless code in j.l.VMStarter class. 2) Fix stack trace creation for new scheme. Now when main thread starts application main method from native code through JNI we have different few first frames on the stack. See changes for vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp 3) Fix -help and -X options processing when VM is created by calling JNI_CreateJavaVM. 4) Changes related to new location of VM's dll's. We don't need part number 4) anymore since you did it in more elegant way. I believe it still makes sense to apply parts 1) 2) 3). Tomorrow, I'll finish the changes to the build so we get a launcher-based JRE and HDK. I know this isn't perfect, but it's a step forward - thanks all for all the help. geir (and for the record, working in C, C++ and Java all at the same time is a hoot...) Geir Magnusson Jr. wrote: > Ok, I think I have this working now. > > DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural > acts with command line parameters and/or scripts. > > There are a few things to chat about - I'll get my thoughts together > later tonight and post, and check in the code. I just wanted to let > people know if they were thinking about working on it. > > geir > > > > Geir Magnusson Jr. wrote: >> >> >> Evgueni Brevnov wrote: >>> On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > HI All, > > Good news! I have a patch to run DRLVM with the classlib's launcher > (I've checked Hello and Eclipse applications on Windows only). > Actually, there are two patches. The first one is for classlib which > changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - "default". Why should we change it? >>> >>> I don't care about it too much. Let it be "default". In that case >>> -vmdir option should be specified each time. Is it convenient for >>> users? >> >> ? right now, "default" is the default. So the user doesn't have to >> specify anything... >> >> With the DRLVM stuff in jre/bin/default the user just types >> >> java >> >> >> > BTW it seems there will be some problems with hythr.dll library >>> if we wish to use drlvm and j9 in simultaneously. But that's another >>> story... >> >> Yes, we need to resolve this. >> >>> > The second one is for build > system and VM itself. Unfortunatelly, it is impossible to eliminate > all problems in a short period of time. There is still a bunch of work > in initialization and jni modules. So this patch is just a one more > step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? >>> >>> Yes, the patch contains changes for both parts vm and build. >>> It was easy for me to change the build than do manual manipulations >>> each time to >>> check whether it runs OK or not. >> >> So does this mean if I apply the patch, then DRLVM works w/ the >> launcher from the jre/bin/default directory w/o any problems? >> >> geir >> >>> > > The vm patch is quite heavy so I attach it and classlib patch. > Hope it will work not only for me :-) > > > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Salikh Zakirov wrote: >> > Andrey Chernyshev wrote: >> >> 1. Fi
Re: [drlvm] DRLVM, jre/bin/default and launcher
Code is checked in for linux - and updating and testing now on WinXP. The issue was that all of our library loading was done with full paths, which didn't let APR via dlopen() use LD_LIBRARY_PATH. So I made some small mods - please review. One problem I found was that I had to make assumptions such as passing NULL instead of a path being safe, because there was no comments in the code about expected inputs (or resulting outputs). I also neutered "vm.boot.library.path" to be "" unless set on command line, rather than be the directory of the launching executable, as I figured that a) I needed to have it be "" and b) that would lead to some interesting failures when people tried to embed DRLVM in other apps or such. I'll see what I can take out of HARMONY-1390 for some of the issues related to teardown. Or, Evgueni, you can tell me to close it and we can do another one. There seemed to be a few extra things included in that patch, btw :) Tomorrow, I'll finish the changes to the build so we get a launcher-based JRE and HDK. I know this isn't perfect, but it's a step forward - thanks all for all the help. geir (and for the record, working in C, C++ and Java all at the same time is a hoot...) Geir Magnusson Jr. wrote: Ok, I think I have this working now. DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural acts with command line parameters and/or scripts. There are a few things to chat about - I'll get my thoughts together later tonight and post, and check in the code. I just wanted to let people know if they were thinking about working on it. geir Geir Magnusson Jr. wrote: Evgueni Brevnov wrote: On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > HI All, > > Good news! I have a patch to run DRLVM with the classlib's launcher > (I've checked Hello and Eclipse applications on Windows only). > Actually, there are two patches. The first one is for classlib which > changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - "default". Why should we change it? I don't care about it too much. Let it be "default". In that case -vmdir option should be specified each time. Is it convenient for users? ? right now, "default" is the default. So the user doesn't have to specify anything... With the DRLVM stuff in jre/bin/default the user just types java > BTW it seems there will be some problems with hythr.dll library if we wish to use drlvm and j9 in simultaneously. But that's another story... Yes, we need to resolve this. > The second one is for build > system and VM itself. Unfortunatelly, it is impossible to eliminate > all problems in a short period of time. There is still a bunch of work > in initialization and jni modules. So this patch is just a one more > step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? Yes, the patch contains changes for both parts vm and build. It was easy for me to change the build than do manual manipulations each time to check whether it runs OK or not. So does this mean if I apply the patch, then DRLVM works w/ the launcher from the jre/bin/default directory w/o any problems? geir > > The vm patch is quite heavy so I attach it and classlib patch. > Hope it will work not only for me :-) > > > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Salikh Zakirov wrote: >> > Andrey Chernyshev wrote: >> >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> >> ..dll/.so into the "default" subdirectory such that one doesn't >> have to >> >> type -vm and -vmdir options; >> > >> > While would you want to rename DRLVM to Harmony VM? >> > It feels to me like claiming DRLVM to be "the only" Harmony VM. >> > On the contrary, I thought Harmony project is about *encouraging* >> diversity. >> > >> > I think having library named libdrlvm.so would be much better. >> >> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so >> that's what we'll name it. >> >> Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm >> and then >> >> java -vmdir:j9 >> >> or >> >> java -vmdir:drlvm >> >> >> etc >> >> geir >> >> > >> >> 2. Exclude building of the "original" launcher from the DRLVM build - >> >> it currently conflicts with the classlib launcher (both are called >> >> "java"). >> >> >> >> 3. Aside from the hythread, it may also have a sense to make the >> >> classlib and DRLVM using the same zlib dll/so (preferably the system >> >> one). >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> -
Re: [drlvm] DRLVM, jre/bin/default and launcher
Ok, I think I have this working now. DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural acts with command line parameters and/or scripts. There are a few things to chat about - I'll get my thoughts together later tonight and post, and check in the code. I just wanted to let people know if they were thinking about working on it. geir Geir Magnusson Jr. wrote: Evgueni Brevnov wrote: On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > HI All, > > Good news! I have a patch to run DRLVM with the classlib's launcher > (I've checked Hello and Eclipse applications on Windows only). > Actually, there are two patches. The first one is for classlib which > changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - "default". Why should we change it? I don't care about it too much. Let it be "default". In that case -vmdir option should be specified each time. Is it convenient for users? ? right now, "default" is the default. So the user doesn't have to specify anything... With the DRLVM stuff in jre/bin/default the user just types java > BTW it seems there will be some problems with hythr.dll library if we wish to use drlvm and j9 in simultaneously. But that's another story... Yes, we need to resolve this. > The second one is for build > system and VM itself. Unfortunatelly, it is impossible to eliminate > all problems in a short period of time. There is still a bunch of work > in initialization and jni modules. So this patch is just a one more > step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? Yes, the patch contains changes for both parts vm and build. It was easy for me to change the build than do manual manipulations each time to check whether it runs OK or not. So does this mean if I apply the patch, then DRLVM works w/ the launcher from the jre/bin/default directory w/o any problems? geir > > The vm patch is quite heavy so I attach it and classlib patch. > Hope it will work not only for me :-) > > > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Salikh Zakirov wrote: >> > Andrey Chernyshev wrote: >> >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> >> ..dll/.so into the "default" subdirectory such that one doesn't >> have to >> >> type -vm and -vmdir options; >> > >> > While would you want to rename DRLVM to Harmony VM? >> > It feels to me like claiming DRLVM to be "the only" Harmony VM. >> > On the contrary, I thought Harmony project is about *encouraging* >> diversity. >> > >> > I think having library named libdrlvm.so would be much better. >> >> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so >> that's what we'll name it. >> >> Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm >> and then >> >> java -vmdir:j9 >> >> or >> >> java -vmdir:drlvm >> >> >> etc >> >> geir >> >> > >> >> 2. Exclude building of the "original" launcher from the DRLVM build - >> >> it currently conflicts with the classlib launcher (both are called >> >> "java"). >> >> >> >> 3. Aside from the hythread, it may also have a sense to make the >> >> classlib and DRLVM using the same zlib dll/so (preferably the system >> >> one). >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --
Re: [drlvm] DRLVM, jre/bin/default and launcher
Evgueni Brevnov wrote: On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > HI All, > > Good news! I have a patch to run DRLVM with the classlib's launcher > (I've checked Hello and Eclipse applications on Windows only). > Actually, there are two patches. The first one is for classlib which > changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - "default". Why should we change it? I don't care about it too much. Let it be "default". In that case -vmdir option should be specified each time. Is it convenient for users? ? right now, "default" is the default. So the user doesn't have to specify anything... With the DRLVM stuff in jre/bin/default the user just types java > BTW it seems there will be some problems with hythr.dll library if we wish to use drlvm and j9 in simultaneously. But that's another story... Yes, we need to resolve this. > The second one is for build > system and VM itself. Unfortunatelly, it is impossible to eliminate > all problems in a short period of time. There is still a bunch of work > in initialization and jni modules. So this patch is just a one more > step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? Yes, the patch contains changes for both parts vm and build. It was easy for me to change the build than do manual manipulations each time to check whether it runs OK or not. So does this mean if I apply the patch, then DRLVM works w/ the launcher from the jre/bin/default directory w/o any problems? geir > > The vm patch is quite heavy so I attach it and classlib patch. > Hope it will work not only for me :-) > > > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Salikh Zakirov wrote: >> > Andrey Chernyshev wrote: >> >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> >> ..dll/.so into the "default" subdirectory such that one doesn't >> have to >> >> type -vm and -vmdir options; >> > >> > While would you want to rename DRLVM to Harmony VM? >> > It feels to me like claiming DRLVM to be "the only" Harmony VM. >> > On the contrary, I thought Harmony project is about *encouraging* >> diversity. >> > >> > I think having library named libdrlvm.so would be much better. >> >> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so >> that's what we'll name it. >> >> Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm >> and then >> >> java -vmdir:j9 >> >> or >> >> java -vmdir:drlvm >> >> >> etc >> >> geir >> >> > >> >> 2. Exclude building of the "original" launcher from the DRLVM build - >> >> it currently conflicts with the classlib launcher (both are called >> >> "java"). >> >> >> >> 3. Aside from the hythread, it may also have a sense to make the >> >> classlib and DRLVM using the same zlib dll/so (preferably the system >> >> one). >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
2006/9/6, Evgueni Brevnov <[EMAIL PROTECTED]>: On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > Evgueni Brevnov wrote: > > HI All, > > > > Good news! I have a patch to run DRLVM with the classlib's launcher > > (I've checked Hello and Eclipse applications on Windows only). > > Actually, there are two patches. The first one is for classlib which > > changes vm default directory to drlvm. > > I don't think we should do that - we'll keep it the same as it is now - > "default". > > Why should we change it? I don't care about it too much. Let it be "default". In that case -vmdir option should be specified each time. Is it convenient for users? BTW it seems there will be some problems with hythr.dll library if we wish to use drlvm and j9 in simultaneously. But that's another story... Evgueni, The patch you provided hardcodes name of vmdir, so the command-line option would not help... OTOH, indeed it is possible to put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm (exactly as Geir said) and just symlink one of them to jre/bin/default as needed :) Regarding hythr lib, DRLVM can load the lib from it's own directory, isn't it? BTW, is there any reason to name it equally with the classlib's counterpart? I suppose it is loaded only dynamically anyway. Still I think this patch is enough for basic launcher support; we can make it more reliable and customizable later. -- Alexey > > > The second one is for build > > system and VM itself. Unfortunatelly, it is impossible to eliminate > > all problems in a short period of time. There is still a bunch of work > > in initialization and jni modules. So this patch is just a one more > > step to our goal. > > Great. As I said in other mails, the build stuff isn't the part to > worry about but rather the VM itself. > > So does this patch do it completely, or should we wait? Yes, the patch contains changes for both parts vm and build. It was easy for me to change the build than do manual manipulations each time to check whether it runs OK or not. > > > > > The vm patch is quite heavy so I attach it and classlib patch. > > Hope it will work not only for me :-) > > > > > > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > >> > >> Salikh Zakirov wrote: > >> > Andrey Chernyshev wrote: > >> >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move > >> >> ..dll/.so into the "default" subdirectory such that one doesn't > >> have to > >> >> type -vm and -vmdir options; > >> > > >> > While would you want to rename DRLVM to Harmony VM? > >> > It feels to me like claiming DRLVM to be "the only" Harmony VM. > >> > On the contrary, I thought Harmony project is about *encouraging* > >> diversity. > >> > > >> > I think having library named libdrlvm.so would be much better. > >> > >> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so > >> that's what we'll name it. > >> > >> Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm > >> and then > >> > >> java -vmdir:j9 > >> > >> or > >> > >> java -vmdir:drlvm > >> > >> > >> etc > >> > >> geir > >> > >> > > >> >> 2. Exclude building of the "original" launcher from the DRLVM build - > >> >> it currently conflicts with the classlib launcher (both are called > >> >> "java"). > >> >> > >> >> 3. Aside from the hythread, it may also have a sense to make the > >> >> classlib and DRLVM using the same zlib dll/so (preferably the system > >> >> one). > >> > > >> > > >> > - > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Evgueni Brevnov wrote: > HI All, > > Good news! I have a patch to run DRLVM with the classlib's launcher > (I've checked Hello and Eclipse applications on Windows only). > Actually, there are two patches. The first one is for classlib which > changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - "default". Why should we change it? I don't care about it too much. Let it be "default". In that case -vmdir option should be specified each time. Is it convenient for users? BTW it seems there will be some problems with hythr.dll library if we wish to use drlvm and j9 in simultaneously. But that's another story... > The second one is for build > system and VM itself. Unfortunatelly, it is impossible to eliminate > all problems in a short period of time. There is still a bunch of work > in initialization and jni modules. So this patch is just a one more > step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? Yes, the patch contains changes for both parts vm and build. It was easy for me to change the build than do manual manipulations each time to check whether it runs OK or not. > > The vm patch is quite heavy so I attach it and classlib patch. > Hope it will work not only for me :-) > > > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Salikh Zakirov wrote: >> > Andrey Chernyshev wrote: >> >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> >> ..dll/.so into the "default" subdirectory such that one doesn't >> have to >> >> type -vm and -vmdir options; >> > >> > While would you want to rename DRLVM to Harmony VM? >> > It feels to me like claiming DRLVM to be "the only" Harmony VM. >> > On the contrary, I thought Harmony project is about *encouraging* >> diversity. >> > >> > I think having library named libdrlvm.so would be much better. >> >> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so >> that's what we'll name it. >> >> Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm >> and then >> >> java -vmdir:j9 >> >> or >> >> java -vmdir:drlvm >> >> >> etc >> >> geir >> >> > >> >> 2. Exclude building of the "original" launcher from the DRLVM build - >> >> it currently conflicts with the classlib launcher (both are called >> >> "java"). >> >> >> >> 3. Aside from the hythread, it may also have a sense to make the >> >> classlib and DRLVM using the same zlib dll/so (preferably the system >> >> one). >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Thanks - putting patches in JIRA is the best way. geir Evgueni Brevnov wrote: Hi Geir, It seems not all of us are able to see my attachments :-( I've created new jira HARMONY-1390 with attachments. Thanks Evgueni. On 9/6/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > Salikh Zakirov wrote: > > Andrey Chernyshev wrote: > >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move > >> ..dll/.so into the "default" subdirectory such that one doesn't have to > >> type -vm and -vmdir options; > > > > While would you want to rename DRLVM to Harmony VM? > > It feels to me like claiming DRLVM to be "the only" Harmony VM. > > On the contrary, I thought Harmony project is about *encouraging* diversity. > > > > I think having library named libdrlvm.so would be much better. > > No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so > that's what we'll name it. > > Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm > and then > > java -vmdir:j9 > > or > > java -vmdir:drlvm > > > etc > > geir > > > > >> 2. Exclude building of the "original" launcher from the DRLVM build - > >> it currently conflicts with the classlib launcher (both are called > >> "java"). > >> > >> 3. Aside from the hythread, it may also have a sense to make the > >> classlib and DRLVM using the same zlib dll/so (preferably the system > >> one). > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Evgueni Brevnov wrote: HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - "default". Why should we change it? The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Salikh Zakirov wrote: > Andrey Chernyshev wrote: >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> ..dll/.so into the "default" subdirectory such that one doesn't have to >> type -vm and -vmdir options; > > While would you want to rename DRLVM to Harmony VM? > It feels to me like claiming DRLVM to be "the only" Harmony VM. > On the contrary, I thought Harmony project is about *encouraging* diversity. > > I think having library named libdrlvm.so would be much better. No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so that's what we'll name it. Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm and then java -vmdir:j9 or java -vmdir:drlvm etc geir > >> 2. Exclude building of the "original" launcher from the DRLVM build - >> it currently conflicts with the classlib launcher (both are called >> "java"). >> >> 3. Aside from the hythread, it may also have a sense to make the >> classlib and DRLVM using the same zlib dll/so (preferably the system >> one). > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Hi Geir, It seems not all of us are able to see my attachments :-( I've created new jira HARMONY-1390 with attachments. Thanks Evgueni. On 9/6/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > Salikh Zakirov wrote: > > Andrey Chernyshev wrote: > >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move > >> ..dll/.so into the "default" subdirectory such that one doesn't have to > >> type -vm and -vmdir options; > > > > While would you want to rename DRLVM to Harmony VM? > > It feels to me like claiming DRLVM to be "the only" Harmony VM. > > On the contrary, I thought Harmony project is about *encouraging* diversity. > > > > I think having library named libdrlvm.so would be much better. > > No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so > that's what we'll name it. > > Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm > and then > > java -vmdir:j9 > > or > > java -vmdir:drlvm > > > etc > > geir > > > > >> 2. Exclude building of the "original" launcher from the DRLVM build - > >> it currently conflicts with the classlib launcher (both are called > >> "java"). > >> > >> 3. Aside from the hythread, it may also have a sense to make the > >> classlib and DRLVM using the same zlib dll/so (preferably the system > >> one). > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Salikh Zakirov wrote: > Andrey Chernyshev wrote: >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move >> ..dll/.so into the "default" subdirectory such that one doesn't have to >> type -vm and -vmdir options; > > While would you want to rename DRLVM to Harmony VM? > It feels to me like claiming DRLVM to be "the only" Harmony VM. > On the contrary, I thought Harmony project is about *encouraging* diversity. > > I think having library named libdrlvm.so would be much better. No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so that's what we'll name it. Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm and then java -vmdir:j9 or java -vmdir:drlvm etc geir > >> 2. Exclude building of the "original" launcher from the DRLVM build - >> it currently conflicts with the classlib launcher (both are called >> "java"). >> >> 3. Aside from the hythread, it may also have a sense to make the >> classlib and DRLVM using the same zlib dll/so (preferably the system >> one). > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move ..dll/.so into the "default" subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be "the only" Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so that's what we'll name it. Then it makes it easy. put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm and then java -vmdir:j9 or java -vmdir:drlvm etc geir 2. Exclude building of the "original" launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called "java"). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Andrey Chernyshev wrote: On 9/1/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: Hi Geir, I'm very enthusiastic about making DRLVM to work with the launcher. It requires implementation of the Invocation API to a certain extent. For example it's enougth to have only partial support for To some extent, some of those invocation API you mentioned have been already implemented. I believe DRLVM can already be started with the launcher if type a command: java -vm:vmcore -vmdir:. Yes. But it won't work if vmdir isn't "." If we want to complete the transition to the classlib's launcher, then I guess we need to do the following: 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move .dll/.so into the "default" subdirectory such that one doesn't have to type -vm and -vmdir options; Yes, but that can be done in the build script. The problem is that DRLVM - apparently EM which seems to a bit of the loading - can't seem to handle when resources aren't in "." 2. Exclude building of the "original" launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called "java"). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). Yep. But first, we need to fix EM so that resources can be in a subdirectory. so to summarize : I don't believe the issue is as simple as a build script. I thought I experimented with getting DRLVM to work with the normal launcher when DRLVM was in /default. If memory serves, it doesnt' work. geir Thanks, Andrey. DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is necessary as well. So if there is no objections I can start working on it right now. Thanks Evgueni. On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > We need to make DRLVM work with the launcher in the same way that J9 > works with the launcher. It's a royal PITA to do an ant-clean and have > DRLVM wiped out of the deploy/jdk/jre directory in classlib-land. > > My goal here is two fold - > > a) make it easy for people to have both DRLVM and j9 around for A/B testing > > b) make DRLVM the default VM we use for everything > > I know that we still have the epic argument around hythread to resolve, > but we can do this task first. > > Does anyone want to volunteer to take this on? If not, I'll do it, but > I know that there are people out there that know DRLVM far better than I > do... > > geir > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Cool. I guess the question is, can it load resources from the directory where the VM itself came from? We want to package things such that they all go into jre/bin/ with the default for that being 'default' (although it shouldn't matter). We also want to avoid setting LD_LIBRARY_PATH and other such externalities... geir Evgueni Brevnov wrote: Ok, I will try to teach DRLVM where to load dlls from before doing other things. Evgueni. On 9/1/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, but can we wack off the biggest problem first, namely that DRLVM doesn't work when it's artifacts (dll's, so's) are in a subdirectory of jre/bin? TO me, that's our biggest problem. Subtle cleanup issues are also important, but not as much at this point. geir Evgueni Brevnov wrote: > Hi Geir, > > I'm very enthusiastic about making DRLVM to work with the launcher. It > requires implementation of the Invocation API to a certain extent. For > example it's enougth to have only partial support for > DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is > necessary as well. So if there is no objections I can start working on > it right now. > > Thanks > Evgueni. > > On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> We need to make DRLVM work with the launcher in the same way that J9 >> works with the launcher. It's a royal PITA to do an ant-clean and have >> DRLVM wiped out of the deploy/jdk/jre directory in classlib-land. >> >> My goal here is two fold - >> >> a) make it easy for people to have both DRLVM and j9 around for A/B >> testing >> >> b) make DRLVM the default VM we use for everything >> >> I know that we still have the epic argument around hythread to resolve, >> but we can do this task first. >> >> Does anyone want to volunteer to take this on? If not, I'll do it, but >> I know that there are people out there that know DRLVM far better than I >> do... >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move ..dll/.so into the "default" subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be "the only" Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. The Harmony launcher looks for harmonyvm.dll as its default vm library. It's just a generic name so that the launcher can find the correct library without -vm. The IBM VME also contains a harmonyvm.dll, which is why it works without specifying command line options Regards, Oliver 2. Exclude building of the "original" launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called "java"). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Andrey Chernyshev wrote: > 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move > ..dll/.so into the "default" subdirectory such that one doesn't have to > type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be "the only" Harmony VM. On the contrary, I thought Harmony project is about *encouraging* diversity. I think having library named libdrlvm.so would be much better. > 2. Exclude building of the "original" launcher from the DRLVM build - > it currently conflicts with the classlib launcher (both are called > "java"). > > 3. Aside from the hythread, it may also have a sense to make the > classlib and DRLVM using the same zlib dll/so (preferably the system > one). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 9/1/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: Hi Geir, I'm very enthusiastic about making DRLVM to work with the launcher. It requires implementation of the Invocation API to a certain extent. For example it's enougth to have only partial support for To some extent, some of those invocation API you mentioned have been already implemented. I believe DRLVM can already be started with the launcher if type a command: java -vm:vmcore -vmdir:. If we want to complete the transition to the classlib's launcher, then I guess we need to do the following: 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and move .dll/.so into the "default" subdirectory such that one doesn't have to type -vm and -vmdir options; 2. Exclude building of the "original" launcher from the DRLVM build - it currently conflicts with the classlib launcher (both are called "java"). 3. Aside from the hythread, it may also have a sense to make the classlib and DRLVM using the same zlib dll/so (preferably the system one). Thanks, Andrey. DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is necessary as well. So if there is no objections I can start working on it right now. Thanks Evgueni. On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > We need to make DRLVM work with the launcher in the same way that J9 > works with the launcher. It's a royal PITA to do an ant-clean and have > DRLVM wiped out of the deploy/jdk/jre directory in classlib-land. > > My goal here is two fold - > > a) make it easy for people to have both DRLVM and j9 around for A/B testing > > b) make DRLVM the default VM we use for everything > > I know that we still have the epic argument around hythread to resolve, > but we can do this task first. > > Does anyone want to volunteer to take this on? If not, I'll do it, but > I know that there are people out there that know DRLVM far better than I > do... > > geir > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrey Chernyshev Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Ok, I will try to teach DRLVM where to load dlls from before doing other things. Evgueni. On 9/1/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Ok, but can we wack off the biggest problem first, namely that DRLVM doesn't work when it's artifacts (dll's, so's) are in a subdirectory of jre/bin? TO me, that's our biggest problem. Subtle cleanup issues are also important, but not as much at this point. geir Evgueni Brevnov wrote: > Hi Geir, > > I'm very enthusiastic about making DRLVM to work with the launcher. It > requires implementation of the Invocation API to a certain extent. For > example it's enougth to have only partial support for > DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is > necessary as well. So if there is no objections I can start working on > it right now. > > Thanks > Evgueni. > > On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> We need to make DRLVM work with the launcher in the same way that J9 >> works with the launcher. It's a royal PITA to do an ant-clean and have >> DRLVM wiped out of the deploy/jdk/jre directory in classlib-land. >> >> My goal here is two fold - >> >> a) make it easy for people to have both DRLVM and j9 around for A/B >> testing >> >> b) make DRLVM the default VM we use for everything >> >> I know that we still have the epic argument around hythread to resolve, >> but we can do this task first. >> >> Does anyone want to volunteer to take this on? If not, I'll do it, but >> I know that there are people out there that know DRLVM far better than I >> do... >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Ok, but can we wack off the biggest problem first, namely that DRLVM doesn't work when it's artifacts (dll's, so's) are in a subdirectory of jre/bin? TO me, that's our biggest problem. Subtle cleanup issues are also important, but not as much at this point. geir Evgueni Brevnov wrote: Hi Geir, I'm very enthusiastic about making DRLVM to work with the launcher. It requires implementation of the Invocation API to a certain extent. For example it's enougth to have only partial support for DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is necessary as well. So if there is no objections I can start working on it right now. Thanks Evgueni. On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We need to make DRLVM work with the launcher in the same way that J9 works with the launcher. It's a royal PITA to do an ant-clean and have DRLVM wiped out of the deploy/jdk/jre directory in classlib-land. My goal here is two fold - a) make it easy for people to have both DRLVM and j9 around for A/B testing b) make DRLVM the default VM we use for everything I know that we still have the epic argument around hythread to resolve, but we can do this task first. Does anyone want to volunteer to take this on? If not, I'll do it, but I know that there are people out there that know DRLVM far better than I do... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Hi Geir, I'm very enthusiastic about making DRLVM to work with the launcher. It requires implementation of the Invocation API to a certain extent. For example it's enougth to have only partial support for DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is necessary as well. So if there is no objections I can start working on it right now. Thanks Evgueni. On 8/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: We need to make DRLVM work with the launcher in the same way that J9 works with the launcher. It's a royal PITA to do an ant-clean and have DRLVM wiped out of the deploy/jdk/jre directory in classlib-land. My goal here is two fold - a) make it easy for people to have both DRLVM and j9 around for A/B testing b) make DRLVM the default VM we use for everything I know that we still have the epic argument around hythread to resolve, but we can do this task first. Does anyone want to volunteer to take this on? If not, I'll do it, but I know that there are people out there that know DRLVM far better than I do... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] DRLVM, jre/bin/default and launcher
We need to make DRLVM work with the launcher in the same way that J9 works with the launcher. It's a royal PITA to do an ant-clean and have DRLVM wiped out of the deploy/jdk/jre directory in classlib-land. My goal here is two fold - a) make it easy for people to have both DRLVM and j9 around for A/B testing b) make DRLVM the default VM we use for everything I know that we still have the epic argument around hythread to resolve, but we can do this task first. Does anyone want to volunteer to take this on? If not, I'll do it, but I know that there are people out there that know DRLVM far better than I do... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
