Re: [DRLVM][JIT] write barrier broken by new jit opts?

On 1/7/07, Robin Garner <[EMAIL PROTECTED]> wrote: If the memory manager requires that the compiler invoke the write barrier for each pointer store, then it should honour the contract and do so. If JIT people agree, I am happy to see that. :-) Thanks, xiaofeng If you want to provide an obje

Re: [DRLVM][JIT] write barrier broken by new jit opts?

I disagree. Partly from the point of view of eventual support for MMTk, but also on more general grounds, in terms of support for future GC algorithms. If the memory manager requires that the compiler invoke the write barrier for each pointer store, then it should honour the contract and do so.

[DRLVM][JIT] write barrier broken by new jit opts?

Hi, I found write barrier in DRLVM can't catch all reference fields updates, and the problem is identified to be caused by new jit opts that do not observe the write barrier invariant for fields updates. For example, JIT may generate code to copy consecutive fields of an object without invoking wr

Unsubscribe

Unsubscribe

[drlvm] stress.Mix problems -- should it prevent committing patches?

I have been hesitant to commit patches given that stress.Mix fails on my 2-cpu rhel4 box. It looks like MegaSpawn.java (see Harmony-2803) identifies stress.Mix failure to be a problem with handling an exceedingly high rate of thread creation. stress.Mix has been causing "build test" failures sin

Re: [drlvm] finalizer design questions

On 1/2/07, Robin Garner <[EMAIL PROTECTED]> wrote: - Finalizers should be run with high priority because memory (possibly large structures) can't be freed until they have completed. I agree, In described case it should work with high priority. In current finalization scheme if garbage col

Re: [drlvm] finalizer design questions

On 1/2/07, Weldon Washburn <[EMAIL PROTECTED]> wrote: Yes with one reservation. I'd like to see the existing DRLVM mechanisms hard coded for just one finalizer thread for now. And that no finalizer code be committed that suspends/resumes java app threads. The intention is to reduce debug con

[classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )

Hi all, I've just finished with moving pack200 code to the new module (r493560). The name of the new module is "pack200" (no surprises), new package names start with "org.apache.harmony.pack200". The build can be customized for using arbitrary build source and build target (Alex has asked for it)

Build failed on WinXP

I'm seeing the following error when trying to build classlib: build-native: [exec] C:\HarmonyTrunk\working_classlib\deploy\build\make\defines.mak(26) : fatal error U1052: file 'win32.mak' not found [exec] Stop. BUILD FAILED The file mentioned is really absent. Any ideas what may I be d

[jira] Could someone please close HARMONY-1686 ?

Could someone please close old HARMONY-1686 ? Paulex? Thank you! Vasily

[DRLVM][GCv5] (H-2945) scalable parallel generational or non-generational collection

Hi, I've submitted a patch for GCv5 at URL: https://issues.apache.org/jira/browse/HARMONY-2945, which achieves good parallelization scalability in real SMP machines. It can works in generational or nongenerational mode. I have tested it on a Intel Tulsa platform which has four Pentium-D dual-core

Re: [vote] HARMONY-1407 : contribution of code for java.lang.management

+1 2007/1/5, Geir Magnusson Jr. <[EMAIL PROTECTED]>: We now have all requisite paperwork (CCLA, BCC, ACQs) in place for http://issues.apache.org/jira/browse/HARMONY-1407, so lets vote to accept : [ ] +1 Accept this contribution [ ] -1 Reject because... As usual, 3 days unless someone complains