This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to /pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
All,
I am hoping someone who has worked on compilers can actually do the
JIT modifications. I don't have much experience in compilers.
I am trying to get MMTk write barriers integrated into Harmony DRLVM.
I came up with the following scheme. I don't know if it is correct.
It would be great if
hi, guys
The way to use gen_invoke to call a Java write barrier should work, and
the better way may be inlining the barrier code. Maybe jet can not do
inlining, but jitrino.opt should do it.
Alex's idea is not so bad. It is right that the cost will be high if
we'll have a JNI call on every
Clever trick. But I don't understand why you want to create the
Address object at all. You can probably just invoke a method of
Address to generate an Address object reference, and the method
invoke bytecode can be identified by the JIT compiler easily and
replaced by a nop or whatever proper. In
Congratulations!
On 09.06.2006, at 05:51, Geir Magnusson Jr wrote:
Please join the Apache Harmony PPMC in welcoming the project's newest
committer, Mark Hindess.
Mark has demonstrated the elements that help build a healthy
community,
namely his ability to work together with others,
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to /pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I am happy to take a look at the error, and if it is not a quick fix I
think we can roll back Collections without trouble.
Regards,
Tim
Geir Magnusson Jr wrote:
and the
welcome and well done.
Tim
Geir Magnusson Jr wrote:
Please join the Apache Harmony PPMC in welcoming the project's newest
committer, Mark Hindess.
Mark has demonstrated the elements that help build a healthy community,
namely his ability to work together with others, continued dedication
If it isn't really quick, roll it back and let Nathan fix it...
geir
Tim Ellison wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I am happy to take a look at the error, and if it is not a quick fix I
think
On Mon, Jun 05, 2006 at 11:17:50AM +0100, Tim Ellison wrote:
[Eek! ok so you can see that wasn't intended to go onto the list]
FWIW and IMVHO, this kind of thing is entirely appropriate on-list :-)
Apologies for embarrassing George (... but buy the book anywayg)
I just might!
Tim Ellison
*cheer*! Keep it up, Nathan!
On Mon, Jun 05, 2006 at 08:55:37PM -0400, Geir Magnusson Jr wrote:
Please join the Apache Harmony PPMC in welcoming the project's newest
committer, Nathan Beyer.
- LSD
-
Terms of use :
Yep, that was the plan, but it was a trivial fix (in repo = r412990).
Just wondering how Mikhail/Stepan got it to build? It may be a
consequence of different compiler versions again since I did not see a
compiler error on the Eclipse compiler either.
Regards,
Tim
Geir Magnusson Jr wrote:
If
Whoohooh! Go, Mark, go!
On Thu, Jun 08, 2006 at 11:51:09PM -0400, Geir Magnusson Jr wrote:
Please join the Apache Harmony PPMC in welcoming the project's newest
committer, Mark Hindess.
Look, two footers:
-
Terms of use :
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I didn't update this particular file because I work separately with
security module only.
But I think that you
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
I had a nice chat with Doug today to try to reach a conclusion regarding
j.u.c
Given that everyone else (Sun, IBM, BEA...) seems to use j.u.c, found here
Stepan Mishura wrote:
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I didn't update this particular file because I work separately with
security module
On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrote:
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I didn't update this particular
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
I had a nice chat with Doug today to try to reach a conclusion regarding
j.u.c
Given that everyone else (Sun, IBM, BEA...) seems to use j.u.c, found here
I checked the allow list, and
[EMAIL PROTECTED]
is still there.
I'm assuming that this isn't a real account. Any chance you could
switch to one to test, so you can see the bounceback if there is one?
geir
Tim Ellison wrote:
Stepan Mishura wrote:
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL
A large message should still generate a bounce...
I'll go look to see what the size is.
How large are these messages?
Mark Hindess wrote:
On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrote:
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote:
I see it too.
Stepan /
Garrett Rooney wrote:
SNIP
Now sometimes you do need to have a totally different implementation
for a new platform, but a lot of the time, there can be some minor
ifdefs (based on availability of FEATURES, not platform) that allow
the same file to work on multiple platforms.
Just splitting up
Answering Geir's question #3:
compiler, linker and define arguments are specified via compilerarg,
linkerarg, defineset tags respectively
in .xml subcomponents descriptors depending on OS, compiler, configuration.
You can find DRL VM subcomponent descriptors at
Thanks - I figured that out.
It's an interesting difference from makefiles, as they tend to be more
explicit and local - I can go into a directory and look at the
makefile for the params used for building stuff local to that directory.
geir
Denis Sharypov wrote:
Answering Geir's question #3:
The most recent success message was 343k at approximately
Fri, 09 Jun 06 11:26:34 +0100.
-Mark.
On 9 June 2006 at 6:33, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
A large message should still generate a bounce...
I'll go look to see what the size is.
How large are these messages?
I'm doing a few things. I've set aside my drive to replace the build
for now, and just want to get it using current classlib as a start.
To that end, I'm :
- tweaking the build to accommodate the structural changes recently made
to classlib (hdk et al)
- trying to normalize the use of apr
any clue about how big a failed message is (if you can figure that out...)?
geir
Mark Hindess wrote:
The most recent success message was 343k at approximately
Fri, 09 Jun 06 11:26:34 +0100.
-Mark.
On 9 June 2006 at 6:33, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
A large message should
The patch that accommodate the structural changes recently made
to classlib and removing the classlib patching and JIRA additions is ready
and will be sent soon.
--
Denis Sharypov,
Intel Middleware Products Division
On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I'm doing a few things.
Just about to go offline, but I'd guess smaller since not as much works!
;-)
-Mark.
On 9 June 2006 at 7:01, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
any clue about how big a failed message is (if you can figure that out...)?
geir
Mark Hindess wrote:
The most recent success message
Sorry, I'm already wading through it. I'll be happy to see it to use
for reference though.
If someone is going to work on something, please speak up here first.
geir
Denis Sharypov wrote:
The patch that accommodate the structural changes recently made
to classlib and removing the classlib
do you mean larger? I was wondering what the size is so I can see if
it's the threshold set on the list, or something else...
geir
Mark Hindess wrote:
Just about to go offline, but I'd guess smaller since not as much works!
;-)
-Mark.
On 9 June 2006 at 7:01, Geir Magnusson Jr [EMAIL
On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Thanks - I figured that out.
It's an interesting difference from makefiles, as they tend to be more
explicit and local - I can go into a directory and look at the
makefile for the params used for building stuff local to that directory.
Yes, I have done this in VMThread.run() method for newly created
threads. But I have seen no way to do this in JNI's ThreadAttach().
Looks like gnu classpath doesn't require any callbacks (like
thread_attach()) to be called on the attached thread, so the jchevm
doesn't do this. That is why in
Alexey Petrenko wrote:
2006/6/8, Tim Ellison [EMAIL PROTECTED]:
Alexey Petrenko wrote:
2006/6/8, Mikhail Loenko [EMAIL PROTECTED]:
what are the benefits?
The main benefit for me is to have possibility to use all the 1.5
extensions without any problems.
We will need to make this step
Thanks for this. I'm figuring it out. It's pretty logical once you
start to figure it out in that you can start to guess where things might
be. There seem to be multiple places that would be valid w/
parent-child relationships, but that's no different than make. I don't
like what I'm guessing
Ivan Volosyuk wrote:
Yes, I have done this in VMThread.run() method for newly created
threads. But I have seen no way to do this in JNI's ThreadAttach().
Ah, ok got it.
Looks like gnu classpath doesn't require any callbacks (like
thread_attach()) to be called on the attached thread, so the
Geir Magnusson Jr wrote:
do you mean larger?
It may be larger if the last test fails with a walkback ;-) but
generally the build fails part way through, with a message, and the rest
of the log is not written, so it is smaller overall.
Regards,
Tim
I was wondering what the size is so I can see
Currently two VM subcomponents - vmi and kernel_classes - explicitly depend
on classlibs.
It's needed to get rid of this and then bootstrap prebuilt harmony classlib
while building vm subcomponents.
Here're the extracts from the correponding xml descriptors describing
dependency:
project
Geir Magnusson Jr wrote:
snip
Denis Sharypov wrote:
I would like to give the background on how the build system is designed and
then
give answers for the specific questions.
The build system provided with the VM is designed to be able to build the
whole harmony codebase
no matter how many
On 6/9/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Clever trick. But I don't understand why you want to create the
Address object at all.
hmm... please read my example again. I do not create an Address
object. And the call to invokespecial is nop'ed.
You can probably just invoke a method of
Ok, actually I meant to write:
int xx = 33;
Address a1 = Address.creat(xx);
so that the bytecode sequence has no stuff for object new. JIT only
needs to recognize Address.creat() as an intrinsic for compilation
without bytecode rewrite.
And yes, I agree that an Address can be
So we need answers from DRLVM and jchevm guys...
Archie has expressed the jchevm opinion in favour of the change --
anyone familiar with DRLVM care to comment?
(Of course this would be after Geir's VM build work, just asking)
Regards,
Tim
DRLVM needs some (minor) changes to support
As far as I can see classlib uses port library libprt.so which is
intended to be used by VM as low level layer above OS threading
system. Some kind of abstraction of underlying OS primitives. The port
library is widely used in classlib. The port library data is
accessible via TLS (it is done imho
Tim Ellison wrote:
Alexey Petrenko wrote:
2006/6/8, Tim Ellison [EMAIL PROTECTED]:
Alexey Petrenko wrote:
2006/6/8, Mikhail Loenko [EMAIL PROTECTED]:
what are the benefits?
The main benefit for me is to have possibility to use all the 1.5
extensions without any problems.
We will need to
While some works going on to properly integrate DRLVM in harmony build system...
I would like to start development of new garbage collector. I know
about Weldon's work related to MMTk. I am not sure that it is the
right way.
Instead of doing GC based on java, I would concentrate on the one
Is there any interest in having summaries of JIRA activity sent to the
list once a week? Something like the following perhaps sent to the
commits list every Sunday at midnight or something?
Regards,
Mark
Summary of JIRA activity since 2006-06-02
=
New
On 9 June 2006 at 18:06, [EMAIL PROTECTED] wrote:
Author: geirm
Date: Fri Jun 9 11:06:17 2006
New Revision: 413113
URL: http://svn.apache.org/viewvc?rev=413113view=rev
Log:
tweaks to stop the apr-1/foo.h stuff, and
just do foo.h for APR includes. Not a big deal
but let me get more
Alexey Varlamov wrote:
So we need answers from DRLVM and jchevm guys...
Archie has expressed the jchevm opinion in favour of the change --
anyone familiar with DRLVM care to comment?
(Of course this would be after Geir's VM build work, just asking)
Regards,
Tim
DRLVM needs some
I just did a small checkin of minor mods of the current build system and
VM source that changes how the APR headers are treated.
It's a simple, minor change
#include apr-1/apr.h
becomes
#include apr.h
the real benefit is that I learned a bit more about how the build stuff
works :)
I've
I promise that if we need logging then I'll personally volunteer to
uncomment those same lines, and let Alexei make fun of me while saying
'I told you so'.
in Russian.
I can do it in several languages of your choice (Russian, English,
Japanese) if this helps to resolve the situation with
Oh geeze. How embarassing. I assume you fixed?
(I was going to flip to my VMWare Ubuntu VMM but it's too slow. I have
a second laptop I will install Ubuntu on, but don't have enough Round
Tuits...)
geir
Mark Hindess wrote:
On 9 June 2006 at 18:09, [EMAIL PROTECTED] wrote:
Author: geirm
After you've got everything built and you have the PDE's Target Platform
pointing at the 'deploy\jdk\jre\lib\boot' folder you should just need to add
the luni-kernel-stubs.jar to your build path. Most of the dependencies
should be resolved as Plug-in Dependencies. You'll also need to add the
-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
I had a nice chat with Doug today to try to reach a conclusion
regarding
j.u.c
Given that everyone else (Sun,
Yep, in fact recent builds of Eclipse can cope with the kernel jars if
you specify -Dpde.allowCycles=true as well as -Dpde.jreProfile=none on
the launch-line.
(We should plan to put the stubs and tests support jars into the HDK
when we get there, but yes, in the meantime link/load it into the
53 matches
Mail list logo
