Re: [general] Announcing Melody
Stefano Mazzocchi wrote: > 2) add a chart for email traffic GMane has a chart for harmony traffic: http://dir.gmane.org/gmane.comp.java.harmony.devel
Re: [jira][attachments] Is it possible to mark attachments as obsolete?
Alexey Petrenko wrote: > Is it possible to configure JIRA to let people to mark issue > attachments as obsolete? Like in Bugzilla? > This is very useful feature when issue has few iterations of the fix. Trick: upload the file with exactly the same name, then the latest one will be marked as "latest" (in mouse-over baloon), and earlier versions will be shown in gray. I use this trick for some time. However, I've seen cases when other contributors ignored "gray" color of the attachment and reviewed/tested/committed incorrect patch. So, probably, some care from the reviewers/committers is also needed.
Re: [drlvm][design] class unloading: Secondary root set
> Salikh Zakirov wrote:
>> I think you have missed one point: after retracing from secondary root
>> set once,
>> more classloaders may be found reachable, so this step needs to be
>> repeated until
>> convergence (to obtain the closure of reachability with additional
>> links Object->Class,
>> served through vtable marks).
Robin Garner wrote:
> My proposal doesn't require steps (2) although VM->ClassLaoder
> references are weak, and (5), because the trace from the vtable roots is
> no different fromthe standard GC trace.
Okay, It looks like you found a way to avoid repetitive retracing from added
roots,
and doing it in one step. If this is the case, I see how one can do
with just enumerating vtables, and without "unload list".
However, I do not understand how can correctness and completeness can be
achieved
with just one retracing. Java allows for arbitrary implementation of
user-defined
class loaders, including chained (think of java application server loaded as an
application to another application server).
> You could alternately say that I'm simply refining your approach. Yes,
> they are structurally very similar - if you agree with my refinements,
> feel free to merge them.
I will gladly merge your ideas as soon as I understand them,
but unfortunately I cannot see how can algorithm be correct without
transitive classloader revival.
It looks to me like one-step approach at deciding whether on unloading a
classloader
can produce incorrect results in the case of multiple chained classloaders.
For example, the test below will unload two of the classloaders incorrectly
at the first System.gc(). Note, that the test works correctly on Sun Hotspot:
$ java -showversion -verbose:gc UnloadTwice
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)
loading UnloadTwice.class
loading UnloadTwice.class
loading UnloadTwice.class
[Full GC 284K->131K(1984K), 0.0100915 secs] <<<<<<<< it does not unload any
classloader on the first GC
[Full GC[Unloading class UnloadTwice]<<<<<<<< it unloads all 3
classloaders at the second GC
[Unloading class UnloadTwice]
[Unloading class UnloadTwice]
131K->131K(1984K), 0.0092772 secs]
ok
import java.io.*;
import java.lang.reflect.*;
public class UnloadTwice extends ClassLoader {
static Object o;
public static void init() {
try {
UnloadTwice cl1 = new UnloadTwice();
ClassLoader scl = ClassLoader.getSystemClassLoader();
cl1.setParent(scl);
Class c1 = cl1.loadClass("UnloadTwice");
Method sp1 = c1.getMethod("setParent", ClassLoader.class);
ClassLoader cl2 = (ClassLoader)c1.newInstance();
sp1.invoke(cl2, new Object[] { scl });
Class c2 = cl2.loadClass("UnloadTwice");
Method sp2 = c2.getMethod("setParent", ClassLoader.class);
ClassLoader cl3 = (ClassLoader)c2.newInstance();
sp2.invoke(cl3, new Object[] { scl });
Class c3 = cl3.loadClass("UnloadTwice");
o = c3.newInstance();
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
init();
System.gc(); // we still have third-level-chained object o live
o = null;
System.gc(); // now o is gone, class unloading should happen
System.out.println("ok");
}
ClassLoader parent;
public void setParent(ClassLoader parent) {
this.parent = parent;
}
public Class loadClass(String name) {
try {
if (!"UnloadTwice".equals(name)) return parent.loadClass(name);
System.out.println("loading " + name + ".class");
InputStream in = parent.getResourceAsStream(name + ".class");
byte bytes[] = new byte[in.available()];
in.read(bytes);
return defineClass(bytes, 0, bytes.length);
} catch (Exception e) { throw new RuntimeException(e); }
}
}
[design] Class unloading: false sharing of vtable marks
As we discussed before, the VTable marks approach [1] has a "false sharing" problem on a multiprocessor: when one thread is writing to vtable mark, it is invalidating respective cache line in other processor caches. Meanwhile, since gcmaps, located near vtable marks, are loaded frequently during heap tracing, the same cache line will be loaded and invalidated repeatedly, leading to huge load to memory bus and harming performance. *Illustration*: original "VTable marks" suggestion applied to current DRLVM object layout. objectVTable gcmap +++---++--+ | VT ptr |--->| gcmap ptr |--->| offset of ref #1 | | ... || mark|| offset of ref #2 | +++...|| ...| +---+|0 | +--+ I would like suggest solution to false sharing problem using additional level of indirection, that is, to store the _pointer to mark word_ in VTable rather than mark word itself. *Illustration*: "indirect VTable marks" suggestion objectVTable gcmap +++---++--+ | VT ptr |--->| gcmap ptr |--->| offset of ref #1 | | ... || mark ptr |---,| offset of ref #2 | +++...| || ...| +---+ ||0 | |+--+ v [mark word] I do not think this will hurt performance significantly in comparison with original "vtable marks" approach, because, additional load of mark_ptr is very likely to be served from the first-level cache, because it happens at the same time as gcmap_ptr load. (If the mark_ptr is loaded first, then subsequent load of gcmap_ptr will be served from cache, so no additional memory load overhead anyway). In current DRLVM design [2], each VTable already have pointers to native Class structure: Class* clss; It looks like the same pointer can be reused for VTable mark word, if we allocate VTable mark word as the first word of struct Class. In this way, even the size of VTable structure will not be changed comparing to current size. The resulting object layout diagram would be *Illustration*: "indirect VTable marks stored in struct Class" objectVTable gcmap +++---++--+ | VT ptr |--->| gcmap ptr |--->| offset of ref #1 | | ... || clss ptr |---,| offset of ref #2 | +++...| || ...| +---+ ||0 | |+--+ v +---+ | mark word | |...| +---+ struct Class Robin suggested "side byte-map" as another solution to the same false sharing problem. As I do not completely understand how this side byte-map would be implemented, I do not know if it is similar to this suggestion. Robin, could you comment on it? [1] http://wiki.apache.org/harmony/ClassUnloading [2] http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/vtable.h?view=co (* This is a follow-up to design proposals at http://wiki.apache.org/harmony/ClassUnloading I am starting new discussion because mailing list is a better means for discussion than Wiki. After we come to conclusion, I will log it to the wiki page. *)
[design] class unloading: Secondary root set
Robin, I have read your description of "secondary root set" approach, and found it the same as "finalization-like" approach discussed by Etienne and me earlier. I think you have missed one point: after retracing from secondary root set once, more classloaders may be found reachable, so this step needs to be repeated until convergence (to obtain the closure of reachability with additional links Object->Class, served through vtable marks). Can you reread two proposals and merge the text into one section? I can do it, but want first to make sure we have common understanding.
Re: [jira] Patch available setting
Alexey Petrenko wrote: > So I think that *require* from issue creator to check the fix *before* > not the best solution. Since noone on earth can prevent you from submitting your patch to a new JIRA and link it to the original one, this is not a *real* requirement. I guess this is just a hint to proper patch review / verification process. In any case, I do not see much of a problem.
Re: Deleted version_svn_tag.h
Nathan Beyer wrote: > Not using SVN directly? Do I even want to ask? We have a running SVN->Git mirroring via tailor, and some people prefer to use Git for managing patches, because git 1) is faster 2) can manage many patches and branches 3) can work offline. (I do not intend this as hidden advertisment, sorry if it sounds like it). > In any case, I tested it after I deleted the file and the file was > regenerated during the build. Did I miss something? I thought this bit > was already in the scripts. Nathan, thanks a lot for you attention! I do not think you missed anything, because it is really due to peculiarities in our setup. When SVN information is not available, pointless file copying wasn't performed, and this was also feature requested by me (to shorten recompilation time). Since the fix was committed promptly, I really don't see much problem in this particular case, and do not see anything that you need to change in your process. Thanks for the care, anyway.
Deleted version_svn_tag.h
Nathan Beyer wrote: > I deleted the file and added it to the ignore property. For those of us poor souls not using SVN directly this deletion broke the build, as the file version_svn_tag.h is not available directly now. The issue HARMONY-2168 provides a fix: copy the file.
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Etienne Gagnon wrote: > The http://wiki.apache.org/harmony/ClassUnloading wiki page is > "Immutable". How can I contribute to it? It is immutable for "anonymous" guests, you need to register and login somewhere. All pages are editable by all registered users. > Do I have to submit JIRA bugs? If yes, how do I make the patches? (svn > diff?) We use JIRA to submit code patches. 'svn diff from the root of the workspace' is a (one of) correct way to create a patch. (Root of the workspace is one of the enhanced/drlvm/trunk, enhanced/classlib/trunk etc.) Some hints for contributors, including patch creation, are available at http://incubator.apache.org/harmony/get-involved.html
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Aleksey Ignatenko wrote: > Actually there is one additional 4-th approach: > > *Mark and scan based approach *wich I described in the first letter. Java > heap trace is performed by VM Core and GC is not affected at all. > > So the list is: > 1. vtable objects( Aleksey ) > 2. per heap space/generation boolean marker on the classloader instance( > Etienne ) > 3. class reachability marker byte in vtable (Robin ) > 4. Mark and scan based approach. > > I agree that we need to structure all appraches somehow, like description > for every approach in wiki. I've started a wiki page http://wiki.apache.org/harmony/ClassUnloading to summarize all discussed approaches. I hope we will eventually come up with the detailed end-to-end design description. I'm going now to fill in all ideas that I can pick up from the discussion, but I encourage all interested parties to review and correct if I get something incorrectly.
Re: [drlvm] Class unloading support - tested one approach
Etienne Gagnon wrote: > Salikh Zakirov wrote: >> 7) let the GC finish collection and reclaim unreachable objects -- this >> reclaims java objects > > Just a bit of a warning... This should be integrated within the > weak/soft/phantom + finalization framework. We definitely don't want > the native resources of a class loader to be freed and later have > finalization revive the class loader... :-) Agreed. "Revival" of classloaders should be done after "revival" of objects in finalization queue. I think this scheme can be implemented by introducing one additional GC->VM callback (vm_trace_complete), which would be called right after GC completed the trace. The call sequence will be as follows: GCVM |---> vm_enumerate_root_set() | gc_add_root_set_entry()<---| | gc_add_root_set_entry()<---| | gc_add_root_set_entry()<---| |<- - - - - - - - - - -return from vm_enumerate_root_set() || [trace heap] | || |---> vm_trace_complete() | gc_add_root_set_entry()<---| | gc_add_root_set_entry()<---| |< - - - - - - - - - - - return from vm_trace_complete()-| || [trace heap from new roots, | if there are any] | |---> vm_trace_complete() |< - - - - - - - - - - - return from vm_trace_complete()-| | [no retrace, as no new roots were received] | [reclaim space] | Additionally, even finalization itself can be moved out of GC responsibility, using this interface and one additional function to query if the object was already reached or not. > [Luckily, nothing special needs to be done for JNI code; > CallStaticMethod does require a native reference to a class > object. Yay! ] Unluckily, something needs to be done for JVMTI. It has a function IterateOverHeap which is supposed to iterate over both reachable and unreachable objects by scanning heap linearly. Thus, if the respective capability (can_tag_objects) has been requested on the VM startup, the GC must run in a special mode and zero out all unreachable objects, because the unreachable object may loose its descriptor (VTable) at any time, and GC will not be able even to know its size. This will prevent some optimizations, like not reclaiming short free areas in unmovable space, and require some special attention from the GC developers. OTOH, gc_cc already has a special mode (-Dgc.heap_iteration=1) to support iteration even before class unloading is implemented.
Re: [drlvm] Class unloading support - tested one approach
Etienne Gagnon wrote: > Ivan Volosyuk wrote: >> We will get rid of false sharing. That's true. But it still be quite >> expensive to write those '1' values, because of ping-ponging of the >> cache line between processors. I see only one solution to this: use >> separate mark bits in vtable per GC thread which should reside in >> different cache lines and different from that word containing gcmap >> pointer. > > The only thing that a GC thread does is write "1" in this slot; it never > writes "0". So, it is not very important in what order (or even "when") > this word is finally commited to main memory. As long as there is some > barrier before the "end of epoch collection" insuring that all > processors cache write buffers are commited to memory before tracing > vtables (or gc maps). The "false sharing" problem occurs whenever one processor writes into the cache line other processors read from, because it invalidates loaded copies and makes other processors read it again from main memory. It doesn't matter if they write 1 or 0 In our case, both gcmap pointer and gcmap itself are likely to be read by multiple processors, so writing to a location nearby may lead to false sharing.
Re: [drlvm] Class unloading support - tested one approach
Etienne Gagnon wrote: >> 3) trace the heap >> 4) scan vtable marks and "revive" marked class unloaders, by adding the >> strong root >> from the previously collected "unload list". Remove the revived >> classloaders from unload list. >> 5) repeat steps (3) and (4) until there is no classloaders to revive > > As long as it is understood that the repeated (3) is not a full trace. > It's only a trace starting from the revived roots. [This is important > in evaluating the total work done]. Exactly.
Re: [drlvm] Class unloading support - tested one approach
Etienne Gagnon wrote: > "Revival" is only needed if you use the finalization-like approach. If > you only do class-unloading GC when the nursery is empty, then no > revival is needed. Ah, I think I got it. You mean running a minor collection, and then "class unloading" full heap collection sequentially, without any mutator work in between? Then, the correctness is observed easily: 1) all mature objects has their vtable marks set to 1 2) after minor collection, the nursery is empty => all live objects already have vtable marks == 1 Thus, if we find a classloader with vtable marks == 0, then it has no object instances, and its reachability is defined solely by reachability of java.lang.ClassLoader instance and existence of the method frames, which can be checked, respectively, by enumerating class loader roots as weak roots, and scanning stacks. Note, that the class loader, which became eligible for unloading during epoch N, will not be unloaded until the end of the epoch N+1. However, in the case of non-generational collector, the "minor collection followed by unloading collection" becomes effectively two successive garbage collections. On the other side, "finalization-like" design goes as follows: 1) clean vtable marks before "class unloading" collection 2) enumerate classloader roots as weak and collect array of user classloader pointers for later use -- let's call it "unload list" 3) trace the heap 4) scan vtable marks and "revive" marked class unloaders, by adding the strong root from the previously collected "unload list". Remove the revived classloaders from unload list. 5) repeat steps (3) and (4) until there is no classloaders to revive 6) unload the classloaders, pointed by the "unload list" -- this reclaims native resources 7) let the GC finish collection and reclaim unreachable objects -- this reclaims java objects This design unloads classloaders at the end of the very same epoch when they became unloadable. The voting definitely was premature, as it turns out that even the design under discussion can be elaborated to multiple substantially different designs.
Re: [drlvm] Class unloading support - tested one approach
>> Etienne Gagnon wrote: >> > My proposal already argued that vtable bit/byte/word marking is >> > unnecessary for "nursery allocations". You only need to mark the >> vtable >> > of objects that survive collection and pretenured objects. Alexey Varlamov wrote: > I may have missed it, but I only recall you argued that we just need > to collect mature space for the *final unloading* as CL and classes > are unlikely to die young, which I agree. But chances that a live > object of a candidate class appeared in the nursery are higher. > Otherwise I just do not grok how this algorithm can be proven for > correctness. Alexey, it looks like what you are thinking about is *concurrent* collector, and concurrent garbage collections brings substantial complexity even without class unloading. However, the design we were discussing was for *stop-the-world* garbage collectors, because this is the only thing currently supported by DRLVM, and all existing GCs are stop-the-world. So, the correctness of unloading algorithm can easily be proved if we consider that the "final unloading" collection is a full heap collection, i.e. both nursery and mature space is collected. I have another concern though: just before starting "final unloading" collection, we scan vtable marks and identify the candidates for unloading. During the "final unloading" collection, the candidate classloader roots are reported as week. At the end of the trace, we need to rescan vtable marks and "revive" the classloader which were found in possession of live objects. This techniques is exactly the same as the one used for object finalization. However, in contrast with finalization, we will need to repeat reviving classloaders which have non-0 vtable marks until the process converges, and no new classloaders are revived. (* in finalization, both dead and live objects in finalization queue are revived, and thus the revival converges in just 1 step *).
Re: [doc][drlvm] The document "Getting started with DRL" is outdated
Morozova, Nadezhda wrote: > * preparing the "Commonly Used Options for DRLVM" (omitting the word > "supported" intentionally) > Question on this one: will the page contain vm-only options? What about > JIT, GC, other? I'd have them all in one place, but we have separate > docs for EM/jit stuff. What do you say? I suggest that the maintainers of the respective components add their favourite options to the page http://wiki.apache.org/harmony/DrlvmCommandLineOptions (I've just linked it from the front page, and stuffed some easy stuff I know). After (and if) the content comes to a reasonable shape, Nadya may consider rewriting it as a permanent web site page. However, I suspect that rate of changing of command line options is a little bit too fast to be tracked by "hard" documentation.
Re: [drlvm] Class unloading support - tested one approach
Robin Garner wrote: > Etienne Gagnon wrote: >> 3- Why would it be so hard to add an unconditional write operation >> during collection (e.g. during copying or marking of an object) in >> drlvm? A detailed technical explanation is welcome. :-) > > I actually believe that this should be implementable in a GC-neutral > way, whether vtables are objects or not. The GC will at some point ask > the VM for the GC map of the object it is about to scan. At this point > the VM can write the mark of the vtable. > > I guess I'm making an assumption about the GC -> VM interface here, but > if it doesn't exist, it should :) In the current GC-VM interface, which is used in DRLVM (see vm/include/open/gc.h and vm/include/open/vm_gc.h), the GC never asks VM about gcmap; instead, it is building a gcmap itself as one of the class loading steps. VM calls gc_class_prepared() for each loaded class, and GC uses various query functions to learn about types and offsets of object fields. The gcmap pointer is stored in the VTable, in the several bytes reserved specifically for the GC use. Technically, it should not be too difficult to add an additional field to the VTable structure, and require GC to write 1 there during object scanning. However, if the VTable mark is located in the same cache line as gcmap, it may severely hit parallel GC performance on a multiprocessor due to false sharing, as writing VTable mark will invalidate the gcmap pointers loaded to caches of other processors. objectVTable gcmap +++---++--+ | VT ptr |--->| gcmap ptr |--->| offset of ref #1 | | ... ||...|| offset of ref #2 | +++---+| ...| |0 | +--+ (* actually, in the current default collector "gc_cc", gcmap ptr also has some flags in lower 3 bits, and gcmap has some fields before offsets array as well *) That's why we probably would want to have the VTable mark be separated enough from both gcmap pointer and the gcmap itself. >> By the way, what are the currently competing proposals? >> 1- object vtables >> 2- Robin/Gagnon proposal (still finishing up some details ;-) >> 3- Is there a 3rd? yes, as far as I heard from Aleksey Ignatenko, there was 3rd prototype in works, which worked as a completely independent from the GC stop-the-world phase, tracing the heap and marking classes and classloaders specially. The tracing functionality was reimplemented within VM without any GC changes. The stop-the-world phase was piggy-backed into some collections. And yet before the 3rd prototype, there was one more, which was different in the tracing implementation. It used GC->VM callback on each object scan.
Re: [drlvm][jvmti] Heap iteration bugfix in HARMONY-2112
Gregory Shimansky wrote: > I've applied your patch in HARMONY-2112 but I have a question to you. There > is > a new condition in jvmti_capability.cpp with the following comment: > > // if the global capability can_tag_objects has already been enabled, > // requested by this environment, but not yet posessed by this > environment, > // reject the request > if (ti->get_global_capability(DebugUtilsTI::TI_GC_ENABLE_TAG_OBJECTS) > && !posessed.can_tag_objects && capabilities_ptr->can_tag_objects) > return JVMTI_ERROR_NOT_AVAILABLE; > > Does it mean that only one environment at a time can hold and use tag objects > functionality? Is it a temporary limitation or inherent design restriction? Yes, your understanding is correct. The design to store tag pointer into each object implies that object cannot be tagged by more than one environment. Thus the restriction of only one environment possessing can_tag_objects capability. I've added a note to KnownNonBugIssuesAndLimitations wiki page.
Re: [drlvm][icl] Fix for the gc_gen compilation problem with Intel Compiler, windows
Alexey Petrenko wrote: > Salikh could you please attach your patch to the HARMONY-1897 > specified by Alexei? done
[drlvm][icl] Fix for the gc_gen compilation problem with Intel Compiler, windows
Hi, the following trivial patch fixes the gc_gen compilation problem with Intel Compiler under Windows: --- vm/gc_gen/src/common/gc_platform.h +++ vm/gc_gen/src/common/gc_platform.h @@ -29,7 +29,7 @@ #include #define USEC_PER_SEC INT64_C(100) -#define VmThreadHandle (void*) +#define VmThreadHandle void* #define VmEventHandle hysem_t #define THREAD_OK TM_ERROR_NONE I did not file the JIRA since the fix is trivial and would be obvious fix to anyone trying compile gc_gen with Intel Compiler on Windows. Could anyone commit this fix?
[drlvm] HARMONY-1635 heap iteration WAS: [general] version of GCC...
Gregory Shimansky wrote: > I think you could use 4.1.0 in Fedora Core 5. Since patch level > shouldn't really affect the C++ compilation restrictions, the same patch > should break on 4.1.0 as well. Gregory, I've looked at harmony-1635.patch you've uploaded to HARMONY-1635, and I see that is based on the outdated patch from HARMONY-1635. (i.e. not the latest version: heap-iteration-optimized.patch). So I will upload the updated patch myself. I've checked its compilation on Fedora Core 5 (Bordeaux) with gcc 4.1.0, and it compiles okay. I've uploaded updated harmony-1635.patch to HARMONY-1635.
Re: [drlvm][x86_64] BBP is broken on Linux/x86_64
Gregory Shimansky wrote: > Geir Magnusson Jr. wrote: >> You should be able to just put them in, ensure they don't break x86, >> and let the people w/ _64 systems to check > > This is a good idea. I promise to install everything correctly and check > 64-bit patches in native environment, but today I'll follow Geir's advice. > > Also I don't like the idea of downgrading classlib instead of fixing the > problem with its build. I think you misunderstood me, I did not suggest to downgrade classlib. My point is that the patch from HARMONY-2017 *really* fixes BBP problem in DRLVM, and I've verified it, though with less-than-up-to-date classlib.
[drlvm] dynamic object layout
Hi, I am currently continuing to work on improving JVMTI Heap Iteration (HARMONY-1635), particularly, tagging objects. The use case that I've heard of is tagging *all* objects for the purpose of memory profiling. According to what I've heard it causes 60x slowdown on Sun's VM. However, the initial tags implementation that I've uploaded to HARMONY-1635 is far worse, as it uses linear search for get/set tag operations. (* for those who didn't read JVMTI spec, tags are jlong (8 byte integer) values, which can be attached to arbitrary objects in get/set manner *) The alternative approach I came up with is to use (mostly) constant time algorithms for get/set operations, is to store a tag pointer in each object. Storing tag itself in an object is not an option, as JVMTI requires to send OBJECT_FREE events with tags for each reclaimed objects, and this information would not be available if the tag would be reclaimed together with the object. However, since the general consensus was that increasing object header is highly undesired, I've tried to implement the _conditional_ increase in object header. Additional object header field is allocated in case JVMTI Agent has requested can_tag_objects capability. The modified object layout I used is as follows: +---+ | VTable pointer | +---+ | lockword | +---+ | [array length] | +---+ | [tag pointer] | +---+ |[padding] | +---+ | fields or elements| | ... | +---+ Where [array length] is only present in array objects, [tag pointer] is only present when can_tag_capability has been enabled at startup [padding] is only present in arrays of longs and doubles for natural 8-byte alignment. VTable pointer is really uint32 offset on em64t/x86_64 and ipf/ia64. The only difference with current object layout is introduction of tag pointer field. I've modified gc_cc to take the changed dynamic object layout into account, and surprisingly it took only one modification: * use VM function vector_first_element_offset_unboxed() instead of hardcoding first array element offset. This is done once for each class done at loading stage, and gc_cc caches this offset for later uses. I've experimented with putting tag pointer at fixed location before array length, but it looks expensive, as it will add one more read to GC array scanning, and we obviously do not want optimize at the expense of common case. The latest version of the patch is attached to HARMONY-1635 (heap-iteration-optimized.patch), I would appreciate any comments and concerns.
Re: [drlvm][x86_64] BBP is broken on Linux/x86_64
Gregory Shimansky wrote: > I've closed HARMONY-2040 and is going to work on HARMONY-2017 now. It > may take a while to set up everything correctly on x86_64. Thanks, Gregory! A side note: I wasn't able to compile latest classlib on em64t. (compilation errors in swing java code) I used somewhat old version (whatever happened to be already built in my workspace) [r452910] Quick hack until we sort out the awt architecture variables. with x86_64 libraries available from HARMONY-1676.
Re: [general] version of GCC...
Geir Magnusson Jr. wrote: > > > Salikh Zakirov wrote: >> Geir Magnusson Jr. wrote: >>> did we ever bottom out on what range of GCC we'll support? >> >> I think we didn't, and I doubt we ever could. > > Of course we can. We just say "version X -> Version y" I would not call this case "we agreed". I would rather say "one can observe that we use gcc of version 3.3.3 <= V <= 4.1.1".
[drlvm][x86_64] BBP is broken on Linux/x86_64
Hi, DRLVM on Linux/x86_64 has been broken for quite some time, since commit [r467997] HARMONY-1942, back-branch polling TLS offset is incorrect. Several people noticed this and came up with solutions: HARMONY-2017 Linux em64t build failed due to typeInt32 is undefined in Ia32BBPolling.cpp HARMONY-2040 fix compilation and disable bbp on linux/x86_64 HARMONY-2017 has a patch with a solution to the problem, while HARMONY-2040 provides only a workaround. I suggest to commit HARMONY-2017 and close HARMONY-2040 as duplicate. Could some committer take care of this issue? Gregory?
Re: [drlvm] more self-dependent VM tasks, newbies welcome
Geir Magnusson Jr. wrote: > Only further thought - how do I get to this page? Maybe I'm not seeing > it. From front page, there is the "TODO list" for DRLVM, but there's no > link to the 'newbie" page. that's not a problem, as long as the newbie page is clickable-through from a starting page. I expect that any newbie seriously considering contributing to the project will read all available sources thoroughly before jumping in. That's why I suggest *not* to add "newbie" page to the wiki front page, as it tends to get cluttered too quickly. Let's keep the Front Page clean and logical (and thus short).
Re: [general] version of GCC...
Geir Magnusson Jr. wrote: > did we ever bottom out on what range of GCC we'll support? I think we didn't, and I doubt we ever could. Still, it's not a problem if the committers can agree on it. I have recollections of Gregory saying he will check on gcc 4.1.1. Geir, what version do you use for checking? > I have a patch I want to commit that is known to not compile under 4.1.1... I suspect it was my patch that doesn't compile under gcc 4.1. I used to use SuSe 9 with gcc 3.3.3, but I will see if I can install a newer version.
Re: [drlvm] Is it time to say goodbye to dear friend GC v4?
Ivan Volosyuk wrote: > I would like to know the opinion of Artem, Salikh and Alexey > Ignatenko. They have used the GC and may have reasons to keep it. As for me, I used it to debug heap iteration because it had heap iteration implementation earlier than GC v41. Now that GC v41 also developed support for heap iteration, there is no reason for me to keep using GC v4. +1 to drop GC v4.
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Geir Magnusson Jr. wrote: > Why not use junit? task in implicitly assumes that you can run all tests in single JVM instance. Though it does provide fork-mode to run tests in separate JVM processes, it still does not allow per-test JVM args configuration. Which is exactly what we need for JVMTI tests, as most of the test has their own special agent to be run with. Nevertheless, we could use junit task with some benefit in creating test reports. I think this can be accomodated in Gregory's scheme by using task instead of task. The most of the ant mechanics (selecting tests and looping over them for compilation and running) will be there no matter what we use for test running, or .
Re: [drlvm][jit] How to override jit compilation?
Mikhail Fursov wrote: > The solutions we have today: > > 1) If you have only a few methods to be affected: create separate JIT > instance without inliner and add method filters to EM configuration file. > Check > http://incubator.apache.org/harmony/subcomponents/drlvm/emguide.htmland > *.emconf files for details. > > 2) If you need to avoid inlining of special method in all Java methods you > can use 'skip_methods' parameter of inliner pass. See opt.emconf file to > check how to pass parameters to inliner. > > 3) Replace all calls to your method with VMHelperCall in translator. > Process > it as direct calls in codegenerator. This solution was already proposed by > Egor. For the sake of completeness, there is one more solution 4) mark methods as 'native' in java sources and provide "native stub overrides" in vmcore/src/jit/native_overrides.cpp.
Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Gregory Shimansky wrote: >> But on Linux these tests fail with >> lost of different exceptions: >> >> For java.lang.ClassGenericsTest: >> >> java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009^Z^Z^Z >> java.lang.NoClassDefFoundError: java/lang/ClassGenericsTest$Mc007^Z >> java.lang.TypeNotPresentException: Type >> java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1 not present >> >> For java.lang.ClassGenericsTest4: >> >> Some NPEs from unobvious sources. I've attached two test reports to >> this email. Anyways, it looks like timeout is not the case for these >> tests failures. > > Ok I think I've found the cause of problems with these two tests on > Linux which I had yesterday. On Gentoo I have russian locale set > "ru_RU.KOI8-R" while on all other Linux installations it appears there > are various combinations of *.UTF-8 locales (usually "en_US.UTF-8", but > I found "en_AU.UTF-8" on oner server). > > I experimented a bit with this stuff and found out that these tests work > ok when locale is some sort of UTF-8 one, including ru_RU.UTF-8 one. > > The result of test run is actually affected by locale set at compilation > time, not the one set at the subsequent test runs. When locale at > compile time is set to *.UTF-8, then test run is successful on any > locale set after it. If locale is set to something simple like "C" (!) > or "ru_RU.KOI8-R" at compile time then test run fails no matter what > locale is set when tests are running. > > I wonder what we should blame here, compiler, VM, classlib or the tests? IMHO, the test is not correct for non-unicode configurations, as some unicode-named classfiles cannot be saved with filename in locale-specified character set. I think that fixing \u characters in these tests to some ASCII characters should fix the problem (I haven't checked myself). However, I do not know the original intention why those characters were put to the class names in the first place, does anyone know an explanation?
Re: [drlvm][gc] TLS access from GC: a proposal to refactor the code
Evgueni Brevnov wrote:
> Hi Guys,
>
> Just one little note from me... AFAIK Window and Linux have limitation
> on the number of TLS slots which can be allocated for any particular
> thread. I believe here is strong (probably performance) reasons for
> doing so. It can be a problem to implement arbitrary size TLS which
> seems to be required in case we want to allocate memory for keeping
> whole structures in it.
Currently TM provides this service by using just *1* OS-level TLS slot.
The keys are allocated from a hythread_t structure:
thread/src/thread_private.h
166 typedef struct HyThread {
312 /**
313 * Array representing thread local storage
314 */
315 void *thread_local_storage[10];
So, it seems reasonable to use 3 of them for GC, 1 for VM and 1 for JIT.
Re: [general] POLL : supported platforms
Morozova, Nadezhda wrote: > My two cents... > >>> I do not understand the lifecycle of this page. If I report today > that >> my >>> platform works OK, but the next commit brokes it, who will update the >> page? >> >> IMHO if the next commit breakes the work-ok-platform and if you notice >> it, why not to update the wiki page? Or you can let me know about this >> bug and I'll make the update:) > Do you think we can add a note with the revision number? This way, you > at least know that the code of revision worked ok/failed on this > platform. Because such tests are done systematically, changing revisions > would not take much time to update. -1 I think this is a conceptually incorrect approach to try to keep a relatively slowly changing wiki page up-to-date with fast-paced commits. I believe this approach is doomed, and the status page is going to get out-of-date while it is being edited. I would suggest the following "fix" to the approach: * Reserve the "supported platforms" notion for the developer releases or snapshots, and do not use the term with respect to SVN trunk * Relate the list of "supported platforms" with the release management process, and describe the status of particular snapshots, and not SVN trunk in general.
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Gregory Shimansky wrote:
> On Tuesday 24 October 2006 19:20 Salikh Zakirov wrote:
>> I would like to request for comments on a possible way of getting rid
>> of java execution from vm_hint_finalize(). The initial patch is attached to
>> HARMONY-1952.
>
> You've also modified the problematic test in it. Are you sure this
> modification doesn't change the test behavior in any way? Wouldn't it be
> better to check that original test works well with it?
The original test may not work with the modification. I consider this a bug in
the test.
It implicitly assumed that all cleared references will be available in
reference queue
as soon as System.gc() completes. This was true before.
The patch in HARMONY-1952 breaks this, because references are enqueued from the
context
of finalization thread, and this may happen some time later.
As the specification does not say at what exact moment cleared references should
become available, I suppose that changing one implementation assumption
("references are available after System.gc()") to a weaker assumption
("references are available after System.gc();System.runFinalization()") is
a correct thing to do.
> Hmm... what if jthread_monitor_try_enter(finalizer_thread) fails, that is,
> monitor is owned by another thread? Is the lock global for all finalization
> threads? It won't give good results if there is more than one of them.
Yes, the lock is global. I used try_enter() to prevent possible deadlock
scenario,
when the finalization happens at precisely the moment finalization thread is
holding
the finalization lock. If this happens, and vm_hint_finalize() cannot grab
the finalization monitor, no harm is taken, because locked finalization monitor
means that the finalization thread is active, and does not need to be waked up.
On the other hand, the finalization queue itself is protected by a different
native
lock, which is guaranteed not to be locked at the garbage collection time
(because it is locked and unlocked in suspend-disabled region).
(* okay, I didn't check this, but I believe it should work this way *)
> Other than that I think your approach with notifying finalizer threads
> instead
> of running the code on the same stack is better.
Let's wait for other potential problems to be found by other Harmony
contributors :)
In any case, it will take some time to bring this idea to a committable patch.
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Pavel Afremov wrote: > gc.Finalizer and gc PhantomReferenceQueueTest are synthetic test. And can't > be called "normal" (do code review, if you doubt, please). But this test > isn't source of the circularity error. The error can happen for usual > application too. The CL an SM tests just show that source of fake > circularity error exists. It's it. I reserve my right to have a different opinion on this topic. > I think, this fake error can happen in usual applications. But it can be > masked here or be covered by other issues... I think that running java from vm_hint_finalize() provides a way for spurious ClassCircularityError to affect many applications, and I consider recursion in class loader as highly unlikely to encounter in real application. Accordingly, I think that fixing vm_hint_finalize() will fix most applications without introducing complexities of lazy class resolution in JIT. I would like to request for comments on a possible way of getting rid of java execution from vm_hint_finalize(). The initial patch is attached to HARMONY-1952.
Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Gregory Shimansky wrote: > Yes the test is synthetic. But the whole problem arose from the currently > excluded smoke tests gc.PhantomReferenceQueueTest and gc.Finalizer. They too > are synthetic but may be an example of another place where this problem > appears. > > The idea to write user code tests was just to show that finalizers > implementation is not the one to be blamed and the problem is reproducible on > pure user code applications, not to show that this problem is so rare no one > in right mind would ever write an application to encounter it :) Gregory, the problem as I see it is that gc.Finalizer and gc.PhantomReferenceQueueTest are *normal* test cases in the sense that they exercise finalizable objects and phantom references in *exactly* the same way as an application would. And Pavel's synthetic tests (HARMONY-1945) do something allowed by the spec, but entirely uncommon for an application -- recursive call from a classloader to the application.
Re: [drlvm][threadmanager] Fast thread local data access
Mikhail Fursov wrote: > The patch with the results of the discussion is in > http://issues.apache.org/jira/browse/HARMONY-1942 > Please review if interested. Looks great!
Re: [vote] Graduate Apache Harmony podling from the Incubator
+1 out of incubator and to a TLP
Re: "Hot to Write GC" requires improvement
First of all, I would like to make it clear
that I am *for* committing HARMONY-1881 changes.
My point was just a little bit of advertising
the tool which I personally consider the best
for the purposes of documentation authoring.
Morozova, Nadezhda wrote:
> About concern for updating resulting HTML and not the source TXT
> for Asciidoc-generated documents:
> However, for the How to Write a GC document, I do not think that the
> issue is big enough because the doc seems quite stable, no frequent
> changes are intended.
Personally, I don't intend adding anything just now.
But, perhaps, Xiao Feng may want to share some of his experience
of creating generational and/or parallel collectors?
> If we manage to have AsciiDoc produce XML that is valid for site
> purposes = that would be great. It would reduce the whole chain to TXT +
> CONFIG > XML > HTML for website! I do not know AsciiDoc internals that
> well now to say whether that's possible.
Looking from the dumped config file ('asciidoc -c some.text > some.conf'),
I see that asciidoc is configurable inside out: starting from the configurable
syntax (you can configure what kinds of quotes are recognized as quotes),
and through to configuring the exact output templates.
I am sure configuring it for producing XML is perfectly possible.
> Here are a couple of my personal considerations about using the tool for
> Harmony docs:
>
> Strong points:
> * Asciidoc enables using code chunks by references the source file, not
> copy=and=paste from code.
> * Asciidoc is a freeware common tool, why not use it?
> * Asciidoc gets TXT as input, so patching is very easy.
>
> Weak points:
> * We have two technologies for writing for website now: XML directly and
> HTML with to add to XML. Adding a new one can be another
> option (good!) or another confusion (bad!). is the effort worth the
> goal?
Let's "vote with our feet" :)
Anyone writing new documentation picks his/her favourite tool.
> * Asciidoc formatting is unique, resembles Wiki formatting but is
> actually different - confused me when I was starting with it.
In fact, every wiki's formatting is unique.
It never was a problem for me, as getting used to any given wiki
syntax usually took just a couple of hours.
> * Asciidoc references into the source code (to get the code snippet
> directly from the file) rely on a specific line in code - see the
> GC-howto.txt we've been discussing. For example, the comment before the
> function to include the function body into the doc. Now, if you update
> the code, you'll probably update the comment as well - the reference
> gets broken. This does not seem much better than manually copying the
> code into the doc. Don't know how to overcome this.
In fact, this is not an asciidoc limitation, this was just the first solution
that I came up with. There may be better ways, for example something like
adding a explicit cut markers to the code that is supposed to be included
verbatim
into other documents, e.g.
// cut-function-start
void function() {
...
}
// cut-function-end
It would be obvious that these things should not be touched.
And in case of major changes like function rename, the document will need an
update anyway.
-
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][threading] Is it safe to use hythread_suspend_all and hythread_resume_all?
Evgueni Brevnov wrote: > Hi All, > > I'd like to here you opinion regarding hythread_suspend_all and > hythread_resume_all functionality provided by TM. Actually I have to > separate questions: > > 1) I found that hythread_suspend_all calls thread_safe_point_impl > inside. There is no assertion regarding thread's state upon entering > hythread_suspend_all. So it can be called in suspend disabled state > and nobody (at least me) expects to have a safe point during > hythread_suspend_all. The problem seems to be very similar with the > one discussed in "[drlvm][threading] Possible race condition in > implementation of conditional variables?" Your thoughts? The code you see is there to prevent following deadlock scenario: Thread A Thread B | | | < suspend(A); | A->suspend_request = 1; |wait for A to reach a safepoint... | | suspend_all() | B->suspend_request = 1 wait for B to reach a safepoint ... and then two threads are infinitely waiting one another. > 2) Assume I need to suspend all threads in particular group. Ok I pass > that group to hythread_suspend_all. Later when all suspended threads > should be resumed I pass the same group to hythread_resume_all. But > threads were suspended group has changed. For example one new thread > was added to it. So the questions are. Is it acceptable to have such > "unsafe" functionality? Would it better to lock the group in > hythread_suspend_all and unlock it in hythread_resume_all. We may as well leave it as the responsibility of application / TI agent writer not to modify a suspended thread group. Why do you think this should be enforced? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "Hot to Write GC" requires improvement
Svetlana,
I've looked through your changes.
Mostly they look okay, and they greatly improve the visual presentation.
Originally, GC-howto was created using AsciiDoc[1] toolchain from the source
text file and source .cpp file. Modifying .html file directly means that we
cannot
update the document to keep it in sync with the source code.
I guess this is acceptable, since nobody is changing source code inlets in
GC-howto now,
but be warned: if anyone is to introduce source changes, it would tedious
task to synchronize visual and content changes.
Have you tried to configure asciidoc to produce the content you want?
I will send you the version of gc-howto.txt and gc.cpp that I have,
but Nadya may have a later version, so please check with her.
Since I am not sure attachment will make it to the list, I'll send it to you
directly. (* or to anyone else who might be interested, just ask *)
[1] http://www.methods.co.nz/asciidoc/
Konovalova, Svetlana wrote:
> Sorry about that!
> I've created a new patch, hope it's the right one you need. Please let
> me know if you still have any problems.
>
> [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
>
> Cheers,
> Sveta Konovalova
>
> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 17, 2006 8:50 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: "Hot to Write GC" requires improvement
>
> The problem with the patch is that it's to the rendered output
>
> site/xdoc/subcomponent/drlvm/gc-howto.html
>
> when what we need is the patch to the source document
>
> site/xdoc/subcomponent/drlvm/gc-howto-content.html
>
> Can you add a new patch with that please?
>
> geir
>
> Rana Dasgupta wrote:
>> This is a good document, thanks Svetlana. Even if a lot of custom gc's
>
>> don't
>> get written, it helps in understanding the current collecor farmework
> and
>> how it plugs into DRLVM.
>>
>> Rana
>>
>>
>>
>>> On 10/16/06, Konovalova, Svetlana <[EMAIL PROTECTED]>
> wrote:
Folks,
I took a close look at "Hot to Write GC" [1] and created a patch
> for
this doc [JIRA 1881]. I fixed formatting, brushed up the code,
> removed
out-dated tags etc.
It would be great if someone can find a chance to look at the
> patch.
Thanks in advance!
[1]
> http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html
[JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
Cheers,
Sveta Konovalova
>
> -
> 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]
>
>
/**
* Copyright 2005-2006 The Apache Software Foundation or its licensors, as
applicable.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include
#include
#include
#include
#include "open/gc.h"
#include "open/vm_gc.h"
#include "open/vm.h"
#define LOG_DOMAIN "gc"
#include "cxxlog.h"
typedef unsigned char byte;
//
// non-GC utilities
// Included to get critical sections
#include
struct Lock {
CRITICAL_SECTION cs;
Lock() { InitializeCriticalSection(&cs); }
~Lock() { DeleteCriticalSection(&cs); }
void lock() { EnterCriticalSection(&cs); }
void unlock() { LeaveCriticalSection(&cs); }
};
// convenient converter from sizes in bytes to Megabytes
inline int mb (int i) {
return (i + 1048576/2) / 1048576;
}
//
// GC types
// This structure is allocated for each user thread.
// It contains the thread-local allocation area.
struct TLS {
byte* current; // the allocation pointer
byte* limit;// the end of the allocation area
};
struct InteriorPointer {
struct Object* base;
int offset;
struct Object** interior_ref;
};
// Encapsulates all GC data.
struct GC {
unsigned int semisize; // the size of the semispace
unsigned int chunk_size; // the chunk size for thread-local chunks
byte* space;// the pointer to the heap
Lock lock; // the lock t
Re: "Hot to Write GC" requires improvement
Svetlana,
I've looked through your changes.
Mostly they look okay, and they greatly improve the visual presentation.
Originally, GC-howto was created using AsciiDoc[1] toolchain from the source
text file and source .cpp file. Modifying .html file directly means that we
cannot
update the document to keep it in sync with the source code.
I guess this is acceptable, since nobody is changing source code inlets in
GC-howto now,
but be warned: if anyone is to introduce source changes, it would tedious
task to synchronize visual and content changes.
Have you tried to configure asciidoc to produce the content you want?
I will send you the version of gc-howto.txt and gc.cpp that I have,
but Nadya may have a later version, so please check with her.
Since I am not sure attachment will make it to the list, I'll send it to you
directly. (* or to anyone else who might be interested, just ask *)
[1] http://www.methods.co.nz/asciidoc/
Konovalova, Svetlana wrote:
> Sorry about that!
> I've created a new patch, hope it's the right one you need. Please let
> me know if you still have any problems.
>
> [JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
>
> Cheers,
> Sveta Konovalova
>
> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 17, 2006 8:50 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: "Hot to Write GC" requires improvement
>
> The problem with the patch is that it's to the rendered output
>
> site/xdoc/subcomponent/drlvm/gc-howto.html
>
> when what we need is the patch to the source document
>
> site/xdoc/subcomponent/drlvm/gc-howto-content.html
>
> Can you add a new patch with that please?
>
> geir
>
> Rana Dasgupta wrote:
>> This is a good document, thanks Svetlana. Even if a lot of custom gc's
>
>> don't
>> get written, it helps in understanding the current collecor farmework
> and
>> how it plugs into DRLVM.
>>
>> Rana
>>
>>
>>
>>> On 10/16/06, Konovalova, Svetlana <[EMAIL PROTECTED]>
> wrote:
Folks,
I took a close look at "Hot to Write GC" [1] and created a patch
> for
this doc [JIRA 1881]. I fixed formatting, brushed up the code,
> removed
out-dated tags etc.
It would be great if someone can find a chance to look at the
> patch.
Thanks in advance!
[1]
> http://incubator.apache.org/harmony/subcomponents/drlvm/gc-howto.html
[JIRA 1881] http://issues.apache.org/jira/browse/HARMONY-1881
Cheers,
Sveta Konovalova
>
> -
> 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]
>
>
/**
* Copyright 2005-2006 The Apache Software Foundation or its licensors, as
applicable.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include
#include
#include
#include
#include "open/gc.h"
#include "open/vm_gc.h"
#include "open/vm.h"
#define LOG_DOMAIN "gc"
#include "cxxlog.h"
typedef unsigned char byte;
//
// non-GC utilities
// Included to get critical sections
#include
struct Lock {
CRITICAL_SECTION cs;
Lock() { InitializeCriticalSection(&cs); }
~Lock() { DeleteCriticalSection(&cs); }
void lock() { EnterCriticalSection(&cs); }
void unlock() { LeaveCriticalSection(&cs); }
};
// convenient converter from sizes in bytes to Megabytes
inline int mb (int i) {
return (i + 1048576/2) / 1048576;
}
//
// GC types
// This structure is allocated for each user thread.
// It contains the thread-local allocation area.
struct TLS {
byte* current; // the allocation pointer
byte* limit;// the end of the allocation area
};
struct InteriorPointer {
struct Object* base;
int offset;
struct Object** interior_ref;
};
// Encapsulates all GC data.
struct GC {
unsigned int semisize; // the size of the semispace
unsigned int chunk_size; // the chunk size for thread-local chunks
byte* space;// the pointer to the heap
Lock lock; // the lock t
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Geir Magnusson Jr wrote: > Please join the Apache Harmony PPMC in welcoming the project's newest > committers, in alphabetical order : > > Oliver Deakin > Richard Liang > Alexey Petrenko > Gregory Shimansky > Alexey Varlamov > Alexei Zakharov Congratulations, Oliver, Richard, Gregory and Alexey(s)! - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] supported platforms
>> Anyway, my point is that supported platform is not something that we >> non-committers >> can decide on. > > I don't agree. "people" that support platforms become "committers" that > support platforms, and the opinions of non-committers is always > important. A project that exists for the pleasure of it's committers > only is not really our goal in an Apache project. I think you misunderstood me. I agree with importance of non-committers contribution to the project. My point is we can't say that the platform is "supported" until there exist committer who regularly checks and promptly commits fixes for that platform. That's why it is useless to make the list of platforms that someone wants to be supported. It is only actual participation that counts. If someone wants to have a platform X supported, then it will take that person to constantly submit fixes for that platform, earn committership, and keep the platform X running by fixing breakages promptly. And only then we will be able to say that platform X is supported. >> P.S. As of the poll, the platforms I have access to and checking >> occasionally are >> >> Windows/i686 XP >> Linux/i686 SUSE 9 (planning upgrade to SUSE10 soon) >> Linux/x86_64 SUSE 9 (planning upgrade to SUSE10 soon) > > Thanks. We need a clear set of defn's. What is "i686" to you? Pentium M or Pentium 4 or anything newer. It is officially called "Intel Architecture" or ia32 here, but 'uname -m' returns i686. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] supported platforms
Geir Magnusson Jr. wrote: > I think we can define "support" as - "one or more people in the ^^^ I think in place of "people" should be _"committer"_. > community tests on that platform on a regular basis, there are users > that use that platform, and we have people volunteering to find and fix > bugs that specifically affect that platform" As a person who tried to fix Linux/x86_64 problems several times, I can say that the fixes by themselves are not the only thing that matters. The platform can't be considered supported, if at any given moment of time is likely to be broken, and the fixes are likely to be floating somewhere in JIRA. Certainly, Linux/x86_64 can not be considered "supported" now, despite of the fact that *there are* people regularly running it and sending patches. As of the future, when we hopefully will have more committers, I think we can *observe* the increase in number of supported platforms. Each committer will have to decide for himself, which platforms s/he will check before each commit, and what to watch for in JIRA. If the committer is doing job well, then and only then we can declare the platform "supported". And the platform will stay "supported" only as long as committer is keeping it running. Anyway, my point is that supported platform is not something that we non-committers can decide on. P.S. As of the poll, the platforms I have access to and checking occasionally are Windows/i686 XP Linux/i686 SUSE 9 (planning upgrade to SUSE10 soon) Linux/x86_64 SUSE 9 (planning upgrade to SUSE10 soon) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant get error
Paulex Yang <[EMAIL PROTECTED]> wrote: >> Can you access http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip in >> browser? Justin Zheng wrote: > I do cannot access that url. How can I get the access permission? The site is one of public Apache mirrors, so it must be some network availability problem that you cannot access it. I've just tried and file is accessible. Could you please check your internet connection is okay? Meanwhile, you can try using some other Apache mirror, for example, the main one, by making the following change and running 'build.bat update' again. --- build/make/win.properties +++ build/make/win.properties @@ -50,7 +50,7 @@ CLASSLIB_HOME=../../../classlib/trunk/ # Apache Portable Runtime, version 1.1 or above # http://apr.apache.org/download.cgi -remote.APR.archive=http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip +remote.APR.archive=http://www.apache.org/dist/apr/apr-1.2.6.zip # APR-util, version 1.2.2 or above # http://apr.apache.org/download.cgi - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant get error
Justin Zheng wrote: > C:\Harmony\trunk\working_vm\build\make\setup.xml:444: Can't get > http://www.rever > se.net/pub/apache/apr/apr-1.2.6.zip to > C:\Harmony\trunk\working_vm\build\pre-cop > ied\archives\win\APR\apr-1.2.6.zip > > It is Ant get error and I can not resolve it. Can anyone help? It is likely that you can't get the resource or are behind a proxy. 1) Can you verify that getting the specified resource is possible at all? i.e. it is not a site availability issue. Looking from your log, the url is http://www.reverse.net/pub/apache/apr/apr-1.2.6.zip, try downloading it from a browser, if it is fails, then the problem is not in DRLVM build. 2) You may need to configure HTTP proxy by modifying trunk/working_vm/build/win.properties (or even use the internal java properties, like set ANT_OPTS='-Dhttp.proxyPort= -Dhttp.proxyHost=' build.bat update ) put appropriate values instead of and . BTW, there is a wiki page with DRLVM troubleshooting tips, would you mind sharing your experience after solving the problem? http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] An easy task for a DRLVM newby: fix -verbose:class
Hi,
as discussed in HARMONY-1847, -verbose:class currently does not produce output
which is reasonable to expect.
For example, running HelloWorld on JRockit 1.5 produces something like
the below text (only several lines provided).
The right way to fix is to put logging lines in the class loading code,
like
INFO2("class", "[load] opened zip " << zip_file_name);
INFO2 is a macro available by
#include
First argument is the logging category "class",
the second argument is the iostream-style printed message,
concatenated together with operator <<.
The task will take some reading through
enhanced/drlvm/trunk/vm/vmcore/src/class_support/*.c
Any undertakers?
[load ] opened zip c:\java5\jre\lib\jrockit.jar
[load ] opened zip c:\java5\jre\lib\rt.jar
[load ] opened zip c:\java5\jre\lib\jsse.jar
[load ] opened zip c:\java5\jre\lib\jce.jar
[load ] opened zip c:\java5\jre\lib\charsets.jar
[load ] opened zip c:\java5\jre\lib\managementapi.jar
[load ] initiated ? (0x2) 0 0x/java/lang/Object
[load ] define ? (0x2) # 0 java/lang/Object
loader=0x, src=c:\java5\jre\lib\jrockit.jar
[load ] loading ? (0x2) 0 0x/java/lang/Object success (0.41 ms)
[load ] initiated ? (0x2) 1 0x/java/io/Serializable
[load ] define ? (0x2) # 1 java/io/Serializable
loader=0x, src=c:\java5\jre\lib\rt.jar
[load ] loading ? (0x2) 1 0x/java/io/Serializable success (0.05 ms)
[load ] initiated ? (0x2) 2 0x/java/lang/Class
[load ] define ? (0x2) # 2 java/lang/Class
loader=0x, src=c:\java5\jre\lib\jrockit.jar
... many similar lines snipped
-
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] -verbose option does nothing
Jean-frederic Clere wrote:
> Mikhail Fursov wrote:
>
>> Do you expect an output like RI does:
>> [Opened C:\tools\sun1.5.0\jre\lib\rt.jar]
>> [Opened C:\tools\sun1.5.0\jre\lib\charsets.jar]
>> [Loaded java.lang.Object from C:\tools\sun1.5.0\jre\lib\rt.jar]
>> [Loaded java.io.Serializable from C:\tools\sun1.5.0\jre\lib\rt.jar]
>> [Loaded java.lang.Comparable from C:\tools\sun1.5.0\jre\lib\rt.jar]
>> ...
>>
>> Should we be compatible with it by default?
>
> If we have a -verbose option, yes. It is very helpfull to know which
> classes and in which order they are loaded.
>
>>
>> I know that there are several -verbose sub-options, like -verbose:em
>> + we have -Xtrace option for more detailed info. Try -Xtrace,
>> -Xtrace:verifier, -Xtrace:classloader, -Xtrace:gc.
>
> Xtrace:classloader contains what I am looking for it is too verbose.
The intention of -verbose flag was to provide the same information as RI
does. The fact that '-verbose' does not show anything, is a bug.
Technically, -verbose is equivalent to '-verbose:jni -verbose:gc
-verbose:class'.
-verbose:class is also accepted.
In fact, -verbose:xyz will be accepted too, but will not produce any output
unless someone puts INFO2("xyz", "some message") calls into DRLVM sources.
I suspect that no output may be caused by missing flush() call in the
logger call.
-Xtrace:classloader is the developer-oriented debugging output,
as is -Xlog:classloader (trace is more verbose).
These flags are not available in the release build of DRLVM.
-Xtrace:xyz and -Xlog:xyz are also general and correspond
to TRACE2("xyz", "") and LOG2("xyz", "") calls respectively.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Weldon Washburn wrote: >> I actually stumbled on this bug during bringup. I replaced >> ...plus(arrayOffset)... with ...plus(12)... Its a hack. But now it >> looks >> like I simply set ARRAY_BASE_OFFSET to 12 during . Does this >> seem >> right?? By the way, the array base offset may differ depending on the platform and array type. As as I know, currently on 32 bit platform (ia32) the array base offset is 12 for types of size <= 4. Double[] and long[] arrays have array base offset 16. on 64 bit platforms, if the vtable pointers are compressed (they are now), the array base offset is the same as on 32 bit platforms. Should someone disable vtable reference compression, the array base offset will be always 16 (8 bytes vptr + 4 bytes flags + 4 bytes array size). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [wiki] frontpage outdated?
Konovalova, Svetlana wrote: > 2.The property > C:\work\vm-harmony\vm\tests\smoke\classloader\LogLoader.java.keywords > >is not defined. The property common.depends.on.targets is not > defined. > > How about the second one? Don't you think it's worth being mentioned? If it was put to README, then it must have helped someone, and hence is worth of putting to wiki page as well. By the way, feel free to improve the existing text as well. Thanks a lot! - 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][util.prefs] Implementation should be compatible with RI
Elena Semukhina wrote: > I prepared the patch for the test and a sample patch for implementation > which enables the test passing on IBM VME. As I'm not an expert in > util.prefs, I'd like someone to review the patch and add a warning message. > > Unfortunately I did not manage to upload attachments to H-1751; got the > mesage: > > Exception trying to establish attachment directory. Check that the > application server and JIRA have permissions to write to it: > com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment > directory. Check that the application server and JIRA have permissions to > write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1751 > Are > there any problems with attachment directory? > I'll make another try later. I suspect this is the way JIRA suggest that you file a new issue, so that issue has just one contributor / patch submitter. I've seen that message when trying to attach files to issue filed by someone else. Attaching to one's own issues works okay. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] 'Patch available' status
Geir Magnusson Jr. wrote: > You can create your own issue navigator and use that, which will show > patch avail... I am not sure I understand this completely. "Issue navigator" allows me to define my filters and customize column presence and order. I still do not understand how to get 'patch available' information. There exists 'patch info' column, but somehow it is not shown on the issue list page even if it was enabled on the column configuration page. - 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][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
Geir Magnusson Jr. wrote: > If all agree, please submit your change as a patch to that patch :) Sorry for confusion, it wasn't my change, but commented changes from HARMONY-1826. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] DRLVM build on Windows
Oliver Deakin wrote: > Could we also stick a link to this page > in the build readme? It would be good to make it as easy to find > as possible for a first time (and the rest of us) DRLVM builder. Done as README-troubleshooting-link.patch in HARMONY-1828 (on top of HARMONY-1730 README.patch) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] 'Patch available' status
Hi, we had a discussion about adding new searchable 'Patch Available' status to JIRA [1] some time ago. Several people supported the idea, and there were no objections. However, no actions have been made. Geir, have you forgotten about it, or do you have some objections? [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[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][build] Make svn stamping optional
Geir, Mark, any chance of HARMONY-1083 being committed? I've updated it to match the current trunk and also incorporated "best practices" from classlib's build system. Without this change the file version_svn_tag.h ends up changed after every build in my workspace, which is annoying. - 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][jvmti] Last commit of Harmony-1582 brocks JVMTI support for DRLVM.
Pavel Rebriy wrote:
>> > Fix for Harmony-1582 brocks initialization of JVMTI support. I'm
>> > investigating the problem and going to create fixing JIRA as soon as
>> > possible.
> The fix is ready. See http://issues.apache.org/jira/browse/HARMONY-1826
Pavel, I have reviewed the patch in HARMONY-1826, and it looks great!
A couple of minor comments.
The change like this doesn't really move us closer to multi-VM support,
as the jni_env is hardcoded to the emitted code.
-s = mov(s, M_Base_Opnd(esp_reg, 0), Imm_Opnd((int)jni_native_intf)) ; //
o0=jni_native_intf
+s = mov(s, M_Base_Opnd(esp_reg, 0),
Imm_Opnd((int)p_TLS_vmthread->jni_env)) ; // o0=jni_native_intf
The following change seems to fix unrelated issue ('Fixed Single Step event
disabling'?),
so I think it would have been better if it filed as a separate JIRA/patch.
-
ti->vm_brpt->release_intf(vm_thread->ss_state->predicted_breakpoints);
-_deallocate((unsigned char *)vm_thread->ss_state);
-vm_thread->ss_state = NULL;
+if( vm_thread->ss_state ) {
+if( vm_thread->ss_state->predicted_breakpoints ) {
+
ti->vm_brpt->release_intf(vm_thread->ss_state->predicted_breakpoints);
+}
+_deallocate((unsigned char *)vm_thread->ss_state);
+vm_thread->ss_state = NULL;
+}
Anyway, I vote for a quick inclusion of this patch.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[wiki] frontpage outdated?
Hi, after creating a wiki page http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting I was wondering where to link it up, so that it would be 'clickable-through' from the start page. I haven't found any suitable place. Moreover, the front page contains a lot of stuff not directly related to the current state of the project. I suggest to clean up front page by moving most of its contents to pages like 'initial project proposals', 'bookmarks' etc. The content which I think is appropriate for the wiki front page are the following links * component links: class library, jchevm, drlvm * status page links * troubleshooting page links It looks like someone already started cleaning and created the page 'OldFrontPage', but the frontpage is still cluttered. Comments? - 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] smoke test : gc PhantomReferenceQueueTest is really unstable
Gregory Shimansky wrote: > On Monday 09 October 2006 21:01 Pavel Pervov wrote: >> Geir, all, >> I did reserched this failure some time ago. The same failure was observed >> on gc.Finalizers. >> Here is what I've found. >> >> Now what is happening: >> 1) FinalizerThread is being run >> 2) java/lang/Object.notify()V is being compiled >> 3) java/lang/InternalError is being resolved (and loaded) for >> java/lang/Object >> 4) GC happens while creating instance of java/lang/Class for >> java/lang/InternalError >> 5) vm_hint_finalize happens >> 6) java/lang/ref/ReferenceQueue.enqueue is being called >> 7) java/lang/Object.notify()V is being compiled >> 8) java/lang/InternalError is being resolved (and loaded) for >> java/lang/Object >> 9) ClassCircularityError occurs for java/lang/InternalError >> 10) VM returns to step (3) >> 11) Assertion happens in SuccessLoadingClass for java/lang/InternalError >> as LoadingClass instance for this class was removed on step (9) >> >> It can be tried to fix it in class loading, but I can imagine only one >> generic solution for this problem: do not run Java while compiling. I believe the real root cause is running java code from vm_hint_finalize(). A possible solution would be: - rewrite vm_hint_finalize() to just run 'notify' operation, without calling any real java code - handle reference queue in the finalizer thread instead of enqueuing it directly from vm_hint_finalize() thread - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] DRLVM build on Windows
Oliver Deakin wrote: > This should be listed somewhere under "Gotchas while building DRLVM". > It would be useful to have these helpful tips stored for future Harmony > contributors. I see there are already some useful DRLVM docs on the > website - perhaps some kind of "build troubleshooting" section would > also be good? I've started a wiki page DRLVM Build Troubleshooting to collect such recipes. http://wiki.apache.org/harmony/DrlvmBuildTroubleshooting - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] DRLVM build on Windows
Alexey Petrenko wrote: > Salikh, > > I've posted the last few lines from the output. There is no compiler call. > And the error message is the same with the mentioned in the first letter: Ah, I see now. The compiler was never called, and the error is likely to be printed by cctask. It looks like some cctask issue. By the way, grepping for the error message, I found this http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] :) Some more things to check 1) Maybe you have older version of cpptasks.jar in ant/lib? - If yes, remove it 2) Maybe the version that 'build.bat update' placed to build/make/tmp is not 1.0b4? - Download real 1.0b4 version from http://ant-contrib.sourceforge.net/ and compare with the cpptasks.jar in build/make/tmp. - If different, remove build/make/tmp and re-run 'build.bat update' If this all still doesn't help, I'd say we're screwed with respect to the build system. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] DRLVM build on Windows
Alexey Petrenko wrote: > Here is a last commands from build -d > build.native.init: > [echo] ## Building native of 'vm.vmcore' > ... log snipped ... The log you pasted has neither compiler command line, nor error message, so I wasn't able to figure out anything. I hope the reason of failure will be obvious once you see the exact compiler command line arguments, which caused it to complain. Could you please paste the log with the compiler command line and error message? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] DRLVM build on Windows
Alexey Petrenko wrote: > I have not built DRLVM for a few days. > But after last update it fails with the following error on Windows: > native.xml:75: Command line is over maximum length without specifying > source file Can you run 'build.bat -d' and find out the exact compiler command line? It seems that some fileset is broken, and compiler is given no input. And by the way, just 'build.bat clean' and 'rm -rf pre-copied' is not enough for a clean start %) You also need to do rm -rf make/tmp ... or start with a clean checkout - 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] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Geir Magnusson Jr. wrote: > > On Oct 9, 2006, at 9:58 AM, Salikh Zakirov wrote: > >> Geir Magnusson Jr. wrote: >>> I keep getting a failure when running the tests - >>> >>> test_jthread_get_all-threads failling the assertion at >>> test_ti_instrum.c:80 >>> >>> geir >> >> I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9 and >> Ubuntu 6. >> The smoke and unit tests both pass okay with and without HARMONY-1582. > > How did you do it on Ubuntu 6? What compiler? Sorry for the confusion. I've missed the "SUSE9" word in the first message. On top of that, I've used outdated workspace when testing on Ubuntu, so errors I've got before have no sense at all. I have rerunned tests on Ubuntu6 using clean workspace, and the results are: trunk trunk + HARMONY-1582 Linux/ia32/SUSE9: unit and smoke pass unit and smoke pass Linux/ia32/Ubuntu6: unit and smoke pass intermittent failures*** *** On the first attempt, unit tests passed, and smoke tests failed on gc.Finalizer Running gc.Finalizer separately, however, passed. On the second run, unit tests failed: [echo] ERROR: Assertion '(thread_count)==(i + initial_thread_count)' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_instrum.c:80 [echo] INFO: TEST test_jthread_get_all_threads: FAILED [echo] ERROR: Test failed: Wrong number waiting on monitor threads (/export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_instrum.c:149) [echo] INFO: TEST test_jthread_get_blocked_count: FAILED [echo] INFO: TEST test_jthread_holds_lock: FAILED [echo] ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:151 [echo] INFO: TEST test_jthread_get_lock_owner: FAILED [echo] INFO: TEST test_jthread_get_owned_monitors start [echo] ERROR: Assertion '(blocked_count)==(5 - i - 1)' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:212 [echo] INFO: TEST test_jthread_get_owned_monitors: FAILED [echo] ERROR: Assertion 'critical_tts == NULL' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:276 - 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] build failure
Mikhail Loenko wrote: > Works fine on a fresh ws. > > could you please update up to 454342: > missed one file (was: moving HARMONY-1609 (Applet, ImageIO and Print > modules) files to correct locations) > > and try "ant rebuild" Verified. Classlib builds and works okay on revision r454349 cyrillic characters in comments replaced with latins (just next to r454342 missed one file (was: moving HARMONY-1609 (Applet, ImageIO and Print modules) files to correct locations) ) - 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] HARMONY-1582 - invocation API for DRLVM CHECKPOINT
Geir Magnusson Jr. wrote: > I keep getting a failure when running the tests - > > test_jthread_get_all-threads failling the assertion at test_ti_instrum.c:80 > > geir I have just tried to test HARMONY-1582 patch on Linux/ia32 SUSE 9 and Ubuntu 6. The smoke and unit tests both pass okay with and without HARMONY-1582. However, Ubuntu 6 results are somewhat surprising: 1) DRLVM (Jitrino) does not compile on GCC 4.0.3 2) After applying a fix (HARMONY-1783), cunit tests fail on a clean SVN trunk. I thought it would be pointless to try to apply HARMONY-1582 before dealing with the failures. Just for your information, the failures I have seen are: ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:546 INFO: TEST test_jthread_monitor_enter: FAILED INFO: TEST test_jthread_monitor_try_enter start ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_java_monitors.c:90 INFO: TEST test_jthread_monitor_try_enter: FAILED ERROR: Assertion 'critical_tts' failed at /export/users/salikh/drlvm/trunk/vm/tests/unit/thread/test_ti_monitor_info.c:266 INFO: TEST test_jthread_get_owned_monitors: FAILED - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] build failure
Hi,
I cannot build classlib on the latest revision ([r454318] moving HARMONY-1609
(Applet, ImageIO and Print modules) fil
es to) with the following errors:
[javac]
/export/users/salikh/classlib/trunk/modules/accessibility/src/main/java/javax/accessibility/AccessibleRelationSet.java:31:
error: Class or interface declaration expected.
[javac] public AccessibleRelationSet() {
[javac] ^
[javac]
/export/users/salikh/classlib/trunk/modules/accessibility/src/main/java/javax/accessibility/AccessibleRelationSet.java:32:
error: Class or interface declaration expected.
[javac] initStorage();
[javac]^
[javac]
/export/users/salikh/classlib/trunk/modules/accessibility/src/main/java/javax/accessibility/AccessibleRelation.java:32:
warning: .
[javac] public static final String FLOWS_TO = "flowsTo"; //$NON-NLS-1$
[javac]
^
[javac]
/export/users/salikh/classlib/trunk/modules/accessibility/src/main/java/javax/accessibility/AccessibleRelationSet.java:33:
error: Class or interface declaration expected.
... many more errors snipped ...
Reverting back to [r454268] helps.
Can it be that latest contribution was not integrated properly?
Is anyone else seeing (or fixing) this?
-
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] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Mikhail Fursov wrote:
> On 10/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>
>> #3 might have originally been put in the JIT/GC interface because the JIT
>> developers liked it. I can't think of a reason why a GC would prefer
>> this
>> interface over #2 above.
>
> If it could be JIT developers decision we would like not to distinguish
> between bases and mptrs at all.:) I mean to keep only
> 'enumerate(base_or_mptr)' method
> I'm not sure the code JIT generates will be much better in this case, but
> JIT internals will become simpler.
Sorry, as I am already lost in #2, #3 and other denotations, my comment
may turn out to be irrelevant, but I think it is worth noting, that
JIT enumeration interface is actually passed through VM like JIT<->VM<->GC:
JIT calls VM funtion vm_enumerate_root_interior_pointer_with_base(slot,base,...)
vmcore\src\gc\root_set_enum_common.cpp
183 void vm_enumerate_root_interior_pointer_with_base(void **slot_root, void
**slot_base, Boolean is_pinned)
184 {
185 int offset =
(int)(POINTER_SIZE_INT)(*((Byte**)slot_root)-*((Byte**)slot_base));
186 gc_add_root_set_entry_interior_pointer(slot_root, offset, is_pinned);
187 }
And VM in turn calls GC function
gc_add_root_set_entry_interior_pointer(slot,offset,...)
IMHO, the best solution would be to use (slot,offset) everywhere,
and pre-compute and cache offsets before enumerating the base pointer.
Or even enumerate base pointer *after* all interior pointers that depend on it.
-
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/threading] need the two lsb's from object header for MMTk port
Weldon Washburn wrote: > Artem, > I'd like to confirm what you said. For GC_BIT_MASK, it looks like the > bottom > two bits of byte number one is available for exclusive GC use. If the GC > needs to alter these two bits while the mutator(s) are running, the GC > needs > to use CAS on the entire 32 bits of obj_info. Does this sound right? Doing 32-bit CAS while mutators are running looks like a safe solution. However, it can degrade performance considerably. Can we instead consider locking the object monitor before modifying its header bits? - 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] first generational version of GCv5 is submitted
Weldon Washburn wrote: > On second thought, you are right. I don't really should not be hacking on > the framework right now. But at some point, we need to have the GC > selectable at the command line. By the way, the GC *is* selectable on the command line now. Just copy the build gc.dll (or gcv4.dll or whatever it is called) to jre/bin/default, and add the following command line option -Dvm.dlls=gcv4 and it will pick up the specified DLL. Currently, however, the only GC being copied to jre/bin/default directory is default gc from vm/gc/src (GCv41). Other garbage collectors can be compiled by specifying -DCOMPONENTS=vm.gcv4 or similar command lines, provided that correct build descriptor is provided in build/make/components/vm/gcv4.xml (It can be copied from gc.xml and trivially adjusted manually). Unfortunately, this command does not install the non-standard GC into jre/default/bin, so one needs to do the copying step manually. - 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][build]Stale object files are linked to DRLVM
Geir Magnusson Jr. wrote: >>> make? Salikh Zakirov wrote: >> I know you are teasing (^_-) >> Geir replied: > I'm actually not. Were there an additional 24 hours in a day There > is a whole list of reasons why I'm not a fan of the current system, > including maintainability as well as performance. (Building classlib > takes far less time that DRLVM on windows, for reasons I find utterly > perplexing...) Well, performance-wise, using 'make' will not make DRLVM build any faster, mainly because it is hard (if at all possible) to take advantage of compile-many-cpp-files-by-single-compiler-command mode available in MSVC and Intel compilers. I completely agree on the maintainability side. >> I can easily propose a couple of ways to use make >> for building DRLVM (i.e. running C++ compiler and linker). The last >> thing I played >> with was using shell-script for generating Makefiles using the source >> file list. > > Well, cool :) We have the ability to learn from and improve upon > classlib how we want to try and handle platforms correctly... Actually, I do not think I would want to take classlib's make system as the base, because it does not satisfy two requirements I personally consider important: * concentrate the build configuration in one place * automatically deduce object files lists by finding .cpp files And, I would rather add GNU Make (Cygwin or Mingw) to the required build tools, than maintain two copies of make files. - 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][build]Stale object files are linked to DRLVM
Salikh Zakirov wrote: >> Currently DRLVM build system suffers from a deficiency, >> which gets in the way quickly if you experiment a lot with patches. >> If you apply a patch that creates a new file, and build DRLVM, and >> then unapply the patch, and rebuild again, >> the stale .obj file will still get linked to the executable. >> >> Usually, this leads to the spurios linker errors. >> >> Can anyone with Ant/DRLVM build system experience propose a solution? I've spent some time reading Ant manual in all conceivable directions, trying to make ant remove stale .obj files, i.e. .obj files that do not have corresponding .cpp file anymore. The only thing I could come up with was something like ... To make this operation clean up stale.obj files, one would need to list all directories, where .cpp files come from. And there exist .c and .asm files too. So, it looks vastly impractical. Too bad Ant doesn't allow to make operations with filesets, like add, subtract, intersect, map, etc. There always is an option to make a custom Ant task, e.g. for creating a new fileset from existing filesets and a mapper, or for subtracting filesets, but I would not go that way until I know for sure there is no others. Dreaming for a moment, if the following construct was possible in Ant, then the original problem would have been solved by using this "objects" fileset in the link task. Geir replied: > make? I know you are teasing (^_-) I can easily propose a couple of ways to use make for building DRLVM (i.e. running C++ compiler and linker). The last thing I played with was using shell-script for generating Makefiles using the source file list. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][build]Stale object files are linked to DRLVM
Hi! Currently DRLVM build system suffers from a deficiency, which gets in the way quickly if you experiment a lot with patches. If you apply a patch that creates a new file, and build DRLVM, and then unapply the patch, and rebuild again, the stale .obj file will still get linked to the executable. Usually, this leads to the spurios linker errors. Can anyone with Ant/DRLVM build system experience propose a solution? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Bugs priorities
Anton Luht wrote: > Hello, > > Maybe it's worth to explicitly specify priorities for various kinds of > bugs? The advice that appears now near 'priority' drop-down in JIRA > list is general and not Harmony-specific. Bug submitters make decision > mostly by his/her intuition. > > An example of rule set: VM hangs & crashes - critical, Junit tests > failures - major, application failures - major, exception > incompatibility - minor. And what guidelines would you recommend for the corner cases, when something is important for some people, and does not matter for others? For example, some people are trying to get Harmony to run x86_64 and ia64 platforms, while most of the project participants just do not care. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Linux/ia32 fix for Intel Compiler
Nikolay Kuznetsov wrote: > out of curiosity, do you know why it happens that Intel Compiler > requires librt at build time to resolve symbols in run time, while gcc > works fine w/o this option. > Also parent system libset contains librt, but not being forwarded to > hythread (due to ant bug I believe), but if just copy parent libset to > hythread DRLVM will also crush at run time with another error, I > wonder why. I've just checked, without specifying librt explicitly in components/vm/hythr.xml gcc-built libhythr.so picks up librt.so dependency correctly from parent linker definition (targets/common_vm.xml#common.linker), while icc-built libhythr.so does not. Running 'sh build.sh -d' (to pass '-d' argument to ant), and grepping for the libhythr.so build command, one can find out the exact command line used to build the library. (See details below). The difference shows, that cctask does not take inherited syslib into account. (The parent linker definition is defined in make/targets/common_vm.xml, and contains following configuration: 209 210 211 212 Indeed, looks like a bug in cctask. --- cmd.icc 2006-10-05 15:02:38.397439882 +0400 +++ cmd.gcc 2006-10-05 15:02:48.743318641 +0400 @@ -1,10 +1,18 @@ -Executing 'icc' with arguments: +Executing 'gcc' with arguments: '-Wl,-init' -'-Wl,hythread_library_init' '-Wl,--version-script,/files/sszakiro/harmony/drlvm/trunk/vm/thread/src/hythr.exp' +'-Wl,hythread_library_init' +'-Wl,--version-script,/files/sszakiro/harmony/drlvm/trunk/vm/thread/src/hythr.exp' '-g' '-shared' '-o' 'libhythr.so' +'../../../../../../../../../../../usr/lib/libpthread.a' +'../../../../../../../../../../../usr/lib/libz.a' +'../../../../../../../../../../../lib/libm.so.6' +'../../../../../../../../../../../usr/lib/libstdc++.so.5.0.6' +'../../../../../../../../../../../usr/lib/libxml2.a' +'../../../../../../../../../../../lib/librt.so.1' +'../../../../../../../../../../../lib/libdl.so.2' '../_obj/thread_init.o' '../_obj/thread_native_attrs.o' '../_obj/thread_native_basic.o' @@ -21,11 +29,11 @@ '../_obj/thread_native_suspend.o' '../_obj/thread_native_thin_monitor.o' '../_obj/thread_native_tls.o' -'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_icc_debug/semis/vm/port/_bin' +'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/vm/port/_bin' '-lport' -'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_icc_debug/semis/extra/log4cxx/_bin' +'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/extra/log4cxx/_bin' '-llog4cxx' -'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_icc_debug/semis/extra/aprutil/_bin' +'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/extra/aprutil/_bin' '-laprutil-1' -'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_icc_debug/semis/extra/apr/_bin' +'-L/files/sszakiro/harmony/drlvm/trunk/build/lnx_ia32_gcc_debug/semis/extra/apr/_bin' '-lapr-1' - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Linux/ia32 fix for Intel Compiler
Mark Hindess wrote: > Salikh, > > I've applied this fix in r453130. But in future please raise a JIRA. > (As it happens I need this fix to workaround problems I was having > on x86_64 otherwise I'd have probably been more hesitant about applying > it.) Okay, thanks. - 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] apr_dso_load error (path address out of bounds)
Armand Navabi wrote: > I do pass the library load in GDB. If I just run helloworld in gdb it > almost always will print hello world. Here is what happens whenever I > just run it in GDB: > > (gdb) r helloworld > Starting program: > /scratch/anavabi/Harmony/enhanced/drlvm/build/deploy/jre/bin/java helloworld > [Thread debugging using libthread_db enabled] > [New Thread 16384 (LWP 20330)] > [New Thread 32769 (LWP 20333)] > [New Thread 16386 (LWP 20334)] > [New Thread 32771 (LWP 20335)] > Hello World! > [New Thread 49156 (LWP 20336)] > > Program received signal SIGUSR2, User defined signal 2. DRLVM uses SIGUSR2 for thread suspension, so it is convenient to put following configuration into .gdbinit: handle SIGUSR2 nostop noprint pass Though I am a little bit surprised that you see it on a HelloWorld application. Usually thread suspension is initiated by the garbage collection, and HelloWorld usually doesn't allocate as much memory as needed to trigger garbage collection. I've just double-checked, and HelloWorld completes without single SIGUSR2 on my machine (Linux SUSE 9, x86) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
Done. HARMONY-1698. Mark, it looks like you already started looking into it, that's *real* quick. Thanks a lot! Geir Magnusson Jr. wrote: > Can you open a JIRA with this, explaining what needs to be done, and > linking the other JIRAs as needed? > Salikh Zakirov wrote: >> The patch turned out to be exact duplicate of HARMONY-1571. >> Besides, there exist a patch with fixes for unit tests: HARMONY-1574. >> >> The following change is needed on top of already committed HARMONY-1551 >> to make DRLVM start on Linux/x86_64. >> >> However, it still doesn't work properly, failing with >> java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167: >> Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion >> `!(vt() & 1)' failed. The assertion failure were caused by the leftover patch from HARMONY-1372, which didn't make it to SVN (gcv41_em64t_vm_changes.diff) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] E-mail vs. JIRA WAS: [patch][drlvm] Fix compilation on Linux/x86_64
Mikhail Fursov wrote: > I do not like JIRA too, but sending patches by email is even worse: > 1) There are a lot of opened JIRA issues. How to track them all by email? Tracking can be done by replying to messages. And if nobody cares about the patch, JIRA will not help -- patches in JIRA rot with exactly the same rate as they do in e-mail. > 2) New people have no access to the old email threads Not true. Check out http://dir.gmane.org/gmane.comp.java.harmony.devel http://news.gmane.org/gmane.comp.java.harmony.devel (by the way, I read/post using Gmane NNTP gateway, and this also gives a fair amount of older postings). > 3) Patches sometimes are too big to be sent by email. Agreed. E-mail is not a silver bullet, though it comes close :) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
Okay, I will file a JIRA as soon as I have a complete solution.
A side question: do we have a philosophical justification
why we as a project prefer to work through JIRA instead of e-mail?
I personally believe that the instruction will not get any clearer
if it is written in JIRA rather than in e-mail, and also tend to think
that noone will ever want to know why build on a particular platform
was failing at some particular point of time in the past.
Accordingly, I think that transient issues like build failures
are better served with e-mailed patches.
Geir Magnusson Jr. wrote:
> Can you open a JIRA with this, explaining what needs to be done, and
> linking the other JIRAs as needed?
>
> Thx
>
> geir
>
> Salikh Zakirov wrote:
>> The patch turned out to be exact duplicate of HARMONY-1571.
>> Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
>>
>> The following change is needed on top of already committed HARMONY-1551
>> to make DRLVM start on Linux/x86_64.
>>
>> However, it still doesn't work properly, failing with
>> java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
>> Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion
>> `!(vt() & 1)' failed.
>>
>> --- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
>> +++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
>> @@ -68,9 +68,9 @@ static void convertOperand2Opnd(
>> }
>>
>> #ifdef _IPF_
>> -static const char* get_reg_value(
>> +const char* InstructionDisassembler::get_reg_value(
>> InstructionDisassembler::Register reg,
>> -const Registers* pcontext)
>> +const Registers* pcontext) const
>> {
>> assert(0);
>> return NULL;
>> @@ -78,9 +78,9 @@ static const char* get_reg_value(
>>
>> #elif defined _EM64T_
>>
>> -static const char* get_reg_value(
>> +const char* InstructionDisassembler::get_reg_value(
>> InstructionDisassembler::Register reg,
>> -const Registers* pcontext)
>> +const Registers* pcontext) const
>> {
>> assert(0);
>> return NULL;
>>
>> Salikh Zakirov wrote:
>>> Hi gang,
>>>
>>> the below patch fixes the problem that prevents DRLVM from being
>>> compilable
>>> on Linux/x86_64.
>>>
>>> The TI itself does not work on x86_64, and the modification only fixes
>>> compiler error.
>>>
>>> diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> b/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> index d29ef32..b4180f6 100644
>>> --- a/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> +++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
>>> @@ -502,7 +502,7 @@ #endif
>>>
>>> const InstructionDisassembler::Opnd& stub_op =
>>> stub_disasm.get_opnd(0);
>>> assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
>>> -method = (Method *)stub_op.imm;
>>> +method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
>>> }
>>> }
>>
>>
>> -
>> 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][build] deploy.canonical ant task
Geir Magnusson Jr. wrote: > Ok - I'm going to suggest something different that gets you what you > want, namely pass a flag to do the "fill up canonical" rather than pass > the deploy directory. > > That way, the build process is always the same, with an extra step if > you ask for it, rather than have it slightly variable as you suggest in > the patch. > > Make sense? Sounds acceptable to me. (Though I still believe that copying is unnecessary). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch][drlvm] Linux/ia32 fix for Intel Compiler
Hi, DRLVM compiled with Intel Compiler 9.0 on Linux/ia32 currently does not work due to symbol 'clock_gettime' not being found. A simple build file fix is needed to solve the problem. It does not affect DRLVM built with gcc. (Gcc build still works with this modification). Could anyone commit this change? Thanks a lot! --- a/build/make/components/vm/hythr.xml +++ b/build/make/components/vm/hythr.xml @@ -95,6 +95,7 @@ vm.port,extra.log4cxx, extra.aprutil" /> + - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] Fix compilation on Linux/x86_64
The patch turned out to be exact duplicate of HARMONY-1571.
Besides, there exist a patch with fixes for unit tests: HARMONY-1574.
The following change is needed on top of already committed HARMONY-1551
to make DRLVM start on Linux/x86_64.
However, it still doesn't work properly, failing with
java: /files/sszakiro/harmony/drlvm/trunk/vm/gc/src/gc_types.h:167:
Partial_Reveal_VTable* Partial_Reveal_Object::vtable(): Assertion `!(vt() & 1)'
failed.
--- a/vm/vmcore/src/jvmti/jvmti_dasm.cpp
+++ b/vm/vmcore/src/jvmti/jvmti_dasm.cpp
@@ -68,9 +68,9 @@ static void convertOperand2Opnd(
}
#ifdef _IPF_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
@@ -78,9 +78,9 @@ static const char* get_reg_value(
#elif defined _EM64T_
-static const char* get_reg_value(
+const char* InstructionDisassembler::get_reg_value(
InstructionDisassembler::Register reg,
-const Registers* pcontext)
+const Registers* pcontext) const
{
assert(0);
return NULL;
Salikh Zakirov wrote:
> Hi gang,
>
> the below patch fixes the problem that prevents DRLVM from being compilable
> on Linux/x86_64.
>
> The TI itself does not work on x86_64, and the modification only fixes
> compiler error.
>
> diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp
> b/vm/vmcore/src/jvmti/jvmti_step.cpp
> index d29ef32..b4180f6 100644
> --- a/vm/vmcore/src/jvmti/jvmti_step.cpp
> +++ b/vm/vmcore/src/jvmti/jvmti_step.cpp
> @@ -502,7 +502,7 @@ #endif
>
> const InstructionDisassembler::Opnd& stub_op =
> stub_disasm.get_opnd(0);
> assert(stub_op.kind == InstructionDisassembler::Kind_Imm);
> -method = (Method *)stub_op.imm;
> +method = (Method *)(POINTER_SIZE_INT)stub_op.imm;
> }
> }
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[patch][drlvm] Fix compilation on Linux/x86_64
Hi gang, the below patch fixes the problem that prevents DRLVM from being compilable on Linux/x86_64. The TI itself does not work on x86_64, and the modification only fixes compiler error. diff --git a/vm/vmcore/src/jvmti/jvmti_step.cpp b/vm/vmcore/src/jvmti/jvmti_step.cpp index d29ef32..b4180f6 100644 --- a/vm/vmcore/src/jvmti/jvmti_step.cpp +++ b/vm/vmcore/src/jvmti/jvmti_step.cpp @@ -502,7 +502,7 @@ #endif const InstructionDisassembler::Opnd& stub_op = stub_disasm.get_opnd(0); assert(stub_op.kind == InstructionDisassembler::Kind_Imm); -method = (Method *)stub_op.imm; +method = (Method *)(POINTER_SIZE_INT)stub_op.imm; } } - 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][build] deploy.canonical ant task
Pavel Pervov wrote: > Dear all, > > Can we exclude this task from DRLVM's build.xml default task? It takes most > of build time when rebuilding only several files while working with drlvm > code. > > AFAIU, exect content of this directory exists at > ___/deploy directory. The HARMONY-1085 has been filed some two months ago to do just that: stop copying jre from platform-specific directory to just deploy/ directory. I have just updated patches in HARMONY-1085 to match current SVN trunk. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] creation of "jdktools"
Tim Ellison wrote: > +1 for creating a jdktools directory. The dependency on the classlib > launcher should be relatively light if we go with a simple tools > launcher that rewrites the tool invocation into a generic launcher > invocation. You may recall the idea was discussed a while ago. Could anyone shed the light why launcher is considered part of classlib? As far as I understand, it depends on standard JNI Invocation API, and some Harmony-wide conventions about property names and files. I would suggest that we move launcher from classlib/ to jdktools/ as well. Sorry if I am missing something. P.S. +1 for original idea to create jdktools/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch][drlvm] fix junit.jar download
Alexey Varlamov wrote: > Can't we just take junit.jar from classlib's depends (as we do with XALAN)? I agree, that would be a better solution. It just didn't occur to me that we already have it in classlib's depends. So, the below change seems to be sufficient. --- build/make/setup.xml +++ build/make/setup.xml @@ -148,6 +148,8 @@ Version: $Revision: 1.5.2.33 $ + + - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch][drlvm] fix junit.jar download
Geir, it looks like the commit [r452245] HARMONY-698 This should be equivalent to what HARMONY-698 broken the downloading of junit.jar (which we used to take from Eclipse distribution). The below patch adds junit.jar as a separate download from ibiblio jar repository. --- 8< --- added downloading of junit.jar diff --git build/make/lnx.properties build/make/lnx.properties index c4f6c56..1404b5b 100644 --- build/make/lnx.properties +++ build/make/lnx.properties @@ -57,6 +57,10 @@ # APR-iconv, version 1.1.1 or above # http://apr.apache.org/download.cgi remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1.tar.gz +# JUnit, version 3.8.1 or above +remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar +remote.JUNIT.archive.type=asis + # LOG4CXX, svn revision 416779 # http://logging.apache.org/site/cvs-repositories.html remote.LOG4CXX.archive=-r 416779 http://svn.apache.org/repos/asf/logging/log4cxx/trunk diff --git build/make/setup.xml build/make/setup.xml index e570ae0..be28782 100644 --- build/make/setup.xml +++ build/make/setup.xml @@ -105,6 +105,7 @@ Version: $Revision: 1.5.2.33 $ + @@ -148,6 +149,12 @@ Version: $Revision: 1.5.2.33 $ + + + + + + @@ -176,7 +183,7 @@ Version: $Revision: 1.5.2.33 $ - + diff --git build/make/win.properties build/make/win.properties index 51274f1..6753d2b 100644 --- build/make/win.properties +++ build/make/win.properties @@ -60,6 +60,10 @@ # APR-iconv, version 1.1.1 or above # http://apr.apache.org/download.cgi remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1-win32-src.zip +# JUnit, version 3.8.1 or above +remote.JUNIT.archive=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar +remote.JUNIT.archive.type=asis + # LOG4CXX, svn revision 416779 remote.LOG4CXX.archive=-r 416779 http://svn.apache.org/repos/asf/logging/log4cxx/trunk remote.LOG4CXX.archive.type=svn - 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] [launcher] Executable hangs
Egor Pasko wrote: > hm, looks stange to me. I see a def of hythread_exit() in > hythread.c:1530. Why it is not in libhythr.so is a mystery ;) No mistery. hythread_exit() *is* defined in CLASSLIB's libhythr.so, but DRLVM insists on using its own, different, libhythr.so. - 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] [launcher] Executable hangs
Salikh Zakirov wrote: > Armand Navabi wrote: >> ../java: relocation error: >> /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so >> : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so >> with link time reference > > The error DRLVM's version of libhythr.so in fact does not define > hythread_exit(), > I've heard that Artem is currently preparing a patch to fix the problem > by adding hythread_exit() definition. Just for the record, the fix for missing hythread_exit() is available in HARMONY-1590. - 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] [launcher] Executable hangs
Armand Navabi wrote: >> What is the kernel version BTW? There could be some issues with >> 2.4.x, currently everybody works with 2.6.x > > The kernel version is 2.6.17.8. > >> concerning hythread_exit .. Did you resolve it already? I see the >> symbol _undefined_ too (and no definition of the symbol in hythread.so >> or any other lib, although sources are fine, probably some bug in the >> build system), but dynamic linker does not complain on my machine. > > No, I did not resolve this problem. When I try to run ./java by itself I > see the following: > > ../java: relocation error: > /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/libhyprt..so > : symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so > with link time reference The error DRLVM's version of libhythr.so in fact does not define hythread_exit(), I've heard that Artem is currently preparing a patch to fix the problem by adding hythread_exit() definition. >From what I've seen, hythread_exit() is not used by launcher in a "normal" >code path, and this message is only shown when running java without parameters (or if the VM loading failed for some reason). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] new "Getting Started" guides
Geir Magnusson Jr wrote in the http://incubator.apache.org/harmony/quickhelp_contributors.html: >>> As of now, you cannot build from a Cygwin or other alternative shell. Salikh replied: >> This is not exactly the case. >> - DRLVM has provisions in 'build.bat' >> to set up environment using Visual Studio environment file 'vsvars32.bat' >> (and friends). >> >> - if Visual Studio configured system environment during installation, then >> both DRLVM and Classlib >> can be built from any place. Geir interjected: > Have you built classlib successfully with cygwin? Yes. I use Cygwin all the time, and always build classlib from cygwin shell. However, it required a couple of things to configure: 1) during Visual Studio installation, tick "configure system environment" checkbox (or something similar) 2) rm /bin/link -- to make sure the 'link' command unambiguously resolves to Microsoft linker (Cygwin's /bin/link is useless program, similar to /bin/ln) I have also heard from some colleagues, that they were able to configure Cygwin to pick up visual studio environment from vsvars32.bat during bash startup, but do not know the exact details. The only way to configure Visual Studio environment at runtime I know is captured in DRLVM's build.bat. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] new "Getting Started" guides
> http://incubator.apache.org/harmony/quickhelp_contributors.html I have a couple of comments on the contents: 1. > $ ant fetch-depends As I am sitting behind the firewall, I have to use $ ANT_OPTS='-Dhttp.proxyHost= -Dhttp.proxyPort=' ant fetch-depends to make sure ant can download dependencies using HTTP proxy. 2. > As of now, you cannot build from a Cygwin or other alternative shell. This is not exactly the case. - DRLVM has provisions in 'build.bat' to set up environment using Visual Studio environment file 'vsvars32.bat' (and friends). - if Visual Studio configured system environment during installation, then both DRLVM and Classlib can be built from any place. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][gc] HARMONY-1371 applied incompletely
Geir, Ivan, just a heads-up: the patch from HARMONY-1371 was applied incompletely. The below hunk was left out (i.e. it exists in HARMONY-1371, but was not committed to SVN). Is this okay? --- vm/gc/src/init.cpp +++ vm/gc/src/init.cpp @@ -51,7 +51,7 @@ int HEAP_SIZE_DEFAULT = 256 MB; unsigned int prev_mark_phase; bool cleaning_needed = false; -int gc_algorithm = 0; +int gc_algorithm = 30; int gc_adaptive = true; int64 timer_start; int64 timer_dt; - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 Geir Magnusson Jr. wrote: > All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. - 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]A subject to profiling instrumenting
zouqiong wrote: >> > I am now doing two things: >> > 1. track accesses to the three things you refer. And just the same >> > implementation as some >> > rt_helper_***, but the following error happens: >> > java.exec: >> > /root/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_ia32.cpp： >> 1621： void >> > Jitrino::Jet::Compiler::gen_patch(const char*, const >> > Jitrino::Jet::CodePatchItem&): 断言"cpi.target_offset != 0"失败。 >> > abort_handler() >> > >> > This error has been fixed. But I still want to know How to dump out the > native code generated by the VM. Should the liblwdis.so > be written by ourselves? > > Now, although the above error has been resolved, I encounter an new issue. > "SIGSEGV in VM code." This error seems some error happens in generated > code. Segmentation faults in compiled java code are always treated as NullPointerException, no matter what address or operation caused a segmentation fault. "SIGSEGV in VM code." means that the segmentation code occured in C++ code of the VM. gdb should be of much help in this case. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jira issues tracking
> Salikh Zakirov wrote: >> I have also seen that other projects in JIRA use "Patch available" >> status, Geir Magnusson Jr. replied: > We could turn this on for non-committers - I see no danger... does anyone? That would be great! JIRA seems to log all changes to the issues, and important information like comments and attachments is immutable, so the risk of open access is low. However, the "Patch available" status is not currently used by HARMONY JIRA, so I suspect some further action is needed to add the new issue status. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
