I'm trying to complete the interruptible channel feature of NIO module,
but there is a question.
The spec for InterruptibleChannel says:
A channel that implements this interface is asynchronously closeable:
If a thread is blocked in an I/O operation on an interruptible channel
then another
Paulex Yang wrote:
snip
I think the kernel class means the classes which heavily depends on VM
implementation, but the buffer is another story, it is the JNI actually
depends on Classlib implementation, so instead of put buffers into
kernel, I prefer to pull the three JNI methods out of VM
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Hi all,
As you have probably noticed, I recently raised HARMONY-596
(which Mark has already kindly applied) to make .lib and .a files generate
straight into the deploy/lib directory.
I think that now we are in a position to finally modularise
On 6/14/06, Richard Liang wrote:
Tim Ellison wrote:
Richard Liang wrote:
I launch Eclipse 3.2 RC7 with options -Xms256M -Xmx256M -vm
D:\jdk\RI\jdk1.5.0_06\bin\javaw -Dpde.allowCycles=true
-Dpde.jreProfile=none,
But LUNI still cannot add luni-kernel-stubs.jar to its Plug-in
Stepan Mishura wrote:
On 6/14/06, Richard Liang wrote:
Tim Ellison wrote:
Richard Liang wrote:
I launch Eclipse 3.2 RC7 with options -Xms256M -Xmx256M -vm
D:\jdk\RI\jdk1.5.0_06\bin\javaw -Dpde.allowCycles=true
-Dpde.jreProfile=none,
But LUNI still cannot add luni-kernel-stubs.jar to
Good day,
I'm trying to build VM from SVN using build.sh and have noticed that
build.sh update fetched something that looks Windows-only:
build
root/pre-copied/common/CLASSLIB/depends/oss/win.ia32/icu4c-3.4-harmony.zip
, five dlls in
build root/pre-copied/common/CLASSLIB/depends/libs/win.ia32/
Alex Blewitt wrote:
snip
I've created Harmony 599
(http://issues.apache.org/jira/browse/HARMONY-599) with a zip of what
I've done so far. I don't believe that it has compile errors, and the
tests run OK -- it's just if I depend on a method/class that's not yet
available in the classpath
On 6/14/06, Richard Liang wrote:
Stepan Mishura wrote:
On 6/14/06, Richard Liang wrote:
Tim Ellison wrote:
Richard Liang wrote:
I launch Eclipse 3.2 RC7 with options -Xms256M -Xmx256M -vm
D:\jdk\RI\jdk1.5.0_06\bin\javaw -Dpde.allowCycles=true
-Dpde.jreProfile=none,
But LUNI
Geir is currently refactoring the DRLVM build, so things will be
changing; however, at the moment there is no opportunity for separate
checkout of the code in our SVN for windows and linux builds (which is
the 'problem' you are seeing here).
Regards,
Tim
Anton Luht wrote:
Good day,
I'm
Paulex Yang wrote:
snip
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
1. Add this method to kernel class Thread (in VMI): private void
setInterruptAction(Runnable action);
...and, reading on, you'll need to add a new
I have a couple of questions about location of makefiles and makefile
includes
1) Currently the makefiles for the modules are stored underneath the
platform
and component they relate to. For example, the luni makefiles are situated
at native-src/linux.IA32/luni/makefile and
Thanks for the link Richard.
Looks like we will need to put support for Enum right into the
ObjectStreams. I'm therefore not convinced that your patch is the right
thing to do. Anyone else care to comment?
Regards,
Tim
Richard Liang wrote:
Tim Ellison wrote:
Richard Liang (JIRA) wrote:
I think that unspecified protected method readResolve() in Enum is
against the spec. So, ObjectInputStream should be fixed.
Best regards,
Boris Kuznetsov
Intel Middleware Products Division
On 6/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Thanks for the link Richard.
Looks like we will need
Paulex Yang wrote:
I'm trying to complete the interruptible channel feature of NIO module,
but there is a question.
The spec for InterruptibleChannel says:
A channel that implements this interface is asynchronously closeable:
If a thread is blocked in an I/O operation on an
Modularize on!
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Hi all,
As you have probably noticed, I recently raised HARMONY-596
(which Mark has already kindly applied) to make .lib and .a files
generate
straight into the deploy/lib directory.
I think that now we
Yah - for now, just ignore it...
I'd suggest that you offer a patch, but if you do so, be forwarned that
this is all in flux - I don't think there's a clear plan yet - so it may
go unused.
geir
Tim Ellison wrote:
Geir is currently refactoring the DRLVM build, so things will be
changing;
Oliver Deakin wrote:
I have a couple of questions about location of makefiles and makefile
includes
1) Currently the makefiles for the modules are stored underneath the
platform
and component they relate to. For example, the luni makefiles are situated
at
Thanks for the extra time to consider the code, and apologies for
dragging out the vote. This really is a great leap forward for Harmony.
I'm +1 to accept the code.
Regards,
Tim
Geir Magnusson Jr wrote:
I have received the ACQs and the BCC for Harmony-528, so I can assert
that the critical
Geir Magnusson Jr wrote:
Paulex Yang wrote:
I'm trying to complete the interruptible channel feature of NIO module,
but there is a question.
The spec for InterruptibleChannel says:
A channel that implements this interface is asynchronously closeable:
If a thread is blocked in an I/O
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
I have a couple of questions about location of makefiles and makefile
includes
1) Currently the makefiles for the modules are stored underneath the
platform
and component they relate to. For example, the luni makefiles are situated
at
For the modules that have both impl and api tests I'm going to add possibility
to skip impl tests, like this:
ant -f build-test.xml -Dtest.noimpl=true -Dtest.jre.home=...
If no objection I'll integrate changes so that the work on splitting the tests
could be continued. (BTW, volunteers are
Hi Alexei
2006/6/14, Alexei Zakharov [EMAIL PROTECTED]:
Hello to everyone,
I am currently investigating tests for java.beans module. As far as I
Cool!
understand there were two separate contributions of java.beans tests
from two different parties. And these contributions were merged into
Alexei Zakharov wrote:
Hello to everyone,
I am currently investigating tests for java.beans module.
Great.
As far as I
understand there were two separate contributions of java.beans tests
from two different parties. And these contributions were merged into
the single combined test suite
On 14 June 2006 at 7:04, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
yes.
And/or add it to the upcoming donation of the [testing] infrastructure
to make it part of the CI runs.
Are you talking about me? It's just an ant file and a few script so I
hope you aren't expecting too much.
geir
Paulex Yang wrote:
But after all, the implementation details(class name, fields/methods,
etc) are different, so the idea is to provide the three JNI methods'
implementation in NIO module, and add them into VMI, so that VM vendor
can choose to add them into the JNI function table. I think this
p.s. the reference to [1] is
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Tim Ellison wrote:
Alexei Zakharov wrote:
Hello to everyone,
I am currently investigating tests for java.beans module.
Great.
As far as I
understand there were two separate
Paulex Yang wrote:
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
I don't think the VM or java.lang.Thread needs to be involved.
First of all, the code performing the blocking operation knows
what kind of operation it is,
On 14 June 2006 at 7:24, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Oliver Deakin wrote:
I have a couple of questions about location of makefiles and makefile
includes
1) Currently the makefiles for the modules are stored underneath the
platform
and component they relate to. For
2006/6/14, Mark Hindess [EMAIL PROTECTED]:
On 14 June 2006 at 7:24, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Oliver Deakin wrote:
I have a couple of questions about location of makefiles and makefile
includes
1) Currently the makefiles for the modules are stored underneath the
Ming,
The above is just a consideration for infrastructure. I have already
implemented the write barrier code in jet for some GC developed in C.
It has already been tested and attached file is the patch.
Cool ! Thanks for the patch !
I'm not too familiar with GC stuff, but seems you are
Alexei Zakharov wrote:
Hello to everyone,
I am currently investigating tests for java.beans module. As far as I
understand there were two separate contributions of java.beans tests
from two different parties. And these contributions were merged into
the single combined test suite we have
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Paulex Yang wrote:
I'm trying to complete the interruptible channel feature of NIO module,
but there is a question.
The spec for InterruptibleChannel says:
A channel that implements this interface is asynchronously closeable:
If a thread is
I assume you'll document this somewhere?
Mikhail Loenko wrote:
For the modules that have both impl and api tests I'm going to add
possibility
to skip impl tests, like this:
ant -f build-test.xml -Dtest.noimpl=true -Dtest.jre.home=...
If no objection I'll integrate changes so that the work
Mark Hindess wrote:
On 14 June 2006 at 7:04, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
yes.
And/or add it to the upcoming donation of the [testing] infrastructure
to make it part of the CI runs.
Are you talking about me? It's just an ant file and a few script so I
hope you aren't
Sure. Can you suggest a proper place?
2006/6/14, Geir Magnusson Jr [EMAIL PROTECTED]:
I assume you'll document this somewhere?
Mikhail Loenko wrote:
For the modules that have both impl and api tests I'm going to add
possibility
to skip impl tests, like this:
ant -f build-test.xml
Mikhail, Tim,
I suggest that you raise a few examples here.
The first example that comes to my mind is the RI's implementation of
PersistenceDelegate for java.lang.String class. (Persistence delegate
is a class that manages persistence details of his target class and is
used by
2006/6/14, Mark Hindess [EMAIL PROTECTED]:
On 14 June 2006 at 7:24, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Oliver Deakin wrote:
I have a couple of questions about location of makefiles and makefile
includes
1) Currently the makefiles for the modules are stored underneath the
How about on the website where you are already talking about how tests
are organized? Or maybe we need a new developers page? or a testing
page to start The Grand Testing Subset of the Apache Harmony Project?
Mikhail Loenko wrote:
Sure. Can you suggest a proper place?
2006/6/14, Geir
BTW, all questionable methods of PersistenceDelegate interface are
protected rather than public. Do we need to test it at all?
2006/6/14, Alexei Zakharov [EMAIL PROTECTED]:
Mikhail, Tim,
I suggest that you raise a few examples here.
The first example that comes to my mind is the RI's
Alexei Zakharov wrote:
BTW, all questionable methods of PersistenceDelegate interface are
protected rather than public. Do we need to test it at all?
Hello Alexei,
IMHO, we need to test the protected methods, which are also part of API.
2006/6/14, Alexei Zakharov [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Given that you are blocked, why is it in an unknown state?
The problem is that you typically don't know whether the thread is
actually blocked or not. So if it is really blocked then, yes,
interrupting it may leave the channel safe for future operations, but if
it were
This font is getting out of hand...
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 11:12 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [Fwd: [classlib][NIO|VMI]Interruptible channel
implementation - how to interact with
Alex,
It looks like the JIT needs to support write barriers written in both
C as well as Java. Its probably best to think of the C write barrier
as a conventional vm helper call. For a garbage collector written in
Java like MMTk, the write barrier is actually Java code. Injecting a
vm helper
Mark Hindess wrote:
snip
On 14 June 2006 at 7:24, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Oliver Deakin wrote:
2) The makefiles for each native component include two files
(defines.mak and rules.mak on windows and makefile.include
and rules.mk on linux) that are generic across all
Oliver Deakin wrote:
snip
but now that I look at it
I see that the
depends/files dir contains the Harmony properties files, so maybe I'm
wrong.
Those are launcher-specific, so don't get too attached to them, I'll
move them out to the tools/launcher directory where they better belong.
the patch that makes the DRLVM work with the latest Harmony class libraries
is published:
http://issues.apache.org/jira/browse/HARMONY-601
It works fine with the current Harmony sources and may be applied and
commited right away.
--
Denis Sharypov,
Intel Middleware Products Division
On 6/9/06,
On 14 June 2006 at 20:59, Denis Sharypov [EMAIL PROTECTED] wrote:
the patch that makes the DRLVM work with the latest Harmony class libraries
is published:
http://issues.apache.org/jira/browse/HARMONY-601
It works fine with the current Harmony sources and may be applied and
commited right
Please don't do anything with this.
I'll patch classlib when I'm comfortable with what I'm doing.
geir
Mark Hindess wrote:
On 14 June 2006 at 20:59, Denis Sharypov [EMAIL PROTECTED] wrote:
the patch that makes the DRLVM work with the latest Harmony class libraries
is published:
Thanks, but I'm still in the middle. I'll give a look, but I think I'm
ok. (I just had a high interrupt rate this weekend, so my context
switches and family stuff slowed me down...)
I wish that whoever did this had chatted a bit on the list so we could
talk about things...
Also, is there a way
Archie Cobbs wrote:
Paulex Yang wrote:
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
I don't think the VM or java.lang.Thread needs to be involved.
First of all, the code performing the blocking operation knows
what kind
Hi, Archie
I have a question, please see my comment inline.
Thanks!
On 6/14/06, Archie Cobbs [EMAIL PROTECTED] wrote:
Paulex Yang wrote:
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
I don't think the VM or
On 6/14/06, Magnusson, Geir [EMAIL PROTECTED] wrote:
This font is getting out of hand...
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 11:12 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [Fwd: [classlib][NIO|VMI]Interruptible
Ok, so I've gotten quite a bit done (I think) and stuff builds using the
classlib as it is in /enhanced/classlib/trunk using it's own build
artifacts.
So my tests are failing.
java/lang/UnsatisfiedLinkError : Failed loading library
Andrew Zhang wrote:
Geir :
Given that NIO is an advanced API, why would the NIO EG let the channel
user simply decide? If you were interrupted while blocked on the
channel, you must close. If not, you can use it...
Most of users may prefer to decide the operation by themselves, but
Tim Ellison wrote:
Paulex Yang wrote:
snip
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
1. Add this method to kernel class Thread (in VMI): private void
setInterruptAction(Runnable action);
...and, reading on,
Weldon Washburn wrote:
oops, I forgot to cc:
-- Forwarded message --
From: Weldon Washburn [EMAIL PROTECTED]
Date: May 24, 2006 11:23 AM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: [EMAIL PROTECTED]
On 5/24/06, Daniel Feinberg [EMAIL PROTECTED] wrote:
that is
I figured that one out... it was in properties.cpp
Let me ask - why are DLLs specified in cpp files like this?
geir
Geir Magnusson Jr wrote:
Ok, so I've gotten quite a bit done (I think) and stuff builds using the
classlib as it is in /enhanced/classlib/trunk using it's own build
test - please ignore
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jimmy, Jing Lv wrote:
Archie Cobbs wrote:
Paulex Yang wrote:
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
I don't think the VM or java.lang.Thread needs to be involved.
First of all, the code performing the blocking
It's working now, at least on windows. I'll round-trip it tomorrow
through SVN to check it on linux.
You can just set a property to point to a classlib/trunk/deploy. Note
that you have to have built that classlib already, so this can be as
simple as an HDK.
I'll review tomorrow after sleeping
I've update web (viv.byethost15.com) - published fresh coverage information.
No awt package in the beans coverage table anymore.
Also I've update the jira-564 by extended script (that include security,
auth, crypto, lang and rmi packages).
Now I have 2 questions/ issues to discuss:
1)
Archie Cobbs wrote:
Paulex Yang wrote:
But after all, the implementation details(class name, fields/methods,
etc) are different, so the idea is to provide the three JNI methods'
implementation in NIO module, and add them into VMI, so that VM
vendor can choose to add them into the JNI function
62 matches
Mail list logo
