Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?

Weldon Washburn wrote: Robin, Good points. Given that Object.hashCode() implementation sortof, kindof depends on a copying mature space, does it make sense for the GC to own the Object.hashCode() implementation? That way, we eliminate the vm-wide debate about giving object hash one or two or

Re: [classlib][logging] A non bug difference from RI?

Stepan Mishura wrote: Andrew, thanks for the test. But working test doesn't mean that there is no bug :-) AFAIK in our case an operation on file (if file is not exist - create file) should be atomic. And it looks like Harmony implementation doesn't do in atomic way.(see

[admin] Automated Monthly Reminder

This is a monthly automated mailing to the Apache Harmony dev list. The Apache Harmony project welcomes the participation and input of anyone interested in open source Java SE, the goal of our project. For more information about the Apache Harmony project, please see the project website.

Re: [classlib][luni] signalis interruptus in hysock

This is a VMI extension introduced by HARMONY-635, and this modification was discussed before in a very long thread[1] But it's weird that, at revision r431077, it is removed, anyone knows why:-(. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL

Re: [general] jira issues tracking

It's a good idea to add Patch available status +1 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][luni] signalis interruptus in hysock

Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1 to my patch. The patch

Re: [DRLVM][VM] set_hash_bits() in vmcore/src/thread/mon_enter_exit.cpp -- is it a bug or a feature?

Guys, The problem looks much broader then just a hash code placing. There is no common place that describe object header format and object header sharing protocol. There are 3 components that use object header together. VMcore -- store VT pointer and hashcode ThreadManager -- update lockword GC

Re: [drlvm] DRLVM, jre/bin/default and launcher

Hi Geir, I'm very enthusiastic about making DRLVM to work with the launcher. It requires implementation of the Invocation API to a certain extent. For example it's enougth to have only partial support for DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is necessary as well. So if

Re: [drlvm]A subject to profiling instrumenting

Hi Zou, At last I read the papers you sent and I hope now I can answer to your questions more precisely. I think it's a good idea to start with JET just to test the base algorithms implementation: SEQUITIR, GC support and so on. Once we have framework working we can easily port everything to OPT

Re: [classlib][luni] signalis interruptus in hysock

2006/8/31, Geir Magnusson Jr. [EMAIL PROTECTED]: Anton Luht wrote: Hello, Behaviour of select() with SA_RESTART can vary by platform - see [1] ---quote begins [EINTR] The select() function was interrupted before any of the selected events occurred and before the timeout interval

Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?

Robin Garner wrote: Weldon Washburn wrote: Robin, Good points. Given that Object.hashCode() implementation sortof, kindof depends on a copying mature space, does it make sense for the GC to own the Object.hashCode() implementation? That way, we eliminate the vm-wide debate about giving

Re: [classlib][luni] signalis interruptus in hysock

Artem Aliev wrote: Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing including this select() problem. +1

Re: [drlvm] DRLVM, jre/bin/default and launcher

Ok, but can we wack off the biggest problem first, namely that DRLVM doesn't work when it's artifacts (dll's, so's) are in a subdirectory of jre/bin? TO me, that's our biggest problem. Subtle cleanup issues are also important, but not as much at this point. geir Evgueni Brevnov wrote: Hi

Re: [classlib][luni] signalis interruptus in hysock

Geir Magnusson Jr. wrote: Artem Aliev wrote: Hello, guys. Do not forgot about portability Hysock lib is a porting layer and it should work the same way on all platforms. The windows does not support signals at all So the porting layer should hide all OS depended signal processing

Re: [build-test-infra] Build Test Infrastructure

Hello, I've deployed the test infrastructure app to http://harmonytest.org . It is mostly for demo purpose - the disk space is not too large - I hope it will move somewhere else after evaluation. Please try to upload your test results there and send comments/wishes about the app - I'll try to

Re: [classlib][luni] signalis interruptus in hysock

Gier, That's crazy. This isn't an implementation dependent feature - it's a side effect. The standard says: It is implementation-dependent behaviour, not a side effect :) http://www.opengroup.org/onlinepubs/007908799/xsh/select.html ---quote begins [EINTR] The select() function was

Re: [classlib][luni] signalis interruptus in hysock

Artem Aliev wrote: Gier, That's crazy. This isn't an implementation dependent feature - it's a side effect. The standard says: It is implementation-dependent behaviour, not a side effect :) http://www.opengroup.org/onlinepubs/007908799/xsh/select.html ---quote begins [EINTR] The

Re: [classlib][luni] signalis interruptus in hysock

Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the

[classlib][luni][io] Someone break something in java.io.ObjectInputStream or -ish?

I was playing with tomcat to test this select() stuff we've been talking about, and on a fresh build of classlib and drlvm : Sep 1, 2006 1:37:50 PM SEVERE org.apache.catalina.session.StandardManager.start: Exception loading sessions from persistent storage Throwable occurred:

Re: [DRLVM][VM] set_hash_bits() in vmcore/src/thread/mon_enter_exit.cpp -- is it a bug or a feature?

On 9/1/06, Artem Aliev [EMAIL PROTECTED] wrote: Guys, The problem looks much broader then just a hash code placing. There is no common place that describe object header format and object header sharing protocol. Yes, I noticed the same thing. This was the original motivation for starting

[DRLVM][GC] MMTk port now ready for write barrier integration

All, A late night IM debug session with Steve Blackburn got the DRLVM/MMTk port to the point where it makes sense to try write barrier integration. All the mods I have been working on plus simple gc regression tests have been committed to drlvm\trunk\vm\mmtk. DRLVM/MMTk now runs the following

Re: [classlib][luni][io] Someone break something in java.io.ObjectInputStream or -ish?

Never mind - there was a problem earlier in execution - DRLVM's Class didn't have isEnum() I assume what followed was because of that. I fixed it, and problem went away. Back to select()... geirb Geir Magnusson Jr. wrote: I was playing with tomcat to test this select() stuff we've been