Sergey,
It is ok to have not thread safe code in AWT implementation which can
work incorrectly in some cases. It is not ok (IMHO) if the incorrect
work leads to VM crash. It can be problem as a security hole.
--
Best regards,
Ivan
On 11/17/06, Sergey Soldatov (JIRA) [EMAIL PROTECTED] wrote:
Well, I was able to use breakpoints for the libraries still not loaded.
Just type: 'br func' and it will inform you that the library is not
loaded yet and will suggest to make it pending on future shared
library load. When the library will be loaded the breakpoint will be
automatically enabled.
On 11/9/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Salikh Zakirov wrote:
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
On 11/9/06, Etienne Gagnon [EMAIL PROTECTED] 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
Robin,
thank you for detailed description of the algorithm. IMHO, this was
the most complicated place of the whole story: how to have a weak
reference to classloader and still be able to get it alive again. This
shouldn't be performance critical part and is quite doable. I
absolutely agree with
On 07 Nov 2006 14:35:55 +0600, Egor Pasko [EMAIL PROTECTED] wrote:
I already have one idea how to benefit from movable vtables.
in GCV4.1? :)
Yes
--
Ivan
Intel Enterprise Solutions Software Division
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 occasionally use it (GCv4) and a modified version of
GCv4.1 (which can help detect heap access via lost pointers). Most of
the time I prefer second one, but
On 11/2/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
On 11/2/06, Robin Garner [EMAIL PROTECTED] wrote:
Xiao-Feng Li wrote:
On 11/1/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 01 Nov 2006 16:05:41 +0600, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x214 day of Apache Harmony Mikhail
+1 for this approach. It will give us some kind of class unloading
without much performance impact on GC.
--
Ivan
On 11/1/06, Robin Garner [EMAIL PROTECTED] wrote:
Actually, just thinking about how I would implement this in JikesRVM, I
would use the reachability based algorithm, but piggyback
Hi All,
DRLVM now builds and run (interpreter mode) on IPF with HARMONY-2004.
The patch should cause no changes on other architectures.
Currently, in interpreter mode everything works fine but GC. GC fails.
I'm investigating this issue.
--
Ivan
Intel Enterprise Solutions Software Division
, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Hi All,
DRLVM now builds and run (interpreter mode) on IPF with HARMONY-2004.
The patch should cause no changes on other architectures.
Currently, in interpreter mode everything works fine but GC. GC fails.
I'm investigating this issue.
Fixed. Now DRLVM works on IPF in interpreter mode with gcv41.
Started running smoke tests and its passing one by one... well, it is
time to rest...
--
Ivan
On 11/1/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Mikhail,
Yes, I did. It fails at bootstrap on attempt to pin an object
Robin, thank you for this information. I want to ask a few questions
to check that I understand you correctly.
On 10/31/06, Robin Garner [EMAIL PROTECTED] wrote:
MMTk implements several algorithms for retaining the reachable objects
in a graph and recycling space used by unreachable ones. It
On 10/31/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
On 10/31/06, Pavel Pervov [EMAIL PROTECTED] wrote:
7- Each class loader structure maintains a set of boolean flags, one
flag per non-nursery garbage collected area (even when thread-local
heaps are used). The flag is set when an instance
Actually, no need to add the overhead to _all_ cycles. We don't need
to trace the vtables everytime. On minor collections all the pinned
vtables can be linearly scanned, thus most expensive tracing from
object to vtable can be avoided in this case.
--
Ivan
Intel Enterprise Solutions Software
On 10/29/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Mikhail Fursov:
On 10/28/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Aleksey,
1. Mark and scan based approach.
2. Automatic class unloading approach.
In the #2, is there any chance for other components to be notified about
If I understand you correctly, you suggest to increment
per-classloader object counter on allocation... It can be much
overhead with the solution, as most of the objects die young.
Do I miss something?
--
Ivan
On 10/29/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
I have missed some messages of
can be
unloaded (as soon as it is not referenced elsewhere).
Making any sense?
Etienne
Etienne Gagnon wrote:
Ivan Volosyuk wrote:
If I understand you correctly, you suggest to increment
per-classloader object counter on allocation... It can be much
overhead with the solution, as most
Excellent algorithm. I think it makes sense to implement it. If we
can't use on 32 bit machines with plenty of ram, we can use it on 64
bit machines.
What about enabling the algorithm at runtime if required conditions
are met, otherwise falling back to some other algorithm?
--
Ivan
On 10/28/06,
As I can see we are far behind stock java implementation. This can
change after fast path for object allocation gets implemented.
Looking at the data received from stack java, I see that it is only
limited by memory bandwidth so it will not scale when changing number
of CPUs.
--
Ivan
On
On 10/27/06, Tim Ellison [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
I have the same problems when building on J2RE-1.4.2.
When running ant on java5 build works fine.
It looks like the build relies on system (jre's) concurrent package,
not the one build as a part of harmony.
I've fixed
Alex,
The process of detecting unused classloaders eligible for GC and
reclamation of its native resources we call here class unloading.
--
Ivan
Intel Enterprise Solutions Software Division
On 10/27/06, Alex Blewitt [EMAIL PROTECTED] wrote:
As a fairly obvious comment, all JSPs that are
On 10/26/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Egor,
I would rather disagree in most of the details. :(
1) 1/10 of the whole heap is probably very much :)
No. You can't measure performance in method/class numbers and proportions at
all. It's normal situation when only 1% of methods
PROTECTED] wrote:
On 10/26/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
It means 10% more pressure on GC subsystem. In memory intensive cases
it can be up to 10% decrease in performance.
Ivan,
If you have 10% more classes loaded it does not mean that you need 10% more
memory space for all
ourselves
an
even deeper hole.
If it is decided 1904 should not be committed, it might make sense to
close it with won't fix.
geir
On 10/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution
I have the same problems when building on J2RE-1.4.2.
When running ant on java5 build works fine.
It looks like the build relies on system (jre's) concurrent package,
not the one build as a part of harmony.
--
Ivan
On 10/16/06, Stepan Mishura [EMAIL PROTECTED] wrote:
On 10/13/06, Oleg
AFAIU, we have pinned VTables for initial version of unloading
support. This means that we can still rely that VTable will not change
and we can compare it with already known constant. No performance
degradation, no new inter-component contracts.
--
Ivan
On 10/26/06, Mikhail Fursov [EMAIL
+1
--
Ivan
Intel Enterprise Solutions Software Division
On 10/25/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Mikhail, I guess there is miscommunication. I didn't suggest to put GC
TLS data to VM_Thread, I think it should have its own TLS key. My
suggestion is to use single key for GC TLS data
Xiao-Feng, I think there should be no problem to get this to work.
But, I also agree with Mikhail that it could be benefitial to have
data directly available in TLS without additional pointer dereference.
If we will have corresponding interface function to allocate more then
one void pointer at
interface for this, I would like to have any performance data
beforehand, do we any data?
Thank you.
Nik.
On 10/25/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Xiao-Feng, I think there should be no problem to get this to work.
But, I also agree with Mikhail that it could be benefitial to have
data
On 10/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
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
On 10/25/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
It seems JIRA is down for maintenance. If HARMONY-1904 is still open
perhaps it makes sense to put a counter in the while (...) { select...}
loop. And
Good idea.
We can use it in fast path of GC allocation. We can have fast TLS base
access compiled in managed code + constant already known offset of
TLS-fields used by GC. Can be significant speedup in comparison to
current scheme. One thing to care about is intercomponent
communication of TLS
On 10/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Well, I think that the solution is what Geir suggests. One think which
bothers me is following. EINTR can happen in different places and the
situations can be quite rare in some circumstances. It can lead to
hard
One thing to care about is to take correct corresponding jar file for
each gc library. How this can be solved?
--
Ivan
On 10/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Alex Astapchuk wrote:
Mikhail Fursov :
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following
a call to hysock_select.
Does that make sense?
Jeff.
On 10/18/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Why not? I understand your opinion, that EINTR should be handled in
upper layers. But here we have somewhat buggy (strange) implementation
specifics of select() and similar calls.
Good
Why not? I understand your opinion, that EINTR should be handled in
upper layers. But here we have somewhat buggy (strange) implementation
specifics of select() and similar calls.
Good functions like read() and write() and so on doesn't interrupt
with SA_RESTART system calls, but select() does. I
The same for GCv4.1 (on Windows). More then 150 and counting.
--
Ivan
On 10/17/06, Weldon Washburn [EMAIL PROTECTED] wrote:
Geir,
I am running Test.java on windows with an svn revision from late last week.
Right now, it is at Iteration: 140 and still going. Because of MMTk
porting,
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
I have zero problem with the commit as long as it does not imply a
change to
the interface between JIT/GC/VM. I suspect Xiao Feng will find no problems
with the commit. Xiao Feng, please comment.
If there is a
On 10/16/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I have zero problem with the commit as long as it does not imply a
change to
the interface between JIT/GC/VM. I suspect Xiao Feng will find no
problems
with the commit. Xiao
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
GC v4.1 has additional
requirement from VM/JIT in order to support collection during
enumeration. Other existing DRLVM's GCs doesn't has such requirement
and will work just fine either way. There is no interface
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
That kind of statement has no place here - I'm not sure how you can
objectively determine something like that, unless Weldon said I don't
want to spend time understanding this..., don't say it.
Lets keep this technical.
Sorry for that.
I have created a JIRA issue for this problem some time ago.
https://issues.apache.org/jira/browse/HARMONY-1556
It contains the description of what is going on.
--
Ivan
On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Usually with this :
java:
AFAIK, nobody does.
On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Well, it just seems to have gotten worse lately
Anyone working on a fix?
geir
Ivan Volosyuk wrote:
I have created a JIRA issue for this problem some time ago.
https://issues.apache.org/jira/browse/HARMONY
On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
When reviewing HARMONY-1672, there are bits like
res.i = (int32)2147483647;
(not part of the patch, but surrounding code...)
What is the downside for using INT32_MAX or something portable and
appropriate? Wouldnt' that make the
Agree on all points.
--
Best regards,
Ivan
Intel Enterprise Solutions Software Division
On 10/15/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Weldon, I'll try to answer some of your questions. Ivan and Salikh will
correct me.
On 10/16/06, Weldon Washburn [EMAIL PROTECTED] wrote:
1)
Mikhail
Geir, please also apply the HARMONY-1762 fix. It contains one more
DRLVM stability fix, but in this case in GC (v4.1 or gc_cc) component.
HARMONY-1815 contains small and highly desirable fix for EM64T.
Without it the GC doesn't work on the architecture.
--
Ivan
On 10/14/06, Geir Magnusson Jr.
What an interesting discussion! I have just read this out. :)
IMHO, all of the discussion is focused on the scalability of
bazar-like development as it exists here in harmony incubator:
If something wrong is commited, then everyone has broken build or
something doesn't work. - This is bad.
On 10/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
Geir, please also apply the HARMONY-1762 fix. It contains one more
DRLVM stability fix, but in this case in GC (v4.1 or gc_cc) component.
But crashes on Ubuntu 6 - see JIRA. Not applied
I see. I have attached
On 10/13/06, Weldon Washburn [EMAIL PROTECTED] wrote:
As Xiao Feng mentions, memset() is filled with a bunch of complications. We
do not want to dive into writing yet another highly optimized memset()
library. There are plenty of them on the shelf. I would like to set
memset() aside and stay
On 10/13/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/13/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
AFAIU, Mikhail also works on something like fast-JNI - a way to call
native function from managed code. To do this, we need some kind of
representation of native function in java
On 10/13/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/13/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
I don't think that the jit needs to know that an object being finalizable
implies not to invoke the fastpath. This to me suggests that the jit
determines allocation policy. I don't see a
On 10/12/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/12/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
GC, VM gurus!
The problems I see:
1) The problem: GC helper must know GC_Thread_Info struct offsets.
This is no problem. I
Mikhail, there is GCVM interface function exists for this purpose:
Boolean gc_supports_frontier_allocation(unsigned *offset_of_current,
unsigned *offset_of_limit) {
// Need additional support for object offset in native stubs.
*offset_of_current = field_offset(GC_Thread_Info,
On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Ivan,
On 10/11/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Mikhail, there is GCVM interface function exists for this purpose:
Boolean gc_supports_frontier_allocation(unsigned *offset_of_current,
unsigned *offset_of_limit) {
// Need
Agree with pluses and minuses :)
2 Egor, it is not so easy to find 'base' pointer having only interior
pointer to an object. So, base pointer should be saved or it should be
deducible somehow.
Could someone review the changes in the patch to jitrino? I'm afraid I
don't have sufficient knowledge
On 10/5/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Ivan, could this enumeration scenario be possible?
1) JIT reports a base to GC
2) GC relocates the base and updates references.
3) JIT reports MPTR, looks for the base, founds the patched base on the
stack and the resulting offset becomes
references are updated when GC moves object.
1) JIT reports reference 1
2) GC moves object and updates reference 1.
3) JIT reports reference 2, but the reference points to the old place where
the object was.
This is almost the same situation we have today.
On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED
On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Ivan,
I'm agree that the problem we have is more complicated then my example. And
I'm glad to hear that there are no problem with the scenario from my example
today.
Jitrino.OPT uses 3 interface methods to report GC root set:
1. VMEXPORT
On 10/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I would like to have second variant implemented and corresponding
(method3) interface removed as unused anymore. But, I'm not sure if
this is possible. Thread stack enumeration is just
On 10/4/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
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
On 10/5/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 5 October 2006 at 13:48, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Readme is quite helpful. Yesterday, I used google to locate thouse lcms libra
ry.
IMHO, if the build system displayed the link to the README.txt it
could be much easier
On 10/5/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 10/5/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Is this can be a problem? If the base pointer is optimized out and we
will find different object base?
--
Ivan
The base pointer for mptr with unknown offset must live as long as mptr
On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 3 October 2006 at 8:12, Ivan Volosyuk (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-1676?page=comments#action_
12439536 ]
Ivan Volosyuk commented on HARMONY-1676
Working on a patch, I've just wanted to check wether it works on em64t.
It is not that easy as I expected. Yesterday, I have filed
HARMONY-1676 to have classlib built.
Today, I have:
Missing dependency. The file from:
/usr/lib/liblcms.a
should be linked to:
On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 4 October 2006 at 12:59, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 10/4/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 3 October 2006 at 8:12, Ivan Volosyuk (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse
On 10/1/06, FaeLLe [EMAIL PROTECTED] wrote:
Perhaps he means clone the object to a WeakReference then null the original
object ?
That way the only existing copy of that object will be a WeakReference
with my limited
understanding of GC concepts would that no be benificial ?
Regards,
-
Geir, it was JIRA 1372. Currently it is marked as closed after these commits.
It looks like it doesn't compile due to the same mistake Weldon made
after me. To new files was not added to the SVN and only existed in
local copy of repository.
Please deal with the JIRA, either reopen it or commit
I have fixed a problem in gc_alloc(), see HARMONY-1661. After that
test passes on my computer.
--
Ivan
On 10/2/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Ok, I will look at the issue today.
--
Ivan
On 10/2/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/2, Alexey Varlamov [EMAIL
+1 from me.
--
Ivan
Intel Middleware Products Division
On 28 September 2006 at 1:38, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
BCC and ACQs are in.
What say ye? Would it be nice to debug using eclipse debugger in DRLVM?
[ ] + 1 accept this contribution into the project
[ ] -1 don't
It helps to maintain code with less potential problems in it. AFAIK,
GCC 3.x warnings is just a subset of GCC 4.x warnings. So, if we fix
warnings on GCC 4.x the code will compile without warnings on either
version of GCC.
--
Ivan
On 9/25/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
If this is
Salikh, this change was reverted back, as it leads to crashes on some
smoke tests. Look at the harmony-1371 comments.
--
Ivan
On 9/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Geir, Ivan,
just a heads-up:
the patch from HARMONY-1371 was applied incompletely.
The below hunk was left out (i.e.
and duplicates classlib's efforts. We should
get rid of this.
2006/9/23, Ivan Volosyuk [EMAIL PROTECTED]:
You are right. It is different property file:
$JRE/lib/boot/bootclasspath.properties (6kbyte)
The strace looks like following. Not quite effective.
The number of syscalls is greater
/UnsatisfiedLinkError : Failed loading library
libhyzlib.so: DSO load failed
I'm working on the fix.
--
Ivan
On 9/23/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote:
Yes, I've seen the same, please keep us informed if you find a solution.
On 9/23/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
GNU gdb 6.4
On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 23, 2006, at 6:00 AM, Ivan Volosyuk wrote:
I have found a solution to this issue. As before, it helps to setup
LD_LIBRARY_PATH before running launcher.
Lets be clear - it only helped to setup LD_LIBRARY_PATH before for
reasons
You are right. It is different property file:
$JRE/lib/boot/bootclasspath.properties (6kbyte)
The strace looks like following. Not quite effective.
The number of syscalls is greater then all others at the startup of
VM. I would like to file a performance JIRA for the issue, but I don't
quite
Getting back to original topic.
I have managed to get following message on activemq-4.0.2 in release
build of drlvm:
ica-50215-1159047303002-1:0) started
Is that it? What is the exact scenario to try with activemq?
--
Ivan
On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 23,
Actually... This is another bug :)
The one I have found is implementation of putfield bytecode. Yours,
somewhere in resolution code common to interpreter and jitrino.
The first bug is fixed by the patch attached. Fix helps to pass
ActiveMQ startup on interpreter.
--
Ivan
On 9/24/06, Geir
Hi,
While working on windows on DRLVM I introduced some crash situation. I
found out that there are two active crash handlers. One in DRLVM, the
other in launcher/classlib.
I can disable DRLVM's one: -Dvm.assert_dialog=1
But the launcher's crash handler still prevent me to use debugger to
hide the actual problematic point.
--
Ivan
On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Do you mean sig_protect in cmain.c?
geir
On Sep 22, 2006, at 12:22 PM, Ivan Volosyuk wrote:
Hi,
While working on windows on DRLVM I introduced some crash situation. I
found out
On 22 Sep 2006 18:03:02 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1EC day of Apache Harmony Vladimir Gorr wrote:
Why not to reproduce this situation on Windows and not to use the MVS
debugger?
IIRC this problem also exists for Windows.
I love Linux. And many other people do. We
When 'stracing' loading of VM I saw quite inefficient way to load a
file from disk. Reading one byte at a time by read() call. If I'm not
mistaken it was this property file. Is this issue fixed in the JIRA?
(Just curious)
--
Ivan
On 9/22/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Dear
On Sep 22, 2006, at 1:29 PM, Ivan Volosyuk wrote:
Exactly. I would like to have a way to disable the crash handler
invoked in the call.
It is quite painful to locate crashing place when the crash handler
enabled. Even setting breakpoint in the handler doesn't help - stack
at this place has number
I have problems running drlvm from gdb:
(gdb) run
Starting program: /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/java Test
[Thread debugging using libthread_db enabled]
[New Thread -1214326592 (LWP 25698)]
[New Thread -1214510160 (LWP 25701)]
Cannot find user-level thread for LWP 25698:
version of gdb doesn't play along well
with nptl or java launcher which spawn another process.
Try running your java program first and attach gdb to the process.
Ivan Volosyuk wrote:
I have problems running drlvm from gdb:
(gdb) run
Starting program: /home/ivan/svn/drlvm/trunk/build/deploy/jre
On 20 Sep 2006 16:06:07 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote:
[snip]
I've also reproduced the problem with DSO.
Just run 'java' from different directory and will get:
java/lang/UnsatisfiedLinkError : Failed loading library
On 9/20/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, a new attachment is submitted to GCv5 as an update to JIRA 1428.
(https://issues.apache.org/jira/browse/HARMONY-1428), which is a
mark-compaction GC. This GC is going to be connected with last
submission (the trace-forwarding GC) into a
On 20 Sep 2006 17:04:57 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1EA day of Apache Harmony Ivan Volosyuk wrote:
On 20 Sep 2006 16:06:07 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote:
[snip]
I've also reproduced
On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
On 20 Sep 2006 16:06:07 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote:
[snip]
I've also reproduced the problem with DSO.
Just run 'java' from different directory
Hi All,
I have some kind of configuration problem. DRLVM's 'build test' fails
on my machine on kernel tests with attached message. As I can see
junit.jar is added in CLASSPATH in build.sh script, but something not
work as expected. '-Djuint.home=make/tmp' or
'-Djunit.jar=make/tmp/junit.jar'
I have reproduced the problem with the stack trace same as reported by Gregory.
Here is the stack trace of thread starting GC:
#4 0xb7af84bc in sched_yield () from /lib/libc.so.6
#5 0xb7bd5efd in hythread_yield ()
at /home/ivan/svn/drlvm/trunk/vm/thread/src/thread_native_basic.c:296
#6
solution.
--
Ivan
On 9/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 9/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Hi All,
I have some kind of configuration problem. DRLVM's 'build test' fails
on my machine on kernel tests
Artem, it looks like two thread mutually suspended each other.
This is only reproducible when jvmti.patch from the JIRA is applied.
--
Ivan
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I have reproduced the problem with the stack trace same as reported by Gregory.
Here is the stack trace
This is an old code and it is unused for quite some time. Most likely
it is broken.
--
Ivan
On 9/20/06, Craig Zilles [EMAIL PROTECTED] wrote:
I noticed in the file trunk/vm/vmcore/src/util/vm_strings.cpp there
is some code to support the storage of strings in arrays of (8b)
bytes
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Artem, it looks like two thread mutually suspended each other.
This is only reproducible when jvmti.patch from the JIRA is applied.
--
Ivan
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I have reproduced the problem with the stack trace
I think the whole idea with current behaviour of JAVA_HOME is bad.
Launcher should set JAVA_HOME according to it own invocation path.
Launcher should override the variable if it set incorrectly.
--
Ivan
On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote:
That appears to be part of the problem
I have traced down problem to implementation of thin locks.
Here is what I get, look at the stack:
hythread_suspend_other()
unreserve_lock()
hythread_thin_monitor_try_enter()
helper
All this code is executed suspend disabled mode and is not a safe point.
Suppose two threads want to unreserve
Artem, your fix works for me.
Digging in the implementation I have got your idea. I like the fix :)
--
Ivan
On 9/20/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I have traced down problem to implementation of thin locks.
Here is what I get, look at the stack:
hythread_suspend_other
On 19 Sep 2006 18:46:40 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1E9 day of Apache Harmony Ivan Volosyuk wrote:
On 19 Sep 2006 18:13:28 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
On Sep 19, 2006, at 6:34 AM, Egor
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 19, 2006, at 7:27 AM, Ivan Volosyuk wrote:
On 19 Sep 2006 18:13:28 +0700, Egor Pasko [EMAIL PROTECTED]
wrote:
On the 0x1E9 day of Apache Harmony Geir Magnusson, Jr. wrote:
On Sep 19, 2006, at 6:34 AM, Egor Pasko wrote
1 - 100 of 193 matches
Mail list logo
