appointed in 2224 - I assumed that it was an external "exclude
> list" :)
>
> But I guess that works. How do we exclude for more than 1 platform?
It's impossible, as I understand.
Pavel Afremov
geir
>
>
> Rana Dasgupta wrote:
> > Hi,
> > Sadl
202
> >
> >
> >
> >
> > In HARMONY-2224 <https://issues.apache.org/jira/browse/HARMONY-2224> I
> > excluded failed tests from acceptance test set:
> >
> > StackTest & exception.FinalizerStackTest on EM64T
> >
> > gc.LOS on Windows.
>
Sadly I am sans a 64 bit Linux box at least temporarily. Sounds hard to
believe, I know...
On 11/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> Not surprising :-) The last big stack relatad checkin in 2018. Its
comment
> notes say that Gregory actu
Thanks for the clarifications Alex.
On 11/16/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
>>
>> So does this mean one specific convention, fastcall, for C helpers and
a
>> second custom DRLVM convention for managed code?
>Right.
>I'm
Not surprising :-) The last big stack relatad checkin in 2018. Its comment
notes say that Gregory actually saw the failure of StackTest and the new
FinalizeStackTest...
On 11/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
First test that fails is the most cherished and beloved StackTest,
Hi Alex,
This is good, thanks. Please see below...
On 11/15/06, Alex Astapchuk <[EMAIL PROTECTED] > wrote:
>Hi all,
>Among other things listed on the JIT Dev tasks, there is a need for
>calling convention (CC) fix-up for IA-32 [1].
>Current problems are:
>1. The calling convention(s) use
go browse
reports/jitrino.jet/html/index.html, there are no errors!
On 11/15/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit
out
> to the console, but show up in the test run results as pass
On 11/13/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
>Hello
>I think that Stack test should print pass if no stack overflow error is
>happened.
>Test should check processing of this error but not existing of it.
I think that this makes sense. StackTest should be intended to detect
corre
I think that a problem with the junit tests is that some failures spit out
to the console, but show up in the test run results as passed. I find this
very confusing. So unless you are watching all the time, you can miss them.
On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
Guys,
This is
On 11/14/06, Robin Garner <[EMAIL PROTECTED]> wrote:
>Whether this helps performance depends on the cache policy of the
>multiprocessor. I'm not sufficiently versed in cache architectures to
>say, but I would expect that machines with sufficiently weak memory
>models will make this cheap, thos
cores info for
multicore systems and the NUMA api's on Linux are a different bunch
altogether.
Thanks,
Rana
On 11/1/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Very informative! Thanks, Rana.
-xiaofeng
On 11/2/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>On Windows,
I can understand that the contributor may not have access to multiple
platforms, but surely he can test using both debug and release builds :-)
What do we gain by asking the contributor to test less?
Rana
On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
+1 for debug testing before submi
Identifying an end to end alogirithm is of course necessary, and the
discussions on the other thread are great. But what were we voting on here?
My understanding was that we were voting on the approach of using:
1. vtable objects( Aleksey )
2. per heap space/generation boolean marker on the class
On 11/9/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>Actually it is more than that. In debug mode TRACE statements are
>compiled and therefore produce executable code. There may also be some
>bugs in compiler generating code in different modes (although this
>usually happens for release).
Great. Thanks Weldon. Does this mean that it is to be verified on Windows?
On 11/8/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
1558 has been committed. It took two commits since I forgot to "svn add"
4
files. All in all, one hundred and twenty one files were committed.
Following the commi
e
violation access signals happen one page before protected page on the
stack.
It's it.
I ran all tests, and everything was OK. But strange misprint was fount in
the new test.
So I attach new fixed patch.
Pavel Afremov.
On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
>
Though I tried several times, I could not repro 2070 or Alexey's specific
problems. The test attached to 2018 repros, and that I think is enough.
Pavel,
1. The patch looks good, but I could not apply and try it since my Linux
box is down.
2. Did you run all tests ( smoke, cuint, kernel, and c
It's worth a lot, since you have implemented this in SableVM yourself.
Thanks.
On 11/7/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
For what it's worth, I'll add my humble +1.
Etienne
Xiao-Feng Li wrote:
> Agreed, so plus me.
>
> Thanks,
> xiaofeng
>
Again, this makes sense. Functional completenes is needed, but over a
period, based on when we want to release. Identifying a couple of milestones
before 1.0 for which we choose features to complete, and performance
objectives can help. For each, we can add a bug-fix/stability period.
Branching th
+1
This makes more sense than putting a sudden unannounced stop to new
features. Possibly Weldon means "on a case by case basis after risk
assessment". However, announced stability periods at the end of milestones
is a good practice. For example, since we have been focussing on development
for a
On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
All,
It looks like the debate on class unloading has concluded.
Let's vote on implementing Robin's proposal.
+1
Weldon
PS -- When class unloading gets implemented and committed is a seperate
issue.
+1 I think it's the best proposa
Yes, I use a gcc version 4.0.2 on RHEL. I have no problems building +
running it now
> > I can confirm that gcc 4.1.1 compiled this patch without any problems.
> > As I've written, patchlevel shouldn't matter here, and if gcc 4.1.0
> > worked, 4.1.1 should work as well (with very rare exception
On 11/5/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>On 11/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> first, can we also use this test for gcv4.1?
>>
Yes. The test is a Java test. The reason I placed it in gc_gen is that it is
intended to stress allocation fastpath and corr
Jet is a startup fast compilation path, not a seperate pluggable jit. So,
while modularity and seperation are important requirements, they may not be
needed here.
Also, Mikhail and Alex are the best people to decide on this.They are
literally the two people who know this code best :-)
help me to understand the current status of the problem?
With best regards,
Alexei Fedotov,
Intel Java & XML Engineering
>-----Original Message-
>From: Rana Dasgupta [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 18, 2006 4:27 AM
>To: harmony-dev@incubator.apache.org
>Sub
Since we have accepted GCV4.1 as the default and GCV5 as the development GC
based on several list discussions, I think that we may be OK with announcing
that GCv4 is deprecated, and maybe taken out of the active tree by end of
2006?
Patches that are still coming in that only work with GCV4, proba
Hi,
I am trying to a clean build on RHEL ( svn latest trunk ) and getting
tons of build errors from the 1635 heap iteration related changes. The 1635
JIRA notes say that the patch has been committed and applied cleanly, so I
am not sure what is happening. Could you please check?
Thanks,
Rana
O
Yes, I actually think that setting an announced date for taking away
deprecated features is a good idea Mikhail. IMHO, dead code also creates
some risk.
On 11/3/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 11/3/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> From that argument, I
o see RI behaviour on Linux. Anyway, I will recheck.
Thanks for closing the other two.
On 11/3/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> Hi,
> I did not want to start a new thread for this. Could someone please
close
> JIRA issues 1109, 1662, 1
Hi,
I did not want to start a new thread for this. Could someone please close
JIRA issues 1109, 1662, 1830? These have been fixed by recent changes in the
stack and exception handling. In any case, none of them repro. Comments on
teh JIRA.
Thanks,
Rana
On 10/25/06, Volynets, Vera <[EMAIL PROTE
On 11/2/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>Robin, thanks for all the clarifications. Now it seems clear to me >and
>I am convinced by this proposal. :-)
Yes, this proposal is the simplest and has the least perf impact. Thanks
Robin.
Right, it is in the default code path. So it is regularly exercised, tested,
fixed. v5 is the one in development. If gcv4 is neither being fixed, nor
developed why keep it? Sorry for the double negatives :-)
On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I don't grok what you mean
If the code is not being exercised by day to day tests and maintained, or if
we are not developing it, we can drop it I think. GCV4.1 is in the first
category, and GCV5 the second. GCV4 doesn't fit either. Dropping it doesn't
stop one from pulling it out of an old svn revision for personal use.
On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>Hi, everyone.
>I've splitted Harmony-2000 (see details:
>http://issues.apache.org/jira/browse/HARMONY-2000) patch >with automatic
>class unloading implementation into 2 independent parts:
>1. cleaning native resources (native_sources_cle
not a big
deal.
On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> No problem with them being both on the Wiki and the JIRA, I think.
Other than getting out of sync it just makes sense to use the
"issue tracking system" for... "issue t
feng
On 11/2/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>On Windows, there is a bunch of bugs.
>
>- On W2003 SP1, Vista, XP-64 GetLogicalProcessorInformation() is the
>recommended api. It returns # of cores on AMD and # of logical procs
on
>Intel.
>
No problem with them being both on the Wiki and the JIRA, I think.
On 02 Nov 2006 17:57:29 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x215 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Alexey Varlamov wrote:
> > 2006/11/2, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >> Put them in
Robin,
The basic difference of this with Etienne's method is that the flag is
on the vtable, instead of the CL instance. Do I understand correctly ? The
GC perf impact is therefore reduced because you need to lookup
object->vtable instead of object->class->CLinstancewhen tracing the heap.
The s
On Windows, there is a bunch of bugs.
- On W2003 SP1, Vista, XP-64 GetLogicalProcessorInformation() is the
recommended api. It returns # of cores on AMD and # of logical procs on
Intel.
- GetSystemInfo() is on XP-32 and Windows Server. It does not work in
wow mode. I think GetNativeSy
On 10/31/06, Etienne Gagnon <[EMAIL PROTECTED] > wrote:
>Yet:
>1- You do need pinning, so you rule out some of the simplest GCs (e.g.
>simple, non-generational copying without pinning.) [Apparently, for
>some very large heaps, simple copying a can be quite difficult to beat,
>efficiency wise,
I created an MMTk page off the DRLVM core VM development page and put in
Weldon's list.
On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>Weldon, can you make a subpage to Rana's list and link it to the MMTK
>integration item?
I created a basic debugging page for debugging with the VS debugger on
windows.
Mikhail and others, make whatever changes you like :-)
Rana
On 10/24/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 24 Oct 2006 22:42:22 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
>
> > - Debugging on Windows
Mikhail,
Wonderful :-) Yes, we are still missing some hoisting opportunities, I saw
that in VTune( the old scores I ran are also with JET since the jitrino WB
was no yet in svn and I was lazy ). We shoule be able to match RI on
allocation rate, we use Appel's algorithm for the allocation of young
Hi Yuri,
Since you invited questions, here are a few from me...
What is the basic profiling mechanism...instrumentation or sampling?
What are the different types of profiles we are capturing ?
How are the profiles currently being persisted?
Is there any existing documentation on this?
Have
Etienne,
This is a good design, thanks. Conceptually, reference counting in the VM
is somewhat similar to Aleksey's proposal 1, if I understand correctly. This
design also requires quite a few hand-offs between the VM and GC. In DRLVM,
the problem is that we have quite a few GC's, not all within
Perfect, thanks Mikhail
On 10/30/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Is it the same?
http://citeseer.ist.psu.edu/630853.html
or
http://www.cs.technion.ac.il/~erez/Papers/parallel-compaction.ps
On 10/30/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
Hi,
Does anyone have an accessible reference to the OOPSLA paper "An efficient
parallel heap compaction algorithm" by Abuaiadh, Ossia, Petrank,
Silbershtein that is cited as a reference in the paper Xiao Feng points
to below? All my google searches lead to the ACM Portal :-)
Thanks,
Rana
O
The point is not that it is unimportant because it is an optimization. It is
1) it seems something that is be good to have, but is not urgent
immediately 2) that given the nature of our best solution ( java tables etc.
) is risky, we may not want to experiment with it in the main branch. We
should
On 10/28/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/28/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> On 10/27/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> >
> >
> > >Yes. That's also my opinion. The _design_ of class unloading is
Xiao Feng,
I will read the reference to understand what are the compressor
advantages, and how the algorithm is implemented, thanks.
Even when you have 1GB of physical memory, is there not an overhead of page
faults?
Is it an option to compact the heap in parts and/or to increase the number
of p
On 10/27/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>Yes. That's also my opinion. The _design_ of class unloading is >the
>focus of the discussion.
I think that before doing an optimization, it is a good idea to understand
why and where it is needed, and if the usage scenario fits what the
lt;[EMAIL PROTECTED]> wrote:
>
>
> Rana Dasgupta wrote:
> > My knowledge in this area is limited. But my understanding was that
web
> > servers and other similar hosts recycled processes periodically as
> > standard procedure, thereby tearing down all associated resourc
Hi,
I ran a simple test that allocates and discards a large number of objects repeatedly on multiple threads. These should all be gen zero objects( none survive ) that are repeatedly collected. So the test is of effective allocation rate( I set heap size for all the gc's to 64M and 256 M ). I thi
management
was not really urgent. I know that IIS does this, I am not sure about httpd.
I am not sure about other host environments.
On 10/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Rana Dasgupta wrote:
> Aleksey,
> I had a couple of questions.
> You state that DRLVM doe
Aleksey,
Thanks for the answers, please see inline.
On 10/26/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>Rana,
>- One example is Eclipse, when you build something with ant. E.g.
building
>kernel classes with ant in Eclipse will create separate class loader
every
>time developer perform
Yes, I thought about this breaking MMTk too. BTW, I don't know if Jikes does
class unloading, but they may get automatic unloading almost for free since
it is all java?
I am not very knowledgeable regarding other methods, but I think you can
always count manually to figure out when the loader ins
Aleksey,
I had a couple of questions.
You state that DRLVM does not implement the class unloading optimization,
and this may create memory pressure on some applications that load many
classes. Do we have a real case / example where an application is stuck for
insufficient memory because it use
The ideal way would be for acceptance tests like "build test" to always pass
and to catch and roll back the patch that breaks this invariant, rather than
to disable the tests. But I agree with Vera, it is important to keep a
running set up as acceptance tests, so disabling the well known failures
I see, thanks. The TLP proposal looks good to me.
Rana
On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
>
> Rana Dasgupta wrote:
> >
> >
> > On 10/25/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]&
On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>any comments? any at all?
Geir,
Sorry about my confusion. Is this synonymous with or a part of the
process of applying to Apache to graduate us from incubator status?
Thanks,
Rana
Hi Weldon,
It is quite likely that Gregory is right about the open file.
compile_IA32.cpp is not changed by 1786 :-) Could you also please close the
JIRA on 1786, 1900, 1898 when you have reviewed and applied the patches?
They still show open.
Thanks for your help,
Rana
On 10/25/06, Gregory
On 10/20/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>But you are right, the dependencies graph of all VM internal >headers is
a huge
>tangle which should be untangled somehow. Hopefully the > Class.h cleanup
which
>Pavel is doing now will make a first step in the right direction.
Is thi
+1
Hi Weldon,
I am sorry to to see that you may be still having problems with the
VS.Net debugger. I use it all the time, and everything( BP's, watch, memory
and thread windows ) works as expected. If you haven't done so alread, could
you please give this a shot?
devenv /debugexe whatever-comman
ursov <[EMAIL PROTECTED]> wrote:
Why not to do in parallel? No doubt, interpreter will run "Hello World"
first :)
On 10/20/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
> I thought that we are doing IPF first with the interpreter?
>
> Rana
>
>
--
Mikhail Fursov
I thought that we are doing IPF first with the interpreter?
Rana
On 20 Oct 2006 19:15:46 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
>To sum up my thoughts:
>* debugging_VM_and_JIT
>+ is outdated
>+ covers both linux and windows debugging tips intermixed
>+ has instructions for JET tracing (quite valid)
>* Let's make make it 2 separate docs: "Linux debugg
About 1916,
This is a Widows debugheap overrun issue in the awt code( don't know when
this was introduced ). The debug heap marks all allocations with a FD FD FD
FD before and after the allocation. During free() it checks to see is that
guardarea has been trampled on. If so, it complains with a DA
Gregory had already created an entry on the front page ( see his comments
above ).
On 19 Oct 2006 10:55:43 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x207 day of Apache Harmony Rana Dasgupta wrote:
> I added the VM dev tasks to
>
> http://wiki.apa
I added the VM dev tasks to
http://wiki.apache.org/harmony/CoreVmDevelopmentItems
off Gregory's currently empty page. Please change as necessary.
Rana
On 18 Oct 2006 20:11:14 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
>
>
> now this is done: http://wiki.apache.org/harmony/JIT_Development_
Alex,
Thanks for the information about Intel64 conventions for long mode. I
spoke losely and inaccurately below. I am the collector of the
development items, not the originator of all items :-) It may be a good
idea to write a short document describing the calling conventions we support
on vario
On 10/17/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/18/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>>
>> Pavel's looks like more flexible, but I have a question with the
>> special interface approach: is it possible that sometimes we want to
>> call a library native method in fast way?
Egor,
I understand them as seperate and distinct optimizations, but we can do
it however you, Mikhail would like to list them. The list also does not
include more local optimizations that are bound to appear as a result of
performance work.
Thanks,
Rana
On 18 Oct 2006 11:31:09 +0700, Egor P
discussed on the JIRA. The Stacktest and all other stack related tests now
pass.
I'll submit the patch against 1786 in the next few hours after running
acceptance tests.
Rana
On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
>
>
> On 10/16/06, Gregory Shimansky &l
Mikhail,
All this looks reasonable to me. At least to go ahead. Regarding 2A,
could the jit cache this information for re-use?
Alternatively, the JIT can do all this at startup...by going thru the
contract class of fastpath java methods and querying the component manager
for the native addresse
Mikhail,
Makes sense. BTW, we need to change the IA-64 to IPF( IA-64 is not an
external term ) on any posted list. IA32 to x86-32 bit and Intel 64 to
x86-64 bit. Sorry for the typo's.
Rana
On 10/17/06, Geir Magnusson Jr. <[EMAIL PROTECTED] > wrote:
Mikhail Fursov wrote:
> Rana,
> the JIT
Hi Gregory,
It is a good idea to put up a live list, thanks. Here are some
suggestions on the contents for development items in the VM/JIT. A few may
be almost done. We can fine tune...and add other work items as well
JIT Items
==
- GC related: WB support in Jitrino.opt
Implement support
Robin,
I found your last set of comments very illuminating. Thanks.
On your suggestion below...who would manage this object, ie., construct
and populate it, etc. before invoking the helper instance method? The jit? I
think that some of the VM specific information has started leaking into the
j
This is a good document, thanks Svetlana. Even if a lot of custom gc's don't
get written, it helps in understanding the current collecor farmework and
how it plugs into DRLVM.
Rana
On 10/16/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:
>
>
> Folks,
>
> I took a close look at "Hot to Wri
Hi,
Is there any known bug related to this issue?
Rana
On 10/15/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> After thinking about it a while, how about the following course of
> action:
>
> 1)
> First phase is to modify hysem_wait() and any other hy blocking
> functions to test if,
On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
So since I don't have Win 2003, I gotta just commit and let someone else
test?
Any committer have win 2003?
I think that it may be hard to find a test at this point that fails on
Windows Server 2003, but passes on XP. But perf etc. c
On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
>> I tried to put some back. StackTest still doesn't work. It's hard to
>> believe... so I gave up and just kept going :)
>I wonder if the test or the implementation are wron
On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> We're a volunteer project, so "supported" is based on interest in
> community. Lets be clear by writing down a set of platforms that we as
> a community commit to support.
>
> I think we can define "support" as - "one or more people
On 10/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> > This is just one more argument for doing IPF porting in a separate
> branch,
> > at least since some point.
> >
> > I admit that maintaining quality and checking for regressions on new
> > platforms is a separate big problem but I
My indentation is messed up, but it's too late to correct it..
On 10/12/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 10/12/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
> > 3) The problem: Is the signature for gc_alloc method : gc_alloc(int
> > objSize,
> > > int allocationHandle) is univers
I think that over time, we will start seeing IPF specific code files
appearing ... eg., quite a different jit, IPFhelpers.cpp,
IPFexception_filters.cpp, IPFnativestack.cpp, IPFprofiledrivers.cpp etc.
That is my impression of how most IPF ports go. Even in the main codebase
they will virtually be
Hi,
There is incomplete support for IPF platforms in the DRLVM codebase, as
many may have seen. It would be nice to complete it. There are a couple of
issues on how to start this. IPF specific changes are likely to be quite
significant, including changes in the JIT, garbage collector(s), exceptio
Makes sense, using a standard barrier invocation fastpath. But I assume that
the MMTk WB helper that it will call needs to be inlined too.
Thanks
On 10/10/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Weldon,
> I thought about slightly different approach.
> Why not to write fast-path VM helpe
Mikhail,
Please see inline.
On 10/9/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>All,
>We have 'org.vmmagic.unboxed' package (address arithmetic) support in
both
J>itrino.OPT and Jitrino.JET compilers today. So we can rewrite part of
our
>VM helper's fast paths in Java and teach JIT comp
On 10/6/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
>If we agree on common testing configs we can make sure the Harmony
>will be stable on at least this set of configurations. This does not
>mean we won't fix problems on other configurations. The goal is to
>gain and maintain general stabil
On 10/6/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>A major design concept in this revision that was not made very clear
>in previous submissions is "space". "GC" is a concept of a full (or
>standalone) garbage collector design. One GC can have multiple spaces,
>each of which can employ diffe
On 10/4/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
On 4 October 2006 at 18:26, "Ivan Volosyuk" <[EMAIL PROTECTED] >
wrote:
>> Secondly, I'm happy for debian users, but not all of the users use
>> debian. Much informative would be to have a URL with the sources where
>> I can get the library.
MIkhail,
Are you going to keep these files ( sln and projects ) updated, since
they are now becoming a part of the main codebase?
Thx,
Rana
On 10/4/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>
> Geir,
> I created this package to have a common place with other MSVC users in
> JIRA
> and I
+1
And the JIRA has logging properties as well. On several threads now, email
patches have just caused more confusion, with participants asking if these
are examples or live code.
On 10/4/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>
> I do not like JIRA too, but sending patches by email is
Yes, this makes sense. In that case, my vote would be to apply Atrem's patch
new_queued_cond_var.patch in H-1519. Let's run with this and the new
thread.c( that we have already applied from H-1457 ) for a while. If we
discover no new issues, we can go chat about them on the APR list?
Thanks,
Ran
On 9/26/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>Just to be clear: I suggest we apply new_queued_cond_var.patch
>attached to HARMONY-1519 - provided that Artem will answer >comments.
Hi,
I went through both the patches apr_cond.patch and
new_queued_cond_var.patch on H-1519.
There is
Hi Weldon/Geir,
Looks like we have quite a few Windows failures. Could one of you folks
please add in the the new file:
patches/win/APR/threadproc/win32/thread.c
that is in 1457, but possibly got dropped from the commit?
We also need H-1340 to fix the assert in the fat monitor. H-1519 may b
I looked at it( gc.LOS hang ) for a while and my findings are somewhat
similar to Alexey's. The problem occurs for me all the time irrespective of
where the trace statement apprears( ref: Weldon's comment ). On breaking in,
the call stack at hang is:
ntdll.dll!7c90eb94()
ntdll.dll!7c90ea53()
k
I am not very familiar with this section of the code. But if this is in
general true, and the classlib dependency on the hythread_XXX api's is
small, what Andrey says above makes sense to me. Why not replace them(
monitor enter/exit, TLS access etc. ) with the portability layer macrodefs
from thrd
On 9/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 9/20/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> >
> > On 9/21/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > Very nice and fast Xiao Feng :-) I read through your first
> submission
>
1 - 100 of 174 matches
Mail list logo
