Re: [drlvm] Cleaning insides of Class.h header
Weldon, one of good examples is static_method_block member variable of struct Class. Its size if calculated, memory is allocated for it, but it is never used throughout the code. Roughly 3K classes loaded in simple Eclipse usage scenario (open Eclipse, create hello, world application, run it, exit Eclipse), which means 3K useless memory allocations are made during this simple run. Heap is fragmented and Visual C runtime has locking on each memory allocation. Regards, Pavel. On 9/7/06, Weldon Washburn [EMAIL PROTECTED] wrote: Pavel, In general I like the idea of cleaning up this code. Maybe the best thing to do is post some patches so that we have examples to discuss. Weldon On 9/5/06, Pavel Pervov [EMAIL PROTECTED] wrote: It's been long time this discussion stopped. This may mean three things: - first, everyone agrees this should be done and I'm ok to provide consecutive patches; - second, noone clearly understand the purpose of what is suggested to do; if this is the case, do not hesitate to ask (again?); - third, noone is really interested in making source code of DRLVM more readable and more understandable, and I should drop this activity. Meanwhile, I'd like to open jira and start posting patches there. Regards, Pavel. On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote: Geir, well, it is the argument at least for me to start thinking in this direction and initiate this discussion. And there are places in VM core code where only definition of members of a class is required, but whole Class.h is included anyway. This is also about localizing potential development in separate functional groups to reduce recompilation when working intensively with these files. Hope, I answered, what you were asking about. :) Regards, Pavel. On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Pavel Pervov wrote: On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/7/24, Pavel Pervov [EMAIL PROTECTED]: First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Will these header files be useful separately? Yes, sure, they will be. This is one of the arguments for doing so. To whom? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
RE: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Nathan Beyer wrote:
I think I have this issue fixed. I modified the 'build-java.xml' script
to
use 'bootclasspath' instead of 'classpath' in the 'javac' task [1].
Why? What changed in the Sun compiler that warrants this?
Can we just switch to the eclipse compiler?
We could switch and personally I'd prefer to. We'd just need to get the ECJ
JAR on Ant's classpath, which we can do by having people copy the JAR to
their Ant lib folder or try to do it dynamically with the build scripts.
-Nathan
geir
Please test it out and let me know if this works. It works for me on
WinXP
and Sun JDK 5.0_8 and resolves the issue mentioned below.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mak
e/
build-java.xml?r1=440948r2=441358diff_format=h
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 10:07 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated
builds
Nathan Beyer wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200608.mbox/[EMAIL PROTECTED]
I've found that a second or third ant build takes care of it.
LOL
That's not a solution.
What I've
noticed though is that the failures are all linking to elements from
classes
in luni-kernel. I'm looking at it, but I think there are some issues
with
what's put on the bootclasspath. I've already found one discrepancy
between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses
a
vararg and our stub didn't have this.
Cool.
-Nathan
There are a number of places that use ReferenceQueues and Reference,
but
can't be generified because of a bug in the Sun compilers prior to
5.0_8. At
the end of this email is an example of code that causes a compiler
error
in
previous releases. This issue does not affect the Eclipse compiler.
I've
run
a full rebuild as of revision 440796 and everything compiles fine
with
both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends
WeakReferenceObject
{
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject
queue)
{
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) != null)
{
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[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] Cleaning insides of Class.h header
Pavel, I would first like to see a patch that removes all the unused variables and cleans up comments. Once this is committed, it makes sense address the other items you mention. Regarding C++. I would suggest looking at doing as much as possible in Java instead of C++. Vmmagic is mostly functional in Jitrino.JET. Vmmagic is very useful to read/write C structs from Java. On 9/10/06, Pavel Pervov [EMAIL PROTECTED] wrote: Weldon, one of good examples is static_method_block member variable of struct Class. Its size if calculated, memory is allocated for it, but it is never used throughout the code. Roughly 3K classes loaded in simple Eclipse usage scenario (open Eclipse, create hello, world application, run it, exit Eclipse), which means 3K useless memory allocations are made during this simple run. Heap is fragmented and Visual C runtime has locking on each memory allocation. Regards, Pavel. On 9/7/06, Weldon Washburn [EMAIL PROTECTED] wrote: Pavel, In general I like the idea of cleaning up this code. Maybe the best thing to do is post some patches so that we have examples to discuss. Weldon On 9/5/06, Pavel Pervov [EMAIL PROTECTED] wrote: It's been long time this discussion stopped. This may mean three things: - first, everyone agrees this should be done and I'm ok to provide consecutive patches; - second, noone clearly understand the purpose of what is suggested to do; if this is the case, do not hesitate to ask (again?); - third, noone is really interested in making source code of DRLVM more readable and more understandable, and I should drop this activity. Meanwhile, I'd like to open jira and start posting patches there. Regards, Pavel. On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote: Geir, well, it is the argument at least for me to start thinking in this direction and initiate this discussion. And there are places in VM core code where only definition of members of a class is required, but whole Class.h is included anyway. This is also about localizing potential development in separate functional groups to reduce recompilation when working intensively with these files. Hope, I answered, what you were asking about. :) Regards, Pavel. On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Pavel Pervov wrote: On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/7/24, Pavel Pervov [EMAIL PROTECTED]: First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Will these header files be useful separately? Yes, sure, they will be. This is one of the arguments for doing so. To whom? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division -- Weldon Washburn Intel Middleware Products Division
[build] Compiler parameterization and using ECJ
I've done some tweaking to the build scripts around compiler usage and wanted to run it by the list for comments, etc. * I've removed the -showversion JVM argument from the module build scripts that were using it when executing the tests. The launcher behavior changed a bit here, so this isn't working with the IBM VME yet. This can be added back later. Note: this wasn't consistently being used in all scripts prior to this change. * Following the lead of other 'javac' properties configured in the /make/properties.xml file, I've added a 'hy.javac.compiler' property that is used by the scripts to set the 'compiler' property on 'javac' tasks. Currently, this is just set to 'modern' to maintain the previous behavior. * I've updated all of the build scripts that were calling 'javac' to consistently use all of the 'hy.javac.*' properties, including the compiler property. Additionally, I've removed all script elements that were setting the 'build.compiler' property. The rationale behind all of the compiler tweaks was to centralize and standardize the compiler setting a bit more. The custom property can always be dumped and we can just use the standard Ant 'build.compiler', but this time use it in the 'properties.xml' file, so it's centralized still. The other big reason to do this is to attempt to use the Eclipse (ECJ) compiler for the build. I've tested using the ECJ by setting the new property and the build and tests work as normal, but I haven't found a way to use the ECJ without manually placing the ECJ JAR in the ANT_HOME\lib folder. As such, I've left the compiler property at 'modern' for now. I'd like to permanently set the compiler property to use the ECJ v3.2, but this will seemingly break the build if Ant isn't setup properly. Does anyone have any objections to using ECJ as the standard compiler? Since Harmony will use this as it's 'javac', I believe it would be proper for Harmony to be built with the same compiler. Does anyone know of any means of dynamically setting up Ant with ECJ? One thought I had was an extension to 'fetch-depends' that copies ECJ to ANT_HOME\lib for builders. I'm not sure if that would be considered desirable behavior. -Nathan
Re: [DRLVM][GC] high-level design proposal for GCV5
Anyone building the below GC? Can you give us an update? - Weldon On 8/22/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, Going on what's in the email called, [DRLVM][GC] Goals for 2006/2007, I put together a top-level design of GC. The intention is to use this design to guide the implementation of Harmony GCV5. Briefly the goals are to build a Generational Mark-Compaction (GenMC) garbage collector, initially it will be two generations: Nursery and Mature. Your comments are welcome. 1. Design principles - The source code should have parallel allocation from the start. Also, the collector should be able to take advantage of multiprocessor HW from the start. In other words when a single threaded Java app runs out of memory on a 4-way box, all 4 CPUs should be involved in GC. - Collection policy should be separated from the issue of object age. One space has one collection policy, while multiple spaces can be of same age. - There should be a clear distinction between collection policy and allocation policy. - Where it is not too time consuming, we should develop our own core data structures such as queues and locks. The intention is to reduce memory/performance/functional dependencies on platform-specific libraries. 2. Generations - The nursery should support linear scan and flexible copying order. The size should be variable at runtime with min and max boundaries. For expedient initial implementation, the nursery can use depth-first trace-forwarding algorithm for the collection. - The mature can be arranged in blocks and collected with parallel mark-compaction algorithm. (c.f. Compressor). The blocks are in the range of 64KB in size. - Large Object Space can start with a simple treadmill collector. - Collection triggering should be abstracted from collection itself. The intention is to allow experimentation with different collection trigger heuristics without actually modifying the collector. - More than two generations should be considered in the design. 3. Write barrier - The initial implementation should be a slot remembering barrier. Object remembering and card marking can be implemented later for experiments or performance evaluation. Substituting write barrier may be implemented if initial performance data suggests it is worthwhile. (Substituting write barrier is a kind of barrier design that does both the write and the barrier operations. It is an optimization for performance and flexibility.) - putfield/aastore/putstatic will need a write barrier, so do some native functions. It would be a good idea to evaluate if it is better to enumerate statics as root references or use a write barrier. The VM itself will need manual write barriers at places appropriate. - The initial write barrier implementation should be an SSB. Its OK to use explicit buffer overflow checks at the beginning. 4. Parallelism - Parallel allocation: Each mutator thread should grab a Nursery chunk for thread local allocation. Also, each collector thread should grab a Mature chunk for promoting live objects into Mature space. LOS allocation does not have to be parallel. - Parallel collection: The new GC should be designed with parallel trace-forwarding for the nursery and parallel mark-compaction for mature space. - Data structures and algorithms should be thread-safe in design from the beginning. The parallelism should be controllable, e.g., the number of parallel collection threads should be controllable at the command line. - For debug purposes, it should be possible to force the GC into single threaded collection. Comments? Thanks, xiaofeng - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [build] Compiler parameterization and using ECJ
Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Nathan Beyer wrote: I've done some tweaking to the build scripts around compiler usage and wanted to run it by the list for comments, etc. * I've removed the -showversion JVM argument from the module build scripts that were using it when executing the tests. The launcher behavior changed a bit here, so this isn't working with the IBM VME yet. This can be added back later. Note: this wasn't consistently being used in all scripts prior to this change. right - I don't think it's much of a loss to not have it, but we'll put it back as soon as we can. * Following the lead of other 'javac' properties configured in the /make/properties.xml file, I've added a 'hy.javac.compiler' property that is used by the scripts to set the 'compiler' property on 'javac' tasks. Currently, this is just set to 'modern' to maintain the previous behavior. Why didn't you make it hy.jc.cr? Seriously. Would it have killed you to put in the armon? Personally, I would prefer that, but in this case I was just trying to be consistent. All of the other javac properties are prefixed with hy.javac.XXX. Be bold! Lead those that are aesthetically challenged! [SNIP] The other big reason to do this is to attempt to use the Eclipse (ECJ) compiler for the build. I've tested using the ECJ by setting the new property and the build and tests work as normal, but I haven't found a way to use the ECJ without manually placing the ECJ JAR in the ANT_HOME\lib folder. As such, I've left the compiler property at 'modern' for now. Ugh. I thought it was working before w/o having to put it in ant/lib, although i don't remember the reason why we took it away. I don't think it was ever working with the Eclipse compiler before, was it? I think so. I think that Mark undid it. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][concurrent] We need to get the concurrent code out of the 'enhanced' part of SVN
Nathan, ... because that part of SVN implies that we have the provenance documentation for the code that makes it in there. For concurrent, we don't, so it has to go out. Please move it to standard/classlib/trunk/modules/concurrent or something. Given it's stablity - that it doesn't change in our SVN - it should be a minor problem to simply have some simple build script that compiles and jars the code, and puts the jar in the enhanced/classlib/trunk area for build and packaging purposes. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][concurrent] We need to get the concurrent code out of the 'enhanced' part of SVN
Okay, I've moved stuff around and setup an SVN externals checkout. Let me know if this fulfills the need to keep the code in 'standard'. -Nathan -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Sunday, September 10, 2006 6:12 PM To: harmony-dev@incubator.apache.org Subject: [classlib][concurrent] We need to get the concurrent code out of the 'enhanced' part of SVN Nathan, ... because that part of SVN implies that we have the provenance documentation for the code that makes it in there. For concurrent, we don't, so it has to go out. Please move it to standard/classlib/trunk/modules/concurrent or something. Given it's stablity - that it doesn't change in our SVN - it should be a minor problem to simply have some simple build script that compiles and jars the code, and puts the jar in the enhanced/classlib/trunk area for build and packaging purposes. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
Gregory Shimansky wrote: On Friday 08 September 2006 06:03 Jimmy, Jing Lv wrote: Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? Yes, the VMs whose Thread do not know how to interrupt a certain understratum blocking I/O(socket read/write, select, or so) is likely to use this method. Though DRLVM using SIGUSR2 may not meet this problem( does SIGUSR2 work on windows?). I agree this must be documented. DRLVM doesn't use POSIX signals on windows if you mean if they work in DRLVM. And if you mean whether they work in the same way as on Linux in regard of interrupting blocked IO I don't think so. POSIX signals on windows work in their own specific to windows kernel version way which makes them quite useless. In this way I believe that method is necessary, maybe not only for windows but also for other platforms. +1 of course to document to the above Geir question -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][i18n] Messages code comments
Is there any reason that there are three overloaded getString(String, XXX) methods that take variations of Object? Can't we just condense this into one method? public static String getString(String key, Object. args) In fact, this signature allows for the getString(String) method to be removed as well, since a vararg argument can be omitted altogether. Additionally, I would change the format method to use a vararg as well. Also, I'd argue that there's little value in having the overloaded methods that take an 'int' and a 'char'. I'd suggest just letting autoboxing handle this in conjunction with the varargs. Where is the code generator for these classes located? -Nathan
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I was trying the latest snapshot with the JBoss installer (4.0.1) and found a problem processing the SHA signatures int the jar manifest. I've entered a JIRA - HARMONY-1412 I will have a look at it. ;-) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[result] Re: [vote] HARMONY-1363 - DRLVM fixes and additions
+1 from Geir, Alexey V, Vladimir, Mikhail L, Mikhail F, Gregory I'd have preferred a third committer, but as it is a set of patches and enhancements to an existing codebase, and there was no opposition, I think we're ok. geir Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. I think that this an important patch so we can get better 1.5 support et al. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] putting kernel.jar in jre/bin/default
Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) geir geir Geir Magnusson Jr. wrote: I'll figure this out myself if I don't get a quick answer, but I think we should put the DRLVM kernel classes jar(s) in the same directory as the rest of the DRLVM artifacts so that it's easy to switch between VMs using the launcher. (J9 does this). How does DRLVM decide where to look? (I'm re-doing the DRLVM build to finish integrating the launcher properly, and figure that a nice thing to add is a DRLVM-snapshot that just drops into classlib/deploy/jdk/jre/bin the same way J9 does for developers 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] putting kernel.jar in jre/bin/default
On 9/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) geir There is GetModuleBaseName function on Windows. So we call LoadLobrary to get vmcore.dll's handle and pass it to GetModuleBaseName to get a base path. It seems to be possible to achieve that on Linux as well... Evgueni geir Geir Magnusson Jr. wrote: I'll figure this out myself if I don't get a quick answer, but I think we should put the DRLVM kernel classes jar(s) in the same directory as the rest of the DRLVM artifacts so that it's easy to switch between VMs using the launcher. (J9 does this). How does DRLVM decide where to look? (I'm re-doing the DRLVM build to finish integrating the launcher properly, and figure that a nice thing to add is a DRLVM-snapshot that just drops into classlib/deploy/jdk/jre/bin the same way J9 does for developers 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] putting kernel.jar in jre/bin/default
Evgueni Brevnov wrote: On 9/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Evgueni Brevnov wrote: If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) geir There is GetModuleBaseName function on Windows. So we call LoadLobrary to get vmcore.dll's handle and pass it to GetModuleBaseName to get a base path. It seems to be possible to achieve that on Linux as well... Great - tell me how. I'm lazy. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] putting kernel.jar in jre/bin/default
2006/9/11, Geir Magnusson Jr. [EMAIL PROTECTED]: Evgueni Brevnov wrote: On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: There seems to be no easy solution, other than parse LD_LIBRARY_PATH or PATH... Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside in one directory? I was thinking about this for packaging - that way you can have : jre/ bin/ j9/ drlvm/ and setup a symlink if you wish. if we have kernel.jar in jre/lib/boot as we do now, it's must less convenient and probably error prone to switch back and forth. If yes then we can take vmcore.dll base path as a location of kerenel.jar. Sure - where will you get that? and what do you w/ .so's in unix? I've come to the conclusion that the only way will be to manually run the PATH (win) and LD_LIBRARY_PATH (linux) IIUC, j9 does this in astonishingly simple way - it just specifies -Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar in the vmdir/harmonyvm.properties file, and the launcher does the rest. Namely, it automatically reads that file, replaces %LAUNCHER_HOME% with actual location and feeds extra arguments to VM among user's ones. This solution looks sufficient for now, but it seems to be only partial: it does not work for pure Invocation API usecase. Besides, those hardcoded arguments to VM appear confusing in some cases - e.g. it is impossible to override kernel.jar via command-line. Also note hardcoded default vmdir. As for the .so locations, I'm not sure if there is portable solution (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution would be leave this to user - for setting JAVA_HOME or such... -- Alexey geir geir Geir Magnusson Jr. wrote: I'll figure this out myself if I don't get a quick answer, but I think we should put the DRLVM kernel classes jar(s) in the same directory as the rest of the DRLVM artifacts so that it's easy to switch between VMs using the launcher. (J9 does this). How does DRLVM decide where to look? (I'm re-doing the DRLVM build to finish integrating the launcher properly, and figure that a nice thing to add is a DRLVM-snapshot that just drops into classlib/deploy/jdk/jre/bin the same way J9 does for developers 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][GC] high-level design proposal for GCV5
Weldon, I am writing it. Will submit an initial trace-forward copying collector for the nursery soon, and a mark-compaction collector for the mature later. Thanks, xiaofeng On 9/11/06, Weldon Washburn [EMAIL PROTECTED] wrote: Anyone building the below GC? Can you give us an update? - Weldon On 8/22/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Hi, Going on what's in the email called, [DRLVM][GC] Goals for 2006/2007, I put together a top-level design of GC. The intention is to use this design to guide the implementation of Harmony GCV5. Briefly the goals are to build a Generational Mark-Compaction (GenMC) garbage collector, initially it will be two generations: Nursery and Mature. Your comments are welcome. 1. Design principles - The source code should have parallel allocation from the start. Also, the collector should be able to take advantage of multiprocessor HW from the start. In other words when a single threaded Java app runs out of memory on a 4-way box, all 4 CPUs should be involved in GC. - Collection policy should be separated from the issue of object age. One space has one collection policy, while multiple spaces can be of same age. - There should be a clear distinction between collection policy and allocation policy. - Where it is not too time consuming, we should develop our own core data structures such as queues and locks. The intention is to reduce memory/performance/functional dependencies on platform-specific libraries. 2. Generations - The nursery should support linear scan and flexible copying order. The size should be variable at runtime with min and max boundaries. For expedient initial implementation, the nursery can use depth-first trace-forwarding algorithm for the collection. - The mature can be arranged in blocks and collected with parallel mark-compaction algorithm. (c.f. Compressor). The blocks are in the range of 64KB in size. - Large Object Space can start with a simple treadmill collector. - Collection triggering should be abstracted from collection itself. The intention is to allow experimentation with different collection trigger heuristics without actually modifying the collector. - More than two generations should be considered in the design. 3. Write barrier - The initial implementation should be a slot remembering barrier. Object remembering and card marking can be implemented later for experiments or performance evaluation. Substituting write barrier may be implemented if initial performance data suggests it is worthwhile. (Substituting write barrier is a kind of barrier design that does both the write and the barrier operations. It is an optimization for performance and flexibility.) - putfield/aastore/putstatic will need a write barrier, so do some native functions. It would be a good idea to evaluate if it is better to enumerate statics as root references or use a write barrier. The VM itself will need manual write barriers at places appropriate. - The initial write barrier implementation should be an SSB. Its OK to use explicit buffer overflow checks at the beginning. 4. Parallelism - Parallel allocation: Each mutator thread should grab a Nursery chunk for thread local allocation. Also, each collector thread should grab a Mature chunk for promoting live objects into Mature space. LOS allocation does not have to be parallel. - Parallel collection: The new GC should be designed with parallel trace-forwarding for the nursery and parallel mark-compaction for mature space. - Data structures and algorithms should be thread-safe in design from the beginning. The parallelism should be controllable, e.g., the number of parallel collection threads should be controllable at the command line. - For debug purposes, it should be possible to force the GC into single threaded collection. Comments? Thanks, xiaofeng - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
