Thanks Alexey, I think the comparison[1] between java6 and java5 is also useful.
[1]
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk6-jdk15.html
On 4/18/07, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
oops, here is a link to japitool comparison:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk6-ha
On 4/18/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2007/4/18, Mikhail Fursov <[EMAIL PROTECTED]>:
> Nathan,
> I checked the patch and it looks OK except a one issue.
>
> I do not really like that we have new p5.emconf in codebase and propose
the
> following improvement:
> 1) add p5 pass to a
I think that we make GCv5 default a week before the milestone since it
gives us some benefits.
And if we discover any stability or other issues we always can switch
it back before the milestone.
SY, Alexey
2007/4/18, Rana Dasgupta <[EMAIL PROTECTED]>:
In addition to specs and eclipse, there are
2007/4/18, Mikhail Fursov <[EMAIL PROTECTED]>:
Nathan,
I checked the patch and it looks OK except a one issue.
I do not really like that we have new p5.emconf in codebase and propose the
following improvement:
1) add p5 pass to all Jitrino.OPT codegen aliases in every emconf we have.
(I can upda
oops, here is a link to japitool comparison:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk6-harmony.html :)
2007/4/18, Alexey Petrenko <[EMAIL PROTECTED]>:
2007/4/18, Tony Wu <[EMAIL PROTECTED]>:
> Thanks Stepan and all the people who helped to boost, now we have a
> branch for java 6 classlib
2007/4/18, Tony Wu <[EMAIL PROTECTED]>:
Thanks Stepan and all the people who helped to boost, now we have a
branch for java 6 classlib.
Before we start to complete the new feature, I think we should have an
agreement addition to Good issue resolution guideline[1].
I just draft 2 points here in
It would be nice to add some info on changes between v5 and v6, maybe
a reference to JAPI report or smth.
2007/4/18, Tony Wu <[EMAIL PROTECTED]>:
Thanks Stepan and all the people who helped to boost, now we have a
branch for java 6 classlib.
Before we start to complete the new feature, I think
On 4/18/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
> On 4/18/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> > Mikhail,
> >I have no problem with the ones you updated, but some questions...
> >
> > Is VM_RT_WRITE_BARRIER_FASTCALL in
On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 4/18/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> Mikhail,
>I have no problem with the ones you updated, but some questions...
>
> Is VM_RT_WRITE_BARRIER_FASTCALL in use?
This helper is dead code today. AFAIR gcv5 uses VM_RT_GC_H
Nathan,
I checked the patch and it looks OK except a one issue.
I do not really like that we have new p5.emconf in codebase and propose the
following improvement:
1) add p5 pass to all Jitrino.OPT codegen aliases in every emconf we have.
(I can update the patch if agreed)
2) a. After the commit:
Would anyone else like to review this patch? It's somewhat
significant. I've tested it on a P4/WinXP and DRLVM works without any
noticeable regressions. I've done some initial tests on a Quad
P3/Ubuntu and I can now run a simple Hello World with the default JIT,
which is a huge step.
If no one ha
Thanks Stepan and all the people who helped to boost, now we have a
branch for java 6 classlib.
Before we start to complete the new feature, I think we should have an
agreement addition to Good issue resolution guideline[1].
I just draft 2 points here in order to use the little to get the big.
I think I have this resolved with this commit [1]. I'm now able to run
DRLVM in interpreted mode on my Quad P3 ... at least a 'Hello World'
app.
-Nathan
[1] http://svn.apache.org/viewvc?view=rev&rev=529880
On 4/18/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
I've run into another SSE2 operation
Naveen,
Unguard was invented at the times when Jitrino did not have value profile
and does the same thing as the value profile does but less precise. We don't
inline at the first compilation and devirtualization without inlining gives
only overhead. Since we can't predict where we'll miss in heur
Hi,
> > > > What the reason for calling classlib's build in this way? Why we have
> > > > to run 'ant.bat' (or 'ant.sh' for Linux) via ?
> > >
> > > It's workaround for Ant's OutOfMemory problem arising after doing the same
> > > by target. The -rebuild of classlib project causes big memory
> >
On 4/18/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Mikhail,
I have no problem with the ones you updated, but some questions...
Is VM_RT_WRITE_BARRIER_FASTCALL in use?
This helper is dead code today. AFAIR gcv5 uses VM_RT_GC_HEAP_WRITE_REF
today.
And are the monitor enter/exit function
I've run into another SSE2 operation in DRLVM, this time it's in the
hythr library, but I can't find the specific instance. According to
GDB, it's happening in fast_thread_array() in libhythr.so.
Is this from the 'apr_thread_ext.c' file? I'm going to attempt to
modify this to be like the changes
On 4/18/07, Maksim Ananjev <[EMAIL PROTECTED]> wrote:
Mikhail, thanks! Your guidelines helped.
Now I see that ABCD fully eliminates the check in my example if placed
between uce and lower:
-XX:jit.CS_OPT.path.optimizer=ssa
,devirt,inline,uce,purge,simplify,dce,uce,lazyexc,
memopt,simplify,dce,
Mikhail, thanks! Your guidelines helped.
Now I see that ABCD fully eliminates the check in my example if placed
between uce and lower:
-XX:jit.CS_OPT.path.optimizer=ssa,devirt,inline,uce,purge,simplify,dce,uce,lazyexc,
memopt,simplify,dce,uce,classic_abcd,lower,dessa,statprof,markglobals
I trie
On 4/18/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
In addition to specs and eclipse, there are the tests that come with
"build test". Are there any more tests we are worried about?
It can be unrelated to JavaOne milestone but we must start thinking that we
are worried about any application
In addition to specs and eclipse, there are the tests that come with
"build test". Are there any more tests we are worried about?
I understand the risk of switching before an event, but we will have
to do it at some point. Not much point in writing it and then not
using it. Doing it still gives u
On 4/18/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
I'm going to integrate finally HARMONY-3291 (Fast TLS access on Linux
(IA32&Intel64), hopefully today. Actually this is not a threading
issue, it affects JIT mainly. No stability risk, it either works or
not.
+1 here. This patch is about 2
I'm going to integrate finally HARMONY-3291 (Fast TLS access on Linux
(IA32&Intel64), hopefully today. Actually this is not a threading
issue, it affects JIT mainly. No stability risk, it either works or
not.
2007/4/18, Weldon Washburn <[EMAIL PROTECTED]>:
On 4/17/07, Tim Ellison <[EMAIL PROTECT
This method is good, but not perfect, for
1. getNextPortsForUDP get a free port by a mechanism "get and
release", but release the port may not be successful (e.g, in linux)
2. even it releases successfully, during the period between utility
method "release" and serversocket reuse it, there may be
Well, putting it reversed, GCv5 is always there to switch to if
desired, the question is whether it is default GC. I consider
switching in the last week as too risky...
Things might be different if we had a couple of weeks to test it.
2007/4/18, Xiao-Feng Li <[EMAIL PROTECTED]>:
On 4/18/07, Mikh
+1 to rename
2007/4/18, Nathan Beyer <[EMAIL PROTECTED]>:
Cool, thanks.
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> On 4/18/07, Nathan Beyer wrote:
> > If there aren't any objections, I'd like to rename it soon, while
> > everything is still fresh.
> >
>
> Agree. We can do it in the
Hi Nathan,
Many testcases in ServerSocketTest use port 0 to start the server then
call getLocalPort to get the actual port.
BTW, the PortManger.getNextPortsForUDP makes use of port 0 to get the
real port number. It's safer, I suggest to replace all the getNextPort
with this method in our code.
O
It's quite risky to switch right before the show.
Xiao-Feng, what workloads you tried with gcv5 except specs and eclipse?
+
I'm working on "lazy resolution" task in both JITs now and going to submit
the patch this week for
review. I think its commit should be delayed for a few weeks until
JavaO
Cool, thanks.
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 4/18/07, Nathan Beyer wrote:
> If there aren't any objections, I'd like to rename it soon, while
> everything is still fresh.
>
Agree. We can do it in the next way: we wait during 24 hours and if
there are no objections I'll
An old problem that we already noticed, I guess still there's a lot of
tests using getNextPort().
+1 for using port 0
2007/4/18, Nathan Beyer <[EMAIL PROTECTED]>:
For the slow (and lazy), can you point me to one of the tests that
just uses port 0.
Thanks.
-Nathan
On 4/17/07, Tim Ellison <[EMA
On 4/18/07, Nathan Beyer wrote:
If there aren't any objections, I'd like to rename it soon, while
everything is still fresh.
Agree. We can do it in the next way: we wait during 24 hours and if
there are no objections I'll rename it.
-Stepan.
-Nathan
On 4/17/07, Stepan Mishura wrote:
> On 4
On 4/18/07, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Do you think we should switch before "end of month"?
Yes, that's my suggestion.
It's certainly a risk, but what is the value in the switch?
The risk is minimal since GCv5 is rather stable, and to the least we
have command line option to
If there aren't any objections, I'd like to rename it soon, while
everything is still fresh.
-Nathan
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 4/18/07, Nathan Beyer wrote:
> I don't mean to be picky, but why the name "java6-branch" [1]? The
> parent folder is already "branches";
Do you think we should switch before "end of month"?
It's certainly a risk, but what is the value in the switch?
Thanks,
Mikhail
2007/4/18, Xiao-Feng Li <[EMAIL PROTECTED]>:
GCv5 might be one "major" that we want to put as default GC in DRLVM.
It still has some issues pending, but overall I thi
On 4/18/07, Nathan Beyer wrote:
I don't mean to be picky, but why the name "java6-branch" [1]? The
parent folder is already "branches"; can we just rename it to "java6"?
I don't have strong preference for that. I saw branch's names in
repositories with "branch" suffix and without. So no object
GCv5 might be one "major" that we want to put as default GC in DRLVM.
It still has some issues pending, but overall I think the stability is
good enough for a switch next week.
Since GC is designed with good modularity, we can simply choose which
GC implementation to use in command line with
'-XX
For the slow (and lazy), can you point me to one of the tests that
just uses port 0.
Thanks.
-Nathan
On 4/17/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ruth Cao wrote:
> You are right, Vladimir.
>
> It is just because the 'port' variable is set to 8080 and on some
> machines this port has alre
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 4/17/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> On 4/16/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> > On 4/17/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > > On 4/16/07, Spark Shen <[EMAIL PROTECTED]> wrote:
> > > > +1.
> > > >
> >
I don't mean to be picky, but why the name "java6-branch" [1]? The
parent folder is already "branches"; can we just rename it to "java6"?
[1]
http://svn.apache.org/repos/asf/harmony/enhanced/classlib/branches/java6-branch/
-Nathan
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
Done at
Thanks for fixing that. I was waiting for the build notices to see
what failed, but I decided to go to bed. :(
Thanks again.
-Nathan
On 4/17/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Vladimir Ivanov wrote:
> Build of Harmony on Linux x86_64 is broken today (log is below). Seems
> the gui
On Wednesday 18 April 2007 00:26 Tim Ellison wrote:
> Gregory Shimansky wrote:
> > Below is my evaluation of the bug HARMONY-2669. I think it is in ICU4JNI
> > native code. The possible solution for it is to recompile ICUInterface34
> > libraries from patched sources and file a bug on ICU meanwhile
Gregory Shimansky wrote:
> Below is my evaluation of the bug HARMONY-2669. I think it is in ICU4JNI
> native code. The possible solution for it is to recompile ICUInterface34
> libraries from patched sources and file a bug on ICU meanwhile.
>
> I would like to know, what sources were used to com
On 4/17/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> Are all the threading changes Weldon and Co. are in the process of
> making going to make it by next week?
>
> If not, should we freeze threading changes till the snapshot is done?
> Weldon?
Most likely the above is wha
Rana Dasgupta wrote:
> Are all the threading changes Weldon and Co. are in the process of
> making going to make it by next week?
>
> If not, should we freeze threading changes till the snapshot is done?
> Weldon?
Weldon said in [1] there is way more work than we can do (and get
stable) for this
Hello
Below is my evaluation of the bug HARMONY-2669. I think it is in ICU4JNI
native code. The possible solution for it is to recompile ICUInterface34
libraries from patched sources and file a bug on ICU meanwhile.
I would like to know, what sources were used to compile ICU4JNI for windows
an
Are all the threading changes Weldon and Co. are in the process of
making going to make it by next week?
If not, should we freeze threading changes till the snapshot is done? Weldon?
On 4/16/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Mikhail Fursov wrote:
> Could it be better if we mark bugs th
Mikhail,
I have no problem with the ones you updated, but some questions...
Is VM_RT_WRITE_BARRIER_FASTCALL in use?
And are the monitor enter/exit functions all interruptible?
Rana
On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 4/17/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
On 4/17/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
However, there is still some triage needed on which helper is
uninterruptible and which is not and why. Is that going to happen over
time and the interface method will be updated?
I hope I did no mistakes marking some helpers as uninterruptib
I may have misunderstood the intent of this thread.
The jit needs to know which helpers are uninterruptible for several
reasons, and it is convenient for it to ask the VM in one place rather
than hardcode. So the interface change on both sides is good and
commitable ( if tests pass etc. )
Howeve
Wow! Thanks for testing it Pavel!
However, should unguard be disabled? As I understand it, won't most
virtual calls be devirtualized using the static heuristic during
first compilation? It is fairly accurate, but unguard will remove
the ones that are unprofitable. This seems intelligent
Pavel Ozhdikhin wrote:
> I've tested HARMONY-3630. Profile-guided devirtualizations gives ~2%
> improvement on SPECjbb2005 which is impressive!
Definitely worth having! Good job Naveen.
Tim
The test java.awt.ButtonRTest fails for me on an unattended WinXP/x86
machine running the HUTs via Continuum. The test is reproduced below,
and I've marked the failing assertion.
Can any AWT expert help? If I modify the test to bail if the event is
not heard (i.e. return if (li.e == null)) then
Thanks, I will check it today.
On 4/17/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> There is a break in Linux64 build. I will commit it after the SVN is ok.
It should be fixed now in rev 529560.
> On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>> Let's commit
I've tested HARMONY-3630. Profile-guided devirtualizations gives ~2%
improvement on SPECjbb2005 which is impressive! We should disable unguard
config before integrating the patch - otherwise we'll devirtualize virtual
calls twice. Also we should get rid of code duplication in ValueProfiler.cpp.
I'
Ruth Cao wrote:
> You are right, Vladimir.
>
> It is just because the 'port' variable is set to 8080 and on some
> machines this port has already been occupied. The test case will pass
> if we use Support_PortManager.getNextPort() on my side.
Please don't use the PortManager, just open port 0 an
On 4/17/07, Alexander Kleymenov wrote:
Stepan,
> > > What the reason for calling classlib's build in this way? Why we have
> > > to run 'ant.bat' (or 'ant.sh' for Linux) via ?
> >
> > It's workaround for Ant's OutOfMemory problem arising after doing the same
> > by target. The -rebuild of class
Vladimir Ivanov wrote:
Build of Harmony on Linux x86_64 is broken today (log is below). Seems
the guilty commit is:
Author: ndbeyer
Date: Mon Apr 16 22:08:00 2007
New Revision: 529487
I added assembly implementations for x86_64 (using SSE2) and ia64 (using
mf instruction). Committed in revisio
On 4/17/07, Ruth Cao <[EMAIL PROTECTED]> wrote:
You are right, Vladimir.
It is just because the 'port' variable is set to 8080 and on some
machines this port has already been occupied. The test case will pass
if we use Support_PortManager.getNextPort() on my side.
btw, does anyone know the
Xiao-Feng Li wrote:
There is a break in Linux64 build. I will commit it after the SVN is ok.
It should be fixed now in rev 529560.
On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Let's commit it.
On 4/17/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> On 4/14/07, Xiao-Feng Li <[EMAIL
There is a break in Linux64 build. I will commit it after the SVN is ok.
Thanks,
xiaofeng
On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Let's commit it.
On 4/17/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> On 4/14/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> > On 4/13/07, Mikhail F
Done at r529549.
I've create the branch and added 'java6' property to federated build.
So to build Harmony using federated build with Java 6 classlibrary it
should be set (for example, ant -Djava6=true)
Thanks,
Stepan.
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
+1 from Stepan,Tony,
Alexey,
I've updated the pages with bugs/issues statistics.
There are many issues still present in the 'bad summary' lists.
Thanks,
Aleksei.
>From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, April 17, 2007 4:19 PM
>
>Guys,
>
>I've added module specification to the issues mentione
Yes, on my box this port occupied by CC/CI.
Thanks, Vladimir
On 4/17/07, Ruth Cao <[EMAIL PROTECTED]> wrote:
You are right, Vladimir.
It is just because the 'port' variable is set to 8080 and on some
machines this port has already been occupied. The test case will pass
if we use Support_PortMa
You are right, Vladimir.
It is just because the 'port' variable is set to 8080 and on some
machines this port has already been occupied. The test case will pass
if we use Support_PortManager.getNextPort() on my side.
May some committer pls revert this? And I'll provide a new patch for
this
Stepan,
> > What the reason for calling classlib's build in this way? Why we have
> > to run 'ant.bat' (or 'ant.sh' for Linux) via ?
>
> It's workaround for Ant's OutOfMemory problem arising after doing the same
> by target. The -rebuild of classlib project causes big memory
> leaks somewhere i
On 4/17/07, Alexander Kleymenov wrote:
Hi Stepan,
Thanks for comments and your work with it!
Please, look at my responses bellow.
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> Hi Alexander,
>
> I've reviewed almost all the code. And I have some comments and questions:
>
> 1) Is it pos
Guys,
I've added module specification to the issues mentioned on the wiki
page: http://wiki.apache.org/harmony/Unresolved_Bugs_History
It would be nice if the owner of the page will regenerate its content.
Thanks in advance.
SY, Alexey
I think it depends on environment. On my box this test failed on IBMVM too.
Thanks, Vladimir
On 4/17/07, Ruth Cao <[EMAIL PROTECTED]> wrote:
Vladimir,
I provide this patch and it passes on my side (IBMVME/Windows & Linux).
I'll try the test on DRLVM soon, thanks.
Vladimir Ivanov wrote:
> New t
Vladimir,
I provide this patch and it passes on my side (IBMVME/Windows & Linux).
I'll try the test on DRLVM soon, thanks.
Vladimir Ivanov wrote:
New test added to the tests.api.java.net.SocketTest failed on my
Windows XP sp2 with execution log:
[junit] Running tests.api.java.net.SocketTe
New test added to the tests.api.java.net.SocketTest failed on my
Windows XP sp2 with execution log:
[junit] Running tests.api.java.net.SocketTest
[junit] java.net.SocketTimeoutException: The operation timed out
[junit] at
org.apache.harmony.luni.net.PlainSocketImpl.accept(PlainSocket
Does the built DRLVM ever works - e.g. HWA passes?
BTW, there is a regression test which can be run easy:
build.bat -Dtest.case=H3591 reg.test
2007/4/17, LvJimmy，Jing <[EMAIL PROTECTED]>:
Hi,
I've already prepared for my patch, I'm running regression test. I
meet some building problem of DRLV
Some advices:
1) update and rebuild classlib first (ant clean/svn update/ant
fetch-depends/ant)
2) run 'build clean' before building updated drlvm to be sure that there are
no object files left for removed sources.
On 4/17/07, Maksim Ananjev <[EMAIL PROTECTED]> wrote:
I am now fully convinced t
I am now fully convinced that there is a problem on my side. I tried
applying the patch as you had described - got segmentation fault on my
test execution. I suppose, that's because i have rather old build.
I tried to make "svn up" - but got compilation errors in the porting layer.
Maybe i need
Hi Stepan,
Thanks for comments and your work with it!
Please, look at my responses bellow.
On 4/17/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
Hi Alexander,
I've reviewed almost all the code. And I have some comments and questions:
1) Is it possible to add modules 'drlvm-test' and 'classlib
On 4/17/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
On 4/16/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> On 4/17/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > On 4/16/07, Spark Shen <[EMAIL PROTECTED]> wrote:
> > > +1.
> > >
> > > But I have a question. Which tag should be use to check out c
75 matches
Mail list logo
