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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
Alexey Petrenko wrote:
Salikh could you please attach your patch to the HARMONY-1897
specified by Alexei?
done
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
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
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
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
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
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 open/hythread_ext.h
#define USEC_PER_SEC INT64_C(100)
-#define VmThreadHandle
Geir Magnusson Jr. wrote:
Why not use junit?
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
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
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
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
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
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
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
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
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)!
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
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
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
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
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
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
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 clinit. Does this
seem
right??
By the way, the array base offset may differ
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
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
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
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
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
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
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)
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
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
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.
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]
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)
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 :
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
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
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
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
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
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
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:
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
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
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
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
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
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.
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
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:
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
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
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
platform_arch_compiler_config/deploy directory.
The
(
#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
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
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
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
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
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
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
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
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
+++
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
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
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.
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
+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,
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;
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=proxy.host -Dhttp.proxyPort=proxy
port' ant fetch-depends
to make
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
Hi,
I have just tried to use JIRA to see how many unapplied patches are there for
DRLVM,
but couldn't search just for the issues with patch provided.
Does anyone know of a good way to find just the issues with patches submitted?
If there is no good way, probably subtasks feature of JIRA could
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
Ivan Volosyuk wrote:
Yes, I have experimented with per-slot verification of write barrier.
The idea was the following: each word in java heap has external mirror
record. After garbage collection all mirror records are synchronized
with the heap. Each write barrier updates mirror record with
Weldon Washburn wrote:
Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h
defines the use of *(ref_ptr +4) for 32-bit environment. Just
guessing that #define BUSY_FORWARDING_OFFSET 0 is intended to tell
the GC that it can use the least significant bit out of these four
bytes.
Geir Magnusson Jr. wrote:
All is in order and in SVN for Harmony-1105 wrt BCC and ACQ.
...
+1
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Geir Magnusson Jr. wrote:
All is in order and in SVN for Harmony-1125 wrt BCC and ACQ.
...
+1
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Vladimir Ivanov wrote:
build of drlvm failed today on my pc with message:
[cc] compile.cpp
[cc] C:\harmony\drlvm1.5\vm\vmcore\src\jit\compile.cpp(750) : error
C3861: 'get_default_stack_size': identifier not found, even with
argument-dependent lookup
This definitely has
Iñigo wrote:
C:\Archivos de programa\FreeMind\libjava -Xmx1g -verbose:gc* -jar
freemind.jar
GC v4 M1-39 (2006-03-28)
GC will incrementally slide compact at each GC, using algorithm = 2
Chunks will be swept on allocation
WARNING: final heap size is too large, reduced to 900 Mb
java heap
: news [mailto:[EMAIL PROTECTED] On Behalf Of Salikh Zakirov
Sent: Tuesday, August 15, 2006 2:20 AM
To: harmony-dev@incubator.apache.org
Subject: [drlvm] newlines in .cpp and .h files
Nathan,
your last commit
r431519 | ndbeyer | 2006-08-15 07:46:26 +0400 (Tue, 15 Aug 2006) | 1
line
Iñigo wrote:
Hello:
I was trying to run Freemind under Windows XP Home Edition SP 2
using the latest harmony snapshot (August 4th). I have already run it in
Ubuntu Dapper, and it went fine, although freemind was not capable of
exporting to other formats (I think it is because
Nathan Beyer wrote:
We definitely need to do something. I spent the last few hours trying to
build/add a smoke test for a patch [1] and have gotten absolutely no
where. I had to change the smoke.test.xml file to compile against the JRE
being built, so I could get it to compile, but after that
1 - 100 of 163 matches
Mail list logo
